I've ported some of the most basic routines in the stdlib, but most of the functions you really want are implemented as ROM calls in the OS.
Projects:
Random Stuff.
Random Stuff.
I am probably getting ahead of myself here but does anyone know how strings are stored in the calculator? I assume that a-z are all in a row as are A-Z but I could be wrong. I will need to know eventually as this is inherently needed in how my C programs work.
You weren't very clear, but it's just a character array (as usual), usually null-terminated (also normal- there are also romcalls for length-prefixed strings). String variables (like all others) need to be located in memory with a call to _FindSym, which returns a pointer to the variable's data (which is prefixed with the variable length).
I suppose you're particularly interested in the character map. For the commonly used characters (alphanumeric and some punctuation) it's the same as ASCII, so you generally don't need to worry about string encoding.
If you wanted to read str1 and invert case, you might do something like this (with a pretend C binding for _FindSym):
Code:
I suppose you're particularly interested in the character map. For the commonly used characters (alphanumeric and some punctuation) it's the same as ASCII, so you generally don't need to worry about string encoding.
If you wanted to read str1 and invert case, you might do something like this (with a pretend C binding for _FindSym):
Code:
char stringName[] = {StrngObj,tVarStrng,tStr1,0};
char *stringVar = FindSym(stringName); //Assuming it's in RAM and exists
stringVar += 2;
while (*stringVar != 0)
{
if (*stringVar >= 0x41 && *stringVar <= 0x5A)
*stringVar += 0x20;
else if (*stringVar >= 0x61 && *stringVar <= 0x7A)
*stringVar -= 0x20;
stringVar++;
}
Ok, thanks that was what I was looking for including some I didn't realize I needed to look for but still needed.
On a separate topic that I just realized might make this pain unneeded, how easy would it be to make a serial console program that would work with a device needing a standard usb-serial driver or alternatively how easy would it be to use usb8x/msd8x to transfer a file onto a usb mass storage device as an ascii file. A third possibility is to use a send byte call assuming the omnicalc one works over usb to send the text one character at a time to an AVR that I have and use it's easier to code interface to do the processing. I would need to make sure I could do byte by byte receiving though to do the last one. All of these options would be interfacing with my AVR to do the processing and I think I could work out each one of them but I am not sure.
On a separate topic that I just realized might make this pain unneeded, how easy would it be to make a serial console program that would work with a device needing a standard usb-serial driver or alternatively how easy would it be to use usb8x/msd8x to transfer a file onto a usb mass storage device as an ascii file. A third possibility is to use a send byte call assuming the omnicalc one works over usb to send the text one character at a time to an AVR that I have and use it's easier to code interface to do the processing. I would need to make sure I could do byte by byte receiving though to do the last one. All of these options would be interfacing with my AVR to do the processing and I think I could work out each one of them but I am not sure.
You mean something as simple as <b>$ minicom /dev/usb0</b>? That would work under Linux of many flavors. 
The Tari wrote:
You weren't very clear, but it's just a character array (as usual), usually null-terminated (also normal- there are also romcalls for length-prefixed strings). String variables (like all others) need to be located in memory with a call to _FindSym, which returns a pointer to the variable's data (which is prefixed with the variable length).
I suppose you're particularly interested in the character map. For the commonly used characters (alphanumeric and some punctuation) it's the same as ASCII, so you generally don't need to worry about string encoding.
If you wanted to read str1 and invert case, you might do something like this (with a pretend C binding for _FindSym):
Code:
String variables aren't zero-terminated though - you'll have to read the size bytes and use a for loop. I suppose you're particularly interested in the character map. For the commonly used characters (alphanumeric and some punctuation) it's the same as ASCII, so you generally don't need to worry about string encoding.
If you wanted to read str1 and invert case, you might do something like this (with a pretend C binding for _FindSym):
Code:
char stringName[] = {StrngObj,tVarStrng,tStr1,0};
char *stringVar = FindSym(stringName); //Assuming it's in RAM and exists
stringVar += 2;
while (*stringVar != 0)
{
if (*stringVar >= 0x41 && *stringVar <= 0x5A)
*stringVar += 0x20;
else if (*stringVar >= 0x61 && *stringVar <= 0x7A)
*stringVar -= 0x20;
stringVar++;
} calc84maniac wrote:
String variables aren't zero-terminated though - you'll have to read the size bytes and use a for loop.
Orly? Shows how much I work with TI variables.
KermMartian wrote:
You mean something as simple as <b>$ minicom /dev/usb0</b>? That would work under Linux of many flavors.
No, I am not including a computer in this setup, the calc would be the host for a little USB AVR I have that can act as a usb serial port with a serial console on it. I am basically looking to transfer a string to my AVR and receive one back. I am looking at doing the actual processing on the AVR which will be easy to program the only issue would be the communication to and from the calculator. How easy or hard would this be?
My choice would be I2C over the I/O port. It's simple (Ben Ryves wrote some routines for the protocol at some point), and most AVRs can handle it in hardware. USB is much more work than it's worth for this application.
The Tari wrote:
My choice would be I2C over the I/O port. It's simple (Ben Ryves wrote some routines for the protocol at some point), and most AVRs can handle it in hardware. USB is much more work than it's worth for this application.
That would work, I just wasn't sure how to get the right data rate, care to provide a link? With that I might even be able to implement it with little help because of omnicalc's send byte and get byte calls
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement