Brian
First what is the objective of your program?
To type on the SimpleIDE terminal and have it echoed back from Activity Board.
SimpleIDE already has it's internal terminal connected to pins 31,30 and you do not
need to open it yourself to talk to it.
In SimpleText there are several functions at the beginning of the list that do not take
a text_t device as the first parameter. Those functions send to the internal terminal.
Look at my post #170 where I use print Hi There and putchar to clear the screen and
print again in the loop to print what came back from the Activity Board.
Note that for the serial connection to the XBEE I do create a device and use open to
tell it which pins and what baud rate and then I use the functions in SimpleText in the lower
half that take a device as the first parameter.
It looks like you stripped the program down to where it is not a valid program and is time to start
over with something simple and build from there.
What post is Banjo's code you started with I am sure I saw it and I believe he swapped out the terminal
on 31,30 but ask to be sure I am looking at the same listing you are.
Jeff
I believe you are thinking of a set of messages with an id and data to send over to the AB.
When you say 6 bytes and ASCII I am not sure what you mean. Actually it is all bytes whether
binary or text chars but either the messages are all binary or all text strings like S-Records .
I was thinking about this yesterday, will post my experiment.
Tom
Tom,
I know that I've gotten of the beaten path from banjo's code ,but I'm trying to receive serial data and react to it. I called fdserial , to test out pointers ,then I want to receive one byte of data and if it's a "5" ,print out five. If it is not a 5 just keep echoing the input.
Ron,
I believe (n = 5) means that "n" now is 5 and that (n == 5) is a test to see if n is equal to 5.
Hi Tom, you are exactly right with the ID and the data packet. I am erring on the side of caution with this being a wireless setup.
The data is going back and forth just fine as it is but I wanted an extra step to ensure the synchronization is secure and I also wanted a simple checksum to verify the data. I have read about checksums, crc's and byte stuffing and I dont think we need anything as complex as what I have been reading about.
I would love to see what you can come up with, the way I am thinking is a fixed length data packet in both directions. At the moment I am sending and receiving 6 bytes each way and don't really visualize it being any longer.
Ken,
You need ITunes on your computer , plug iPad into desktop,select ipad in iTunes , select apps ,choose techBasic and drag jpeg in techBasic ,unplug iPad and it should work.
Hi, I have been trying different graphics on the iPad also, just to visualize what the finished article could look like.
More importantly I have been trying techBasics error handling routines. I have to admit I spent more time on it than I expected, it took me a while to grasp what the manual was saying.
There are two possible error situations I wanted to handle in particular, both associated with the wifi connection. One is if for any reason the iPad did not receive all or part of the data packet and the second is if the wifi connection should drop out.
The objective is to be able to recover from the above without rebooting the app. I want to test it some more but number one seems to be done so now its on to number two.
The attached screen shot shows the app in an error condition where the transmission from the Prop was disabled. After re-enabling the transmission I was able to reconnect and continue as normal.
Another option now available is the ability to change IP and Port numbers, the app as I have it loads with the defaults shown in the screen shot which works with my XBee.
Jeff
@Ken some of the errors regarding file #1 are the errors I am dealing with now in the error handling routines. Also there was an issue with my spin file to begin with but I updated the zip file and I think that should be ok. Try with what you have and if you are still having problems I will attach the latest zip with images (I have not zipped it up yet)
I've just now caught up to your ad-hoc example up above, and have the connection framework functioning very reliably. Yeah! Took me about two hours to properly set things up (I think the baud rate in your sample Spin program was 115K, but should be 9600, or matched to the XBee WiFi).
Even though the robot is doing nothing it's exciting to see that we've gotten this far. I've always assumed this wouldn't be possible for a bunch of reasons (gotta be an Apple developer, etc.) but it's rewarding to see that we can have two-way communication.
Before I read your post above, and catch up to where you are with this, take me back to your ActivityBotDebug.spin program for a moment. Basically, you've provided a serial framework with communication bytes for whatever we want to send back and forth, right? And you're now looking to us to fill in the framework with useful stuff - value of Ping))), speeds from accelerometer, etc. Am I mostly right? And this is why Brian was pulling out whatever hair he had left - he was trying to get the framework built in C because there are so many useful ActivityBot programs already produced in C.
Let me know if I'm as clueless as I thought, or if I'm understanding what where we are with this project.
Hi, I have been trying different graphics on the iPad also, just to visualize what the finished article could look like.
More importantly I have been trying techBasics error handling routines. I have to admit I spent more time on it than I expected, it took me a while to grasp what the manual was saying.
There are two possible error situations I wanted to handle in particular, both associated with the wifi connection. One is if for any reason the iPad did not receive all or part of the data packet and the second is if the wifi connection should drop out.
The objective is to be able to recover from the above without rebooting the app. I want to test it some more but number one seems to be done so now its on to number two.
The attached screen shot shows the app in an error condition where the transmission from the Prop was disabled. After re-enabling the transmission I was able to reconnect and continue as normal.
Another option now available is the ability to change IP and Port numbers, the app as I have it loads with the defaults shown in the screen shot which works with my XBee.
Jeff
@Ken some of the errors regarding file #1 are the errors I am dealing with now in the error handling routines. Also there was an issue with my spin file to begin with but I updated the zip file and I think that should be ok. Try with what you have and if you are still having problems I will attach the latest zip with images (I have not zipped it up yet)
This looks like a vast improvement, especially with the error handling.
Seems like the rest of us should be working on the ActivityBot side of things since you've made so much progress on the iPad side of things.
Looks like you've given us an "insert your code here" method:
pub Main | x , y com.start(RX_PIN,TX_PIN,00,BAUD)
debug.start( 31,30,00,BAUD)
com.rxflush
repeat
DataOut
x:=com.rx
case x
"W" : get_data
Where we can do things like provide light levels (two bytes for left/right side), ultrasonic sensor (single byte), LED status (couple bits, or bytes if we want) and speed (two bytes).
These values could be displayed in techBASIC and also be changed through the R/C interface as they are sent back in the get_data method.
Pretty close to what you're thinking? I'm no programmer, but with enough time and help I usually find my way.
Now I'm finding myself in the C or Spin debate. Seems like we should get your Spin program working in C first because we could easily leverage all the useful ActivityBot source code examples. This might be a challenge for me and I see that Brian has already lost some hair over the idea.
I am pleased you have at least seen a sample Ken, its hard work to start, loading images and code etc, mainly because its very new to most of us. Of course a purpose built app would take out 80% of the work.
The app you are running is transmitting 6 bytes and receiving 6 bytes, the fact the received bytes are an echo at the moment does not matter they can be used for any sensor data we wish when we decide what data we want displayed on the iPad. In my opinion 6 bytes is close to being enough but that can be modified.
Brian and Tom have both shown some good C examples I am afraid I am not proficient enough to chip in and help.
I am attaching progress so far, with this one you can test the error handling by pressing the reset button on the Prop. The app will show an error but you should be able to reconnect and continue without rebooting the app once the reset has completed.
I recommend deleting all images and files that are related to this project from your iPad and starting afresh with these new images. The zip contains 8 images 1 techBasic source file on Notepad and a Spin file for testing.
One last thing about the techBasic source you have and something I have been looking at. It's actually working too fast and overunning the wifi buffer, that is my thought right now anyway.The source in this zip slows the rate down. I will continue to monitor this.
Jeff
Good digging on error handling. I will look at it later.
Been working on simple message sending
In the process of debugging first test of code.
Not the final way I want to do it but just testing message parsing in C and
making the messages in Tech Basic.
Just made the LED's on P26 and P27 turn on and off sending a message to AB
@Jeff,
This c stuff is as clear as cream of mushroom soup ,I hoping to make a parser so that accessories can be added later. I'll take a look at your spin code and see if I can make it work in C.
Can anyone tell me what is wrong with this code ? It should receive one marker char of either a "X" or a "Y" and then store the next char in separate locations ,then send the 2 values to the serial terminal.
Here is my message sending test code
Strickly testing out the concept.
We would use messages which have a checksum for testing if valid
We would make up messages to tell the Bot to execute various commands or to
send speed settings etc.
For now I just have two messages, one that has one data byte used in a case statement as if
it came from a keypress on a terminal
The second message just sends 6 known bytes over.
First cut only sending messages from iPad,
This is a test program only actual version will put watching for incoming messages in a seperate cog and
main line code can watch if valid messages are there.
I have code doing that with the Sony Remote but did not want to cloud up the testing with to much .
This gets a message and in fact will wait forever to get it and then processes.it.
The advantage is things happen one at a time.
Parsing messages may work better if the messages coming in are strings and not binary like these as TB
has string functions like LEFT and MID.
The Tech Basic code
REM Test Message sending to Activity Bot Ver 1
DIM Message~(16)
xcenter = Graphics.Width/2
DIM quit AS Button
quit = Graphics.newButton(xcenter,250)
quit.setTitle("Quit")
DIM send6 AS Button
send6 = Graphics.newButton(xcenter,200,100)
send6.setTitle("Send 6 bytes")
REM Direct connection ip address
Comm.openTCPIP(1, "192.168.1.3", $2616)
DIM swP26 as Switch
DIM swP27 as Switch
DIM lblP26 as Label
DIM lblP27 as Label
swP26 = Graphics.newSwitch(xcenter,25)
!Default to off
swP26.setOn(0)
swP27 = Graphics.newSwitch(xcenter,65)
!Default to off
swP27.setOn(0)
lblP26 = Graphics.newLabel(xcenter+85,25,100)
lblP27 = Graphics.newLabel(xcenter+85,65,100)
lblP26.setText("P26LED")
lblP27.setText("P27LED")
System.showGraphics
SUB TxMessage(numbytes AS BYTE)
FOR i% = 1 TO numbytes
PUT #1,, Message~(i%)
NEXT
END SUB
SUB SendMsgA1(db AS Byte)
Message~(1) = $A1
Message~(2) = 2
Message~(3) = db
! Compute the checksum
checksum~ = BITNOT(2 + db) + 1
Message~(4) = checksum~
TxMessage(4)
END SUB
SUB SendMsgA6
!Send known bytes
Message~(1) = $A6
Message~(2) = 7
Message~(3) = $01
Message~(4) = $02
Message~(5) = $04
Message~(6) = $08
Message~(7) = $10
Message~(8) = $20
FOR idx = 2 To 8
checksum~ = checksum~ + Message~(idx)
NEXT
checksum~ = BITNOT(checksum~) +1
Message~(9) = checksum~
TxMessage(9)
END SUB
SUB valueChanged(ctrl AS Control, time AS DOUBLE)
IF ctrl = swP26 THEN
IF swP26.isON THEN
SendMsgA1(1)
ELSE
SendMsgA1(2)
END IF
END IF
IF ctrl = swP27 THEN
IF swP27.isON THEN
SendMsgA1(4)
ELSE
SendMsgA1(8)
END IF
END IF
END SUB
SUB touchUpInside(ctrl AS Button, when AS Double)
if ctrl = quit then
STOP
ELSE IF ctrl = send6 THEN
SendMsgA6
end if
end sub
The C code which is run with the terminal as I print what is happening
Turning the Tech Basic switches on and off turns on and off P26 and P27 LED'S
/*
Test message concept
Each message will be of the following format
MsgId byte Just something made up, maybe lower nibble is length
Len byte Number of bytes remaining in message after this byte including chksum byte
Data0 byte Data bytes what they mean is message dependent
.
.
Datan byte
Checksum Checksum byte, the 2's complement of the sum of all bytes except MsgId
Two simple messages for this test
A single data byte to simulate switch closure or a key press
MsgId = 0xA1
Len = 2
Databyte
CheckSum
Send six bytes to be processed
MsgId = 0xA6
Len = 7
Six Data bytes
CheckSum
*/
#include "simpletools.h" // Include simple tools
#include "fdserial.h"
#define MAXCHARS 78
/* Parsing the incoming messages requires a state machine driven by
each incoming byte from the serial port
With the following states
*/
#define WAIT4MSGID 1 //Get bytes until we see one we know
#define GETLENBYTE 2 //Get the number of bytes remaining in message
#define GETDATABYTES 3 //Get the data bytes. Len byte - 1 bytes
#define GETCHECKSUM 4 //Get checksum byte
#define MAXMSGSIZE 16 //Small messages for now
// Connections for Activity Bot Board
int RX = 10, TX = 9; // XBEEwifi connected pins
fdserial *xbwifi; // Serial device to talk to XBEEwifi
// An array to hold an incoming message of max length
uint8_t MsgBuffer[MAXMSGSIZE];
// Message parsing variables
uint8_t rxchar;
uint8_t MyChkSum;
uint8_t BValue;
uint8_t *pRxMsgPtr;
uint8_t *pMsgPtr;
uint8_t bytecount;
uint8_t bytesneeded;
int RxMsgState;
//Create an array to store 6 byte message values for testing
uint8_t Sixbytes[6];
/* For testing of the receive message function. Just define it here
for later version launch it into it's own cog to watch for messages
and handshake with main line code when message is available
*/
void RxMessage() {
uint8_t chktest;
uint8_t idx; //Stand alone version only
int ch;
// HERE IN STAND ALONE TEST VERSION
int msgflag; // Set to 1 to build a new message
// State Machine sets it to 0 indicating have a message
// When in seperate cog handshake flag will be used
//Get a char from serial port wait for it to arrive
//In this test version it will hang the system
RxMsgState = WAIT4MSGID; // HERE IN STAND ALONE TEST VERSION
msgflag = 1; // HERE IN STAND ALONE TEST VERSION
idx = 0; // HERE IN STAND ALONE TEST VERSION
print("RxMessage Looking\n");
while(msgflag == 1) {
rxchar = fdserial_rxChar(xbwifi);
// Execute state machine on rxchar
switch (RxMsgState) {
case WAIT4MSGID:
if ( (rxchar == 0xA1) || (rxchar == 0xA6)) {
print("\nGot Message %x\n",rxchar);
MsgBuffer[idx++] = rxchar;
MyChkSum = 0;
RxMsgState = GETLENBYTE;
}
break;
case GETLENBYTE:
// Already pointing at len byte
MsgBuffer[idx++] = rxchar;
bytesneeded = (uint8_t)rxchar -1; // Do not include checksum byte
bytecount = 0;
MyChkSum = (uint8_t)rxchar; // First byte of sum
RxMsgState = GETDATABYTES;
break;
case GETDATABYTES:
//Already pointing at next byte
MsgBuffer[idx++] = rxchar;
MyChkSum += (uint8_t)rxchar;
bytecount++;
if(bytecount == bytesneeded) {
RxMsgState = GETCHECKSUM;
}
break;
case GETCHECKSUM:
//Now pointing at checksum byte
MsgBuffer[idx] = rxchar; // No need to inc to next byte this time
/*Adding the received checksum byte to MyChkSum should be
zero if we have a valid checksum because the checksum in message
is the negitive of the sum
*/
chktest = (uint8_t)rxchar + MyChkSum;
chktest = chktest & 0xFF; //Only 8 bits wanted
if(chktest == 0) {
msgflag = 0; // Were done have valid message
RxMsgState = WAIT4MSGID; // Redundent in stand alone version
}
fdserial_rxFlush(xbwifi); // Clear the serial buffer
break;
}
}// End while msgflag
}
int main() // Main function
{
uint8_t ix; //Index into MsgBuffer array
int ch;
// Add startup code here.
xbwifi = fdserial_open(RX,TX,0,9600); // Full Duplex serial to XBEE
fdserial_rxFlush(xbwifi); // Clear the serial buffer
pause(100);
RxMsgState = WAIT4MSGID;
while(1)
{
// Add main loop code here.
//Get a valid message, waits forever for one
RxMessage();
//Process the valid message
//Have plenty of time not watching for new message
//until done.
// Start at beginning of message
ix = 0;
//Use a case statement to process each type of message
switch (MsgBuffer[ix++]) {
case 0xA1:
print("Message A1\n");
ix++; // Bump index past len byte of message
BValue = MsgBuffer[ix];
//Use the byte as if it was a keypress command
switch (BValue) {
case 1:
high(26); // Turn on P26 Led
print("P26 ON\n");
break;
case 2:
low(26); // Turn off P26 Led
print("P26 OFF\n");
break;
case 4:
high(27); // Turn on P27 Led
print("P27 ON\n");
break;
case 8:
low(27); // Turn off P27 Led
print("P27 OFF\n");
break;
}
break;
case 0xA6:
print("Message A6\n");
ix++; // Bump index past len byte of message
for(int b=0;b<6;b++) {
Sixbytes[b] = MsgBuffer[ix++];
}
for(int br=0;br<6;br++){
print("$%02x ",Sixbytes[br]);
}
print("\n");
break;
}// end switch message
}
}
The code below has correct syntax, but I have no idea if it will do what you need.
I indent to keep track of what the code is doing in my mind. The braces {} are there for correctness and communicating what the code is expected to do. It is not a comment in C.
#include "simpletools.h"
#include "fdserial.h"
int main(void)
{
extern text_t *dport_ptr; // default debug port pointer gets reassigned to fdserial.
char ch,i;
int z[6];
fdserial *xbee = fdserial_open(11,10,0,9600);
simpleterm_close();
dport_ptr = (fdserial_open(31,30,0,115200));
while(1) {
if(fdserial_rxReady(xbee))
ch = readChar(xbee);
if (ch == 'W') {
for (i = 0;i < 6; i++)
z[i] = readChar(xbee);
}
for (i = 0;i < 6; i++)
writeChar(xbee,z[i]);
putchar(z[i]);
} // end while
return 0; // main's return value
} // end main
I'm very glad to see that others are continuing and progressing with this.
I might not be able to participate so much the coming time, my daughter had a small accident yesterday. Nothing serious, but my priorities are like following:
#1 Family
#2 Family
#3 Family
#4 Work
#5 Hobbies and/or fun
For #4 and #5 I'm still debating if they are in correct order
Comments
First what is the objective of your program?
To type on the SimpleIDE terminal and have it echoed back from Activity Board.
SimpleIDE already has it's internal terminal connected to pins 31,30 and you do not
need to open it yourself to talk to it.
In SimpleText there are several functions at the beginning of the list that do not take
a text_t device as the first parameter. Those functions send to the internal terminal.
Look at my post #170 where I use print Hi There and putchar to clear the screen and
print again in the loop to print what came back from the Activity Board.
Note that for the serial connection to the XBEE I do create a device and use open to
tell it which pins and what baud rate and then I use the functions in SimpleText in the lower
half that take a device as the first parameter.
It looks like you stripped the program down to where it is not a valid program and is time to start
over with something simple and build from there.
What post is Banjo's code you started with I am sure I saw it and I believe he swapped out the terminal
on 31,30 but ask to be sure I am looking at the same listing you are.
Tom
if(n = 5 )
Ron
I believe you are thinking of a set of messages with an id and data to send over to the AB.
When you say 6 bytes and ASCII I am not sure what you mean. Actually it is all bytes whether
binary or text chars but either the messages are all binary or all text strings like S-Records .
I was thinking about this yesterday, will post my experiment.
Tom
I know that I've gotten of the beaten path from banjo's code ,but I'm trying to receive serial data and react to it. I called fdserial , to test out pointers ,then I want to receive one byte of data and if it's a "5" ,print out five. If it is not a 5 just keep echoing the input.
Ron,
I believe (n = 5) means that "n" now is 5 and that (n == 5) is a test to see if n is equal to 5.
Thanks'
Brian
The data is going back and forth just fine as it is but I wanted an extra step to ensure the synchronization is secure and I also wanted a simple checksum to verify the data. I have read about checksums, crc's and byte stuffing and I dont think we need anything as complex as what I have been reading about.
I would love to see what you can come up with, the way I am thinking is a fixed length data packet in both directions. At the moment I am sending and receiving 6 bytes each way and don't really visualize it being any longer.
Jeff
Yes, so you would think that the problem is the choice of input statement, but it
produces the result as expected n=n+1 unless its five.
How many bytes form an integer (2, ? ) how many bytes form a char (1, ?)
I need to play with C again, its been a while.
Cheers
Ron
I put the n = n+1 in there just to see if the data was going though the if...else.
Brian
I even replaced the int n declaration to char n, to see if that changed anything, but no.
It makes no sense to me.
Back to lurking (:
int size is system dependent, but in PropGCC it's 4 bytes (and char is 1). I have a full unit tested list here: https://github.com/libpropeller/libpropeller/blob/master/libpropeller/gcc/gcc.test.h#L161
Brian
@Brian
You are using if (n == 5) SB if (n == '5') Note single quotes to test for the character 5.
cheers
Ron
Ron
Here is forward and reverse w/accel. Tech basic code and activity bot code. Yes I know it's simple ,but it works.
Brian
Edit: code with graphic ,sorry steve for stealing it.
Thanks' for the '5' info
Brian
Throwing an error on the img.loaDIMage("aBot.jpg") because I've been unable to import the image into techBASIC.
Read the help files, no solution. Please tell me how you achieved this seemingly very simple task.
Thanks,
Ken Gracey
You need ITunes on your computer , plug iPad into desktop,select ipad in iTunes , select apps ,choose techBasic and drag jpeg in techBasic ,unplug iPad and it should work.
Brian
Just reading through their docs to find the cause of this error.
Ken Gracey
More importantly I have been trying techBasics error handling routines. I have to admit I spent more time on it than I expected, it took me a while to grasp what the manual was saying.
There are two possible error situations I wanted to handle in particular, both associated with the wifi connection. One is if for any reason the iPad did not receive all or part of the data packet and the second is if the wifi connection should drop out.
The objective is to be able to recover from the above without rebooting the app. I want to test it some more but number one seems to be done so now its on to number two.
The attached screen shot shows the app in an error condition where the transmission from the Prop was disabled. After re-enabling the transmission I was able to reconnect and continue as normal.
Another option now available is the ability to change IP and Port numbers, the app as I have it loads with the defaults shown in the screen shot which works with my XBee.
Jeff
@Ken some of the errors regarding file #1 are the errors I am dealing with now in the error handling routines. Also there was an issue with my spin file to begin with but I updated the zip file and I think that should be ok. Try with what you have and if you are still having problems I will attach the latest zip with images (I have not zipped it up yet)
I've just now caught up to your ad-hoc example up above, and have the connection framework functioning very reliably. Yeah! Took me about two hours to properly set things up (I think the baud rate in your sample Spin program was 115K, but should be 9600, or matched to the XBee WiFi).
Even though the robot is doing nothing it's exciting to see that we've gotten this far. I've always assumed this wouldn't be possible for a bunch of reasons (gotta be an Apple developer, etc.) but it's rewarding to see that we can have two-way communication.
Before I read your post above, and catch up to where you are with this, take me back to your ActivityBotDebug.spin program for a moment. Basically, you've provided a serial framework with communication bytes for whatever we want to send back and forth, right? And you're now looking to us to fill in the framework with useful stuff - value of Ping))), speeds from accelerometer, etc. Am I mostly right? And this is why Brian was pulling out whatever hair he had left - he was trying to get the framework built in C because there are so many useful ActivityBot programs already produced in C.
Let me know if I'm as clueless as I thought, or if I'm understanding what where we are with this project.
Sure appreciate it!
Ken Gracey
This looks like a vast improvement, especially with the error handling.
Seems like the rest of us should be working on the ActivityBot side of things since you've made so much progress on the iPad side of things.
Looks like you've given us an "insert your code here" method:
pub Main | x , y com.start(RX_PIN,TX_PIN,00,BAUD) debug.start( 31,30,00,BAUD) com.rxflush repeat DataOut x:=com.rx case x "W" : get_dataWhere we can do things like provide light levels (two bytes for left/right side), ultrasonic sensor (single byte), LED status (couple bits, or bytes if we want) and speed (two bytes).
These values could be displayed in techBASIC and also be changed through the R/C interface as they are sent back in the get_data method.
Pretty close to what you're thinking? I'm no programmer, but with enough time and help I usually find my way.
Now I'm finding myself in the C or Spin debate. Seems like we should get your Spin program working in C first because we could easily leverage all the useful ActivityBot source code examples. This might be a challenge for me and I see that Brian has already lost some hair over the idea.
Ken Gracey
The app you are running is transmitting 6 bytes and receiving 6 bytes, the fact the received bytes are an echo at the moment does not matter they can be used for any sensor data we wish when we decide what data we want displayed on the iPad. In my opinion 6 bytes is close to being enough but that can be modified.
Brian and Tom have both shown some good C examples I am afraid I am not proficient enough to chip in and help.
I am attaching progress so far, with this one you can test the error handling by pressing the reset button on the Prop. The app will show an error but you should be able to reconnect and continue without rebooting the app once the reset has completed.
I recommend deleting all images and files that are related to this project from your iPad and starting afresh with these new images. The zip contains 8 images 1 techBasic source file on Notepad and a Spin file for testing.
One last thing about the techBasic source you have and something I have been looking at. It's actually working too fast and overunning the wifi buffer, that is my thought right now anyway.The source in this zip slows the rate down. I will continue to monitor this.
Jeff
Good digging on error handling. I will look at it later.
Been working on simple message sending
In the process of debugging first test of code.
Not the final way I want to do it but just testing message parsing in C and
making the messages in Tech Basic.
Just made the LED's on P26 and P27 turn on and off sending a message to AB
Will test send 6 byte message next
Tom
This c stuff is as clear as cream of mushroom soup
Can anyone tell me what is wrong with this code ? It should receive one marker char of either a "X" or a "Y" and then store the next char in separate locations ,then send the 2 values to the serial terminal.
Thanks'
Brian
No problem
Strickly testing out the concept.
We would use messages which have a checksum for testing if valid
We would make up messages to tell the Bot to execute various commands or to
send speed settings etc.
For now I just have two messages, one that has one data byte used in a case statement as if
it came from a keypress on a terminal
The second message just sends 6 known bytes over.
First cut only sending messages from iPad,
This is a test program only actual version will put watching for incoming messages in a seperate cog and
main line code can watch if valid messages are there.
I have code doing that with the Sony Remote but did not want to cloud up the testing with to much .
This gets a message and in fact will wait forever to get it and then processes.it.
The advantage is things happen one at a time.
Parsing messages may work better if the messages coming in are strings and not binary like these as TB
has string functions like LEFT and MID.
The Tech Basic code
REM Test Message sending to Activity Bot Ver 1 DIM Message~(16) xcenter = Graphics.Width/2 DIM quit AS Button quit = Graphics.newButton(xcenter,250) quit.setTitle("Quit") DIM send6 AS Button send6 = Graphics.newButton(xcenter,200,100) send6.setTitle("Send 6 bytes") REM Direct connection ip address Comm.openTCPIP(1, "192.168.1.3", $2616) DIM swP26 as Switch DIM swP27 as Switch DIM lblP26 as Label DIM lblP27 as Label swP26 = Graphics.newSwitch(xcenter,25) !Default to off swP26.setOn(0) swP27 = Graphics.newSwitch(xcenter,65) !Default to off swP27.setOn(0) lblP26 = Graphics.newLabel(xcenter+85,25,100) lblP27 = Graphics.newLabel(xcenter+85,65,100) lblP26.setText("P26LED") lblP27.setText("P27LED") System.showGraphics SUB TxMessage(numbytes AS BYTE) FOR i% = 1 TO numbytes PUT #1,, Message~(i%) NEXT END SUB SUB SendMsgA1(db AS Byte) Message~(1) = $A1 Message~(2) = 2 Message~(3) = db ! Compute the checksum checksum~ = BITNOT(2 + db) + 1 Message~(4) = checksum~ TxMessage(4) END SUB SUB SendMsgA6 !Send known bytes Message~(1) = $A6 Message~(2) = 7 Message~(3) = $01 Message~(4) = $02 Message~(5) = $04 Message~(6) = $08 Message~(7) = $10 Message~(8) = $20 FOR idx = 2 To 8 checksum~ = checksum~ + Message~(idx) NEXT checksum~ = BITNOT(checksum~) +1 Message~(9) = checksum~ TxMessage(9) END SUB SUB valueChanged(ctrl AS Control, time AS DOUBLE) IF ctrl = swP26 THEN IF swP26.isON THEN SendMsgA1(1) ELSE SendMsgA1(2) END IF END IF IF ctrl = swP27 THEN IF swP27.isON THEN SendMsgA1(4) ELSE SendMsgA1(8) END IF END IF END SUB SUB touchUpInside(ctrl AS Button, when AS Double) if ctrl = quit then STOP ELSE IF ctrl = send6 THEN SendMsgA6 end if end subThe C code which is run with the terminal as I print what is happening
Turning the Tech Basic switches on and off turns on and off P26 and P27 LED'S
/* Test message concept Each message will be of the following format MsgId byte Just something made up, maybe lower nibble is length Len byte Number of bytes remaining in message after this byte including chksum byte Data0 byte Data bytes what they mean is message dependent . . Datan byte Checksum Checksum byte, the 2's complement of the sum of all bytes except MsgId Two simple messages for this test A single data byte to simulate switch closure or a key press MsgId = 0xA1 Len = 2 Databyte CheckSum Send six bytes to be processed MsgId = 0xA6 Len = 7 Six Data bytes CheckSum */ #include "simpletools.h" // Include simple tools #include "fdserial.h" #define MAXCHARS 78 /* Parsing the incoming messages requires a state machine driven by each incoming byte from the serial port With the following states */ #define WAIT4MSGID 1 //Get bytes until we see one we know #define GETLENBYTE 2 //Get the number of bytes remaining in message #define GETDATABYTES 3 //Get the data bytes. Len byte - 1 bytes #define GETCHECKSUM 4 //Get checksum byte #define MAXMSGSIZE 16 //Small messages for now // Connections for Activity Bot Board int RX = 10, TX = 9; // XBEEwifi connected pins fdserial *xbwifi; // Serial device to talk to XBEEwifi // An array to hold an incoming message of max length uint8_t MsgBuffer[MAXMSGSIZE]; // Message parsing variables uint8_t rxchar; uint8_t MyChkSum; uint8_t BValue; uint8_t *pRxMsgPtr; uint8_t *pMsgPtr; uint8_t bytecount; uint8_t bytesneeded; int RxMsgState; //Create an array to store 6 byte message values for testing uint8_t Sixbytes[6]; /* For testing of the receive message function. Just define it here for later version launch it into it's own cog to watch for messages and handshake with main line code when message is available */ void RxMessage() { uint8_t chktest; uint8_t idx; //Stand alone version only int ch; // HERE IN STAND ALONE TEST VERSION int msgflag; // Set to 1 to build a new message // State Machine sets it to 0 indicating have a message // When in seperate cog handshake flag will be used //Get a char from serial port wait for it to arrive //In this test version it will hang the system RxMsgState = WAIT4MSGID; // HERE IN STAND ALONE TEST VERSION msgflag = 1; // HERE IN STAND ALONE TEST VERSION idx = 0; // HERE IN STAND ALONE TEST VERSION print("RxMessage Looking\n"); while(msgflag == 1) { rxchar = fdserial_rxChar(xbwifi); // Execute state machine on rxchar switch (RxMsgState) { case WAIT4MSGID: if ( (rxchar == 0xA1) || (rxchar == 0xA6)) { print("\nGot Message %x\n",rxchar); MsgBuffer[idx++] = rxchar; MyChkSum = 0; RxMsgState = GETLENBYTE; } break; case GETLENBYTE: // Already pointing at len byte MsgBuffer[idx++] = rxchar; bytesneeded = (uint8_t)rxchar -1; // Do not include checksum byte bytecount = 0; MyChkSum = (uint8_t)rxchar; // First byte of sum RxMsgState = GETDATABYTES; break; case GETDATABYTES: //Already pointing at next byte MsgBuffer[idx++] = rxchar; MyChkSum += (uint8_t)rxchar; bytecount++; if(bytecount == bytesneeded) { RxMsgState = GETCHECKSUM; } break; case GETCHECKSUM: //Now pointing at checksum byte MsgBuffer[idx] = rxchar; // No need to inc to next byte this time /*Adding the received checksum byte to MyChkSum should be zero if we have a valid checksum because the checksum in message is the negitive of the sum */ chktest = (uint8_t)rxchar + MyChkSum; chktest = chktest & 0xFF; //Only 8 bits wanted if(chktest == 0) { msgflag = 0; // Were done have valid message RxMsgState = WAIT4MSGID; // Redundent in stand alone version } fdserial_rxFlush(xbwifi); // Clear the serial buffer break; } }// End while msgflag } int main() // Main function { uint8_t ix; //Index into MsgBuffer array int ch; // Add startup code here. xbwifi = fdserial_open(RX,TX,0,9600); // Full Duplex serial to XBEE fdserial_rxFlush(xbwifi); // Clear the serial buffer pause(100); RxMsgState = WAIT4MSGID; while(1) { // Add main loop code here. //Get a valid message, waits forever for one RxMessage(); //Process the valid message //Have plenty of time not watching for new message //until done. // Start at beginning of message ix = 0; //Use a case statement to process each type of message switch (MsgBuffer[ix++]) { case 0xA1: print("Message A1\n"); ix++; // Bump index past len byte of message BValue = MsgBuffer[ix]; //Use the byte as if it was a keypress command switch (BValue) { case 1: high(26); // Turn on P26 Led print("P26 ON\n"); break; case 2: low(26); // Turn off P26 Led print("P26 OFF\n"); break; case 4: high(27); // Turn on P27 Led print("P27 ON\n"); break; case 8: low(27); // Turn off P27 Led print("P27 OFF\n"); break; } break; case 0xA6: print("Message A6\n"); ix++; // Bump index past len byte of message for(int b=0;b<6;b++) { Sixbytes[b] = MsgBuffer[ix++]; } for(int br=0;br<6;br++){ print("$%02x ",Sixbytes[br]); } print("\n"); break; }// end switch message } }Here is a little try at your rxArray, Not working yet .I know I'm going to have a "Now I get it" with this c stuff ,but hasn't happen yet.
Brian
#include "simpletools.h"
#include "fdserial.h"
int main(void)
{
extern text_t *dport_ptr; // default debug port pointer gets reassigned to fdserial.
char ch,i;
int z[6];
fdserial *xbee = fdserial_open(11,10,0,9600);
simpleterm_close();
dport_ptr = (fdserial_open(31,30,0,115200));
{
while(1)
if(fdserial_rxReady(xbee))
ch = readChar(xbee);
{
if (ch == 'W');
{
for (i = 0;i < 6; i++);
z = readChar(xbee);
}
{
for (i = 0;i < 6; i++);
writeChar(xbee,z);
putchar(z);
}
}
}
}
This is a great tutorial:
http://www.cprogramming.com/tutorial/c-tutorial.html
This may be helpful too:
http://www.cplusplus.com/doc/tutorial/control/
That one is C++, but most of C++ syntax is C.
The code below has correct syntax, but I have no idea if it will do what you need.
I indent to keep track of what the code is doing in my mind. The braces {} are there for correctness and communicating what the code is expected to do. It is not a comment in C.
#include "simpletools.h" #include "fdserial.h" int main(void) { extern text_t *dport_ptr; // default debug port pointer gets reassigned to fdserial. char ch,i; int z[6]; fdserial *xbee = fdserial_open(11,10,0,9600); simpleterm_close(); dport_ptr = (fdserial_open(31,30,0,115200)); while(1) { if(fdserial_rxReady(xbee)) ch = readChar(xbee); if (ch == 'W') { for (i = 0;i < 6; i++) z[i] = readChar(xbee); } for (i = 0;i < 6; i++) writeChar(xbee,z[i]); putchar(z[i]); } // end while return 0; // main's return value } // end mainI might not be able to participate so much the coming time, my daughter had a small accident yesterday. Nothing serious, but my priorities are like following:
#1 Family
#2 Family
#3 Family
#4 Work
#5 Hobbies and/or fun
For #4 and #5 I'm still debating if they are in correct order
Hope your family is doing well.
@ Steve,
Thanks' , so much reading ,so little time
@Jeff,
Try this code ,not perfect - but it's a start
Edit : take semicolons off the 2 for loops, thought I did that already, must not saved it that way.