Society of Robots - Robot Forum
Software => Software => Topic started by: frank26080115 on February 21, 2008, 04:36:27 PM
-
In the spirit of bulletproofing wireless data transmission, my robot's base station will send out a "start condition". I am using AVRGCC.
The start condition is that the bit 7 of the byte is 1, ALL actual data bytes are 4 bit nibbles and not 8 bit bytes (the 4 bits are stringed back together my the microcontroller). so the start condition is unique.
In the best case scenario, the robot gets the start condition, responds with an acknowledgment, the base station receives the acknowledgment, then A FIXED AMOUNT of data is exchanged, and then both devices idle their radio to deal with other processes.
In the worst case scenario, bytes are missing, the start condition happens again but not expected.
My solution is to insert assembly code with (this goes at the beginning of the radioCom procedure
__asm__ __volatile__("radioComBeginLabel: nop\n\t");
and in the receiving function looks like
uint8_t norReadSplit()
{
uint8_t data;
uint8_t temp1 = norRead(); // read from FIFO buffer
if(bit_is_clear(temp1, 7))
{
iniRx = temp1;
__asm__ __volatile__("randomasslabel1: rjmp radioComBeginLabel\n\t");
}
temp1 <<= 4;
uint8_t temp2 = norRead();
if(bit_is_clear(temp2, 7))
{
iniRx = temp2;
__asm__ __volatile__("randomasslabel2: rjmp radioComBeginLabel\n\t");
}
data = temp2 + temp1;
return data;
}
(NOTE, waiting is done in another function with a timeout failsafe, so waiting is not needed here)
My question is, is there any other pointers/program counters that should be changed? Is there another way to accomplish the same goal?
The radios are Nordic nRF24L01 modules from SparkFun, the microcontroller is the massive yet DIP ATMEGA644
-
nay.
C already has the goto statement.
here is a sample:
{
//somecode
if(x>100){ goto HERE;}
//some code
HERE:
//some code
}
-
it doesn't work from one function to another
-
I'm not sure exactly what your doing or why the goto statment is necessary but there has to be a better way. Thats just asking for trouble with the processor to goto within a function. If you don't come back to that function just right you could just get lost in the code or some other strange error like your variables being overwritten and you loss the data anyway. Can't you put the comm code into another function and call that function from within the other function?
not sure if your radios will support this but a unique start/stop sequence I ran into with DMX lighting protocals is that the transmitter sends the 0 condition for 88us or more. It then transmits serial data down the line like normal at 250 kbits/s. The time frame This 88us pulse is longer then the 8 bit serial sequence at 250 kbits/s. That way you can't just send a 0ed byte down the line to activate it. The DMX protocol runs on RS-485 and is a wired application. So it might not transfer over to the radios nicely. But if you can get your radio to just send a specific time frame of 0s thats longer then a normal byte plus start/stop conditions it would then look for the specific sequence of bytes after that. DMX has 512 possible channels so all the devices look for a specific "channel" on the string. If your channel 12 you wait for the start bit and then count 12 bytes and take that one as your in this case percent of power to the light bulb. Not sure if this will work with your setup but I hope it helps
-
If you have to use GOTO, I would say you have a huge design flaw in your program. Forcing a weird GOTO statement using assembly is even worse.
-
Do you have libc? try longjmp() - if not might want to check out a libc implementation to see how they do it.
-
In the best case scenario, the robot gets the start condition, responds with an acknowledgment, the base station receives the acknowledgment, then A FIXED AMOUNT of data is exchanged, and then both devices idle their radio to deal with other processes.
In the worst case scenario, bytes are missing, the start condition happens again but not expected.
How about the robots run a small program to verify the data is correct, and send out a 'please repeat' call if it isn't.
Or perhaps time-outs when no data is received to reset everything.