Null Terminated Strings?
Alex Bell
Posts: 17
Hi Forum Folk,
Does anyone know whether items stored in Program Memory are Null Terminated strings? How about RAM locations? My Packet program is coming along, however, in my desired code version, when I have read in a string of values on a serial port, and then reformat them MSB first and try to ship them out as a synchronous signal on another pin, I get spaces between my characters that are not apparent when I read strings out of Program memory. Thanks, Alex Bell
Does anyone know whether items stored in Program Memory are Null Terminated strings? How about RAM locations? My Packet program is coming along, however, in my desired code version, when I have read in a string of values on a serial port, and then reformat them MSB first and try to ship them out as a synchronous signal on another pin, I get spaces between my characters that are not apparent when I read strings out of Program memory. Thanks, Alex Bell
Comments
And I believe when you read a string in from a serial port (into a byte array), you specify what the terminating character should be (it's a null by default?) but the terminating character is not saved.
So my second question is: Is there always a terminating character? This must be the NINTH bit? Do the registers hold 9 bits then, and the terminating bit is transparent? Or are the Byte Arrays 8 bits with the capability of only holding 7 bits? I am very confused because I can't find any info on the actual architecture of the chip's many kinds of memory, but I have noticed that the ram and eeprom seem to do my tasks differently. Thanks Alex
And no, there is no 'ninth bit', that's 8051 talk. And a "terminating Character" is NOT a 'Bit', it is an entire Byte. So if you saw "Hi" in memory, it would be "H", "i", 0. The last '0' or zero there is the terminating byte. And again, this is not automatic, you have to say:
DATA "Hi", 0 ' This puts a 'string' into eeprom memory when you program the BS2.
The way the memory works is that you basically have 13 Registers on the chip, each 16 bits wide. This is called RAM, but it's really registers. The PBasic run-time lets you treat those as 13 Words, or 26 Bytes, or 52 Nibbles, or 208 BITS, or any combination of the above. It does this very flexibly. Now, through a 'DATA' statement, you can put strings in the EEPROM when you program your BS2. The code starts from high-memory down, and the Data starts from location zero up. Don't bump them together, the BS2 doesn't check for this, and it won't work. Use the Memory Map part of the IDE to make sure.
Now, usually "Async" means RS-232, like SEROUT/SERIN, and "Synchronous" means with a clock -- like SHIFTOUT/SHIFTIN. I don't really understand how you are using the terms above, since you keep saying "Send them on another pin". If you're sending them Synchronously, you'd also need a clock pin. Note that even though you can manage RAM very flexibly, SEROUT/SERIN work in Bytes only.
Now, regarding a Byte Array. That's a concept. It's a way of talking about how a string is stored. So, a string "Hi",0 in eeprom will be stored as: "H", "i", 0. A String in registers --
DATA MyOtherStr "Hi",0
MyStr VAR BYTE(4)
MyStr(0) = "H"
MyStr(1) = "i"
MyStr(2) = 0
SEROUT 16, I9600, [noparse][[/noparse]STR MyStr] ' Will send "Hi" out serial port. Stops at the zero, and doesn't send it.
SEROUT 16, I9600, [noparse][[/noparse]STR MyStr\2] ' Sends out "Hi", and doesn't care that letter(3) is a zero.
You can also say (I'm pretty sure) -- SEROUT 16, I9600, [noparse][[/noparse]STR MyOtherStr]
In this case, the data will come from the EEPROM.
I am building a kind of Ham Radio packet device that sends out a burst of up to 16 bytes at a time, serially, bit by bit. That is my output, and since it is a data-burst of characters, I am calling it "synchronous" since it has no start or stop bits, it is simply "$AA,$B5,$32..." etc for 16 bytes. The synchronization is acquired by the receiver off of the $AA character reversals...since it is a short message, sync is usually preserved for the duration of the message. Bits are sent out of a pin on port a of a SX chip running a modified version of the UART Virtual Perhiperal, modified to send the MSB first. When I use only the SX chip, I hard-code my 16 bytes with the program, and it transmits the 16 bytes out in the way I want, which displays on my "packet receiver" exactly as it should be. This is a packet radio beacon. It works OK with a "canned" message.
To change my message, I would have to reprogram the sx chip.
It is inconvenient to re-program the packet beacon everytime my "beacon message" changes. I want to port my new message over an async link, rs-232 fashion, and have the SX chip reformat it by stripping start and stop bits, and reversing the order of each byte so that it "goes out" MSB first, as opposed to the RS-232 stream which is LSB first.
My desire is to have a BS2 chip with its serial port act as my "friendly interface". It will have all of the higher level communication and packet protocols to encapsulate my data. I use 1200 Baud SEROUT instructions from the BS2 chip INTO the SX chip RS-232 port provided by the Virtual Perhiperal to download a properly formatted message. The SX chip captures the 16 bytes and hold them in the "circular buffer". This is RAM now, not the EEPROM as in the "hard-coded" example. According to the SASM Debug, I am capturing and storing the ASCII characters in the SX circular buffer just as I want them...BUT as I read the 16 bytes out of RAM something is different. All I can think of is that there must be some difference in how the SX chip stores RAM bytes as opposed to EPROM bytes. I put the two versions of the code on this forum under the topic "Packet Radio Needs something" a week ago. Eventually I can replace the BS2 with a PC running a packet formating program for the higher level routines, and the SX will handle the interrupt based "modem" operations it is so well suited for. So in the end, there will be a pc, an async link to a SX chip and the SX chip will have an output into a chip modem to generate the tones. Thanks for your help!
And the SX and BS2 SERIN command DO strip off the start and stop bits, and just put the byte into a variable. The other confusion factor here is this LSB versus MSB reversal. I can't determine if it is even necessary, or if it is why it should be. If the SX is sending the data properly when hard-coded, it should send it properly when "soft-coded" so to speak from recieved data.
OH!· One thing you may not know is the SX can only have 16 bytes per array in RAM.· This is because of the way the SX memory is partitioned.· Thus it DOES access RAM differently than it accesses programmed FLASH memory.· And I believe those 16-bytes must be aligned on a page boundary, even then.· That could be the cause of your problem here.
Are you using SX/B or straight assembly ? And can you post your code, that will help alot.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
www.sxvm.com
"A problem well defined, is a problem·half solved."
·
I am using straight assembly language, not SX/B...I guess there is a serin in SX/B? Maybe I should try using that, and I might be able to do everything simpler? Anyway, here is my two listings again. The 1200TX is the hard coded listing that works, 1200TXRX is the one with problems! Thanks for your help! Alex