Part 4 - Miscellaneous and Esoteric Issues
|
|
| PICAXE Questions & Answers | |
|
Part 4 - Miscellaneous and Esoteric Issues | |
|
|
|
Part 1 - Common QuestionsPart 2 - Software IssuesPart 3 - Hardware IssuesPart 4 - Miscellaneous and Esoteric Issues
Part 5 - Known Bugs and Other Problems
Two pieces of information that Rev-Ed have released into the public domain with Programming Editor 4.1.2 which leads to that conslusion are ...
There is also a 'Wizard' menu entry for PICAXE.net which is yet to be made accessible, and a link to a PICAXE.net datasheet, although the datasheet itself doesn't exist. None of the current documentation mentions PICAXE.net, so, until more information is forthcoming, it's not clear what the offering is, how it will work, nor when it will be available or how much it will cost. One thing is for sure; something very interesting looks to be on its way.
The "Read Only" aspect of its naming is historical, from the time when the hardware technology used would only allow a limited number of writes before such EEPROM devices failed to function correctly; to all intents and purposes it was Read Only. With new technology, EEPROM can support up to one million writes without any problems although not all devices allow so many. Flash is, without getting into the really deep technicalities, exactly the same as EEPROM, but currently allows around 100,000 writes before it fails to work correctly. Like EEPROM, Flash will remember what was last writen to it when the power is removed, and is also "non-volatile storage". RAM is Random Access Memory, and comes in two flavours; Dynamic (DRAM) and Static (SRAM). Dynamic RAM is cheap and ideal for building large memory devices such as are used in PC's but has to be "refreshed" on a regular basis to make it remember what was last written to it ( this is all handled transparently to your own programs by special chips on a PC motherboard ). Static RAM does not need refreshing and is often faster in use than DRAM but is much more expensive to manufacture. SRAM is used where speed is important or having to do refreshing is unsatisfacory and it is commonly used within microcontrollers and computer CPU's. Neither Dynamic nor Static RAM will remember what was written to them if power is completely removed, which makes them "Volatile storage". It is possible to make Static RAM remember what was last written to it by keeping it powered-up when the rest of the system has its powered down. This is usually done by a battery or a very large specialised capacitor-type device, and is what is meant when people talk about "Battery Backed-Up RAM", such memory is also "non-volatile storage", at least until the backup battery goes flat. SFR's are what Microchip calls control registers on PICmicro devices; Special Function Registers. These are memory locations within the PICmicro which can be written to in order to control the operation of the device and read from to see what it is doing. SFR's which function this way do not contain data per se but because the RAM within a PICmicro was historically a part of the Special Function Register set, it is quite common to see RAM in a PICmicro being refered to as SFR. SFR's on a PICmicro ( and PICAXE ) which actually control the device's operation are reset to particular values whenever power is connected or the device is reset. The RAM part of the PICmicro SFR set is not initialised in any way when the power is applied or the device is reset and will often contain random data. On the PICAXE ... The PICAXE sets the SFR's as it needs to do its job and clears the RAM to zero when turned on or reset, so the programmer does not have to worry about data may be in the RAM when it is first used. All PICAXE's have 64, 128 or 256 bytes of EEPROM which can be used for storing data, and the EEPROM can be written to up to one million times. Access to this data is gained by using the READ and WRITE commands, and whatever is written is remembered even after the power to the PICAXE has been removed. On the PICAXE-08, 18 and 18A, the program code is also placed in the Data EEPROM alongside any data, and these devices will allow one million program downloads. On the PICAXE-18X, 28X and 40X the program code goes into Flash which will allow about 100,000 downloads. Data still goes to EEPROM with one million writes allowed. The PICAXE-28 and 28A are special cases with program code being downloaded into Flash, and with data being placed in EEPROM, but the READMEM and WRITEMEM commands give access to an additional set of data held in Flash which can be written to 100,000 times. All variables and SFR's which can be accessed using the PEEK and POKE commands are located in Static RAM and have unlimited read and write capabilities. Note that the location and function of chip controlling SFR's and the amount of RAM available varies between variants of PICAXE processors. Any data written to the variables or RAM is fogotten and replaced with zeroes when the PICAXE has its power removwed.
SYMBOL B0_SFR_ADDRESS = SFR Address of 'b0'
SYMBOL B7_SFR_ADDRESS = SFR Address of 'b7'
FOR b13 = B0_SFR_ADDRESS TO B7_SFR_ADDRESS
POKE b13,$AA
NEXT
The following program should find the address of 'b0' on any PICAXE variant when variables 'b0' through to 'b13' are stored consecutively in the SFR space.
SYMBOL PATTERN0 = $35
SYMBOL PATTERN1 = $56
SYMBOL PATTERN2 = $69
SYMBOL PATTERN3 = $9A
SYMBOL PATTERN4 = $AC
SYMBOL PATTERN5 = $C3
SYMBOL PATTERN6 = $36
SYMBOL PATTERN7 = $59
SYMBOL PATTERN13= $6A
SYMBOL peekAt = b8
SYMBOL byte = b9
SYMBOL pattern = b10
SYMBOL bX = b11
SYMBOL ptr = b12
ptr = $1F
TryNextSfr:
IF ptr = $F3 THEN Done
ptr = ptr + 1
b0 = PATTERN0
b1 = PATTERN1
b2 = PATTERN2
b3 = PATTERN3
b4 = PATTERN4
b5 = PATTERN5
b6 = PATTERN6
b7 = PATTERN7
b13 = PATTERN13
FOR bX = 0 TO 7
peekAt = ptr + bX
PEEK peekAt,byte
READ bX,pattern
IF byte <> pattern THEN TryNextSfr
NEXT
peekAt = ptr + 13
PEEK peekAt,byte
READ 8,pattern
IF byte <> pattern THEN TryNextSfr
FOR b0 = 0 TO 255
PEEK ptr,byte
IF byte <> b0 THEN TryNextSfr
NEXT
FOR b13 = 0 TO 255
PEEK peekAt,byte
IF byte <> b13 THEN TryNextSfr
NEXT
SERTXD (#ptr," ")
GOTO TryNextSfr
Done:
SERTXD ( "Done" )
END
EEPROM 0,( PATTERN0 )
EEPROM 1,( PATTERN1 )
EEPROM 2,( PATTERN2 )
EEPROM 3,( PATTERN3 )
EEPROM 4,( PATTERN4 )
EEPROM 5,( PATTERN5 )
EEPROM 6,( PATTERN6 )
EEPROM 7,( PATTERN7 )
EEPROM 8,( PATTERN13 )
The program should print a single SFR Address in decimal indicating the address of 'b0' within the SFR space followed by the word "Done". Note that the location of 'b0' is likely to be different on each PICAXE variant and may change between firmware versions. Code which is dependant upon the location of 'b0' will almost certainly fail if it is executed on any PICAXE where it is not at that location. At least the following test should be included at the start of any PICAXE program to check that 'b0' is likely to be at the location expected, but it is not guaranteed to be 100% accurate ...
SYMBOL B0_SFR_ADDRESS = SFR Address of 'b0'
CheckB0IsWhereWeThinkItIs:
FOR b0 = 0 TO 255
PEEK B0_SFR_ADDRESS,b1
IF b0 <> b1 THEN B0IsNotWhereWeThoughtItWas
NEXT
The PICtalk protocol is only appropriate to communications over a wireless link, and is almost entirely undocumented. The manufacturer does not recommend the use of the protocol and will provide no help, assistance or information on the protocol which is only really suitable for the limited application for which it was originally intended. It is best to forget that you ever heard of the PICtalk protocol and look at alternative protocols for over-the-air communications; take a look at ... Oh, go on; please tell us what you know ... From the Remote Greenhouse Monitor datasheet data is transmitted in 11 byte packets. In that application, two packets are sent ( the first giving data for the light sensor and the second for temperature ) and they are both sent once every half second. All packets are sent at 1200 baud and each packet has the same format ...
$AA $AA $AA $AA $00 $00 $99 ii vv [ 50mS ] $66 $66 [ 50mS ] The first four bytes ( 4 x $AA ) are a 'preamble' which is used to 'condition' the receiver which becomes ready to receive data, and is much more reliable when doing so, after it has seen a burst of alternating 0's and 1's. The next three bytes ( $00 $00 $99 ) are the synchronisation and framing bytes, and the receiver uses the $99 to prepare itself to receive the actual data that is embedded within the packet. The two following bytes ( 'ii' and 'vv' ) are the indicator of which sensor has been read and what its value is. For the Remote Greenhouse monitor an 'ii' of $00 indicates it is a light sensor reading and $01 that it is a temperature reading. The two $66 bytes with 50mS pauses before and after are also used as framing bytes and to allow some rudimentary error checking to be performed on the received data. The required packet can be sent using the following code ...
SYMBOL ii = b0 ' Sensor Indicator Number
SYMBOL vv = b1 ' Sensor Value
SendPacket:
ii = Sensor Indicator Number
vv = Sensor Value
SEROUT TX_PIN,T1200,($AA,$AA,$AA,$AA,$00,$00,$99,ii,vv)
PAUSE 50
SEROUT TX_PIN,T1200,($66,$66)
PAUSE 50
RETURN
The receiving software monitors the data from the radio receiver looking for the $99 framing byte and then reads the 'ii' and 'vv' bytes which have been transmitted. A check is made that the 'ii' value is not $66, which indicates that what was received is not correct. If 'ii' is $66 the receiver simply waits until another packet is received. The packets can be received as follows ...
SYMBOL ii = b0 ' Sensor Inidcator Number
SYMBOL vv = b1 ' Sensor Value
ReceivePacket:
SERIN RX_PIN,T1200,($99),ii,vv
IF ii = $66 THEN ReceivePacket ' Perform Error Check
RETURN
There is almost no error checking within the receiver code given in the Remote Greenhouse Monitor example, no checks for corrupted data, and no handling or notification of lost packets. The protocol also has a very high overhead in transmission with each packet taking nearly 200mS to transmit. This gives a maximum throughput of around five packets per second. It is for these, and other, reasons that the protocol is not recommended for use and is not officially supported for PICAXE users by the manufacturer.
The equivalent period of the each PWM pulse cycles is ...
As 'period' decreases, 'PWMfrequency' increases, so the highest frequency is when 'period' is 0 (zero), however, 0 is a special case in that it stops PWM, so the lowest value that can be used is 1 (one), which at 4MHz ...
PWMfrequency = ( 4 * 250000 ) / ( 1 + 1 ) PWMfrequency = 1000000 / 2 PWMfrequency = 500000Hz or 500KHz Correspondingly, the lowest frequency is when 'period' is 255, which at 4MHz ...
PWMfrequency = ( 4 * 250000 ) / ( 255 + 1 ) PWMfrequency = 1000000 / 256 PWMfrequency = 3906.25Hz or 3.90625KHz Note that the frequency may drift slightly, and will be more pronounced on a PICAXE-18X which is controlled by an on-chip "RC" oscillator, and not an external resonator or crystal. If you need to find the 'period' value required to produce a particular 'PWMfrequency', then use the following equation ...
The biggest difference to the BS1 is that the for most PICAXE's the main I/O lines are fixed input or output, and not bi-directional as on the BS1. A BS1 design using this bi-directionality would probably need both its hardware and software changing to work on a PICAXE. PBASIC for the Basic Stamp 2 (BS2) is a superset of that for the BS1 but is not so easy to convert as it has many syntactical elements not supported on the BS1 or PICAXE, in particular, Arrays, Modifiers and Parenthesisied Mathematical Expressions, additional functions ( Sine, Square Root etc ), and additional Commands. The ease of converting from PBASIC for a BS2 to PICAXE or BS1 will very much depend on what the program being converted uses and needs to do. It would be fairly hard to create an automatic conversion utility which did the job, so "by hand, a line at a time" is the only real approach.
That's not entirely true, as a PICAXE which has its program code placed within on-chip Data EEPROM ( and perhaps Flash ) can be read through a PICmicro programmer and the tokens which represent the executable program can be decoded to give an approximation of the original source code, but it is not a task which is easy to perform and requires information on the PICAXE which is not published nor generally available.
It is an unusual situation, and one which should not occur, because making an analogue input pin an output can damage attached hardware. PICAXE is a trademark of Revolution Education Ltd. These PICAXE pages are produced entirely independantly of Revolution Education Limited and may not reflect the opinion of Revolution Education Limited or its agents. The information provided is based upon and derived from information published by Revolution Education Limited, other sources of PICAXE information and the author's own experiments and prior experience. The views expressed by the author do not necessarily represent those of Revolution Education Limited or its agents. While every effort has been made to ensure that the information on these PICAXE pages is accurate and correct, the author can accept no responsibility for any errors or ommissions which do occur. The information provided is used entirely at your own risk. | ||||
|
First published on Friday the 5th of March, 2004 at 03:31:59
Last upload was on Thursday the 16th of December, 2004 at 11:40:37 |
