Dancing Tinkerbell for a pirate magician

@robotbuilder Hard wire connection between the arduinos is not an option, nor a viable test scenario. The radio com works perfectly. The problem is the timing of the check radio for data feature.

@zander Thanks, this is helpful. I can see where there could be left over data if I don't flush the buffer, but on the first read that shouldn't be the case. When the read fails it completely fails. That is to say, if I just read the radio over and over in the loop, doing nothing else, I get the messages exactly correct, every time. I can send hundreds of key presses and see them in the monitor.

"Tinkerbell: 1"

"Tinkerbell: 2" etc. I can reproduce this as many times as I want.

Then when I run a function between calls to recv I get

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The data I get is displayed above the row of ^^^^.  It's the blank space. Also known as the empty string, also known as hair pulling aggravation.  So spurious left overs isn't what is happening.

loop {

if recv ( params here)

  display results

} // this works

loop {

do something

if recv ( params)

  display results

} // doesn't work

@robotbuilder Ok, but the receiver is gathering data on a timer interrupt driven basis. I call "recv" which checks function "available()" and if there is data in the buffer, it copies it to the buffer with a memcpy statement. Thus, the data should be there when I return from some other function because the work was done behind the scenes with the timer interrupt.

@eliza When you have an unthrottled input like the radio, it MUST be the highest priority task otherwise data can be lost. Output we can buffer, but input HAS to be processed as soon as it arrives. One possibility is an interrupt attached to the relevant pin. When the interrupt happens the routine you passed to the interrupt handler runs immediately. Now normally we want to put the minimum code in the ISR but for this case you have to drain the input line. Perhaps you are not aware, but you can force code such as an ISR to execute in the faster RAM memory. You do that by adding IRAM_ATTR between the void and the function name. I am not sure, but disabling interrupts may be needed as well (in REF manual on arduino.cc website), marking code as critical using CRITICAL section markers may also be needed. See HERE but ignore the 'do as little as possible' warnings as this is an unthrottled IO operation as noted above.

Another approach may be to do 'normal' minimal ISR code to set a flag and then in the main loop when the flag is true it might be possible to modify the &buflen argument to only get a small number of bytes. Of course you will need bookkeeping on the count.

Once you are ready, if you want/need more help be prepared to publish the entire code and circuit diagrams. Copy paste the code using the std tools described in the HELP.

Good luck.

@eliza Obviously, for a more complex real world app like what you are preparing it won't work.

@eliza Your example makes no sense.

@eliza I doubt it's a TIMER interrupt, it should be a PIN interrupt. This is NOT a time driven thing, it's a data ready NOW driven thing.

@eliza 

@robotbuilder Hard wire connection between the arduinos is not an option, nor a viable test scenario. The radio com works perfectly. The problem is the timing of the check radio for data feature.

From the point of view of the software on the transmitter arduino that converts the text to a stream of on/off values at the output pin and the software on the receiver arduino that converts the stream of on/off values at the input pin back to a string there no difference. When you say "check radio for data" you are in fact checking the input pin for data. How it got there is not relevant to that process. I don't have the radio/receiver interface. I understand you would be using the modules not a wire.

@robotbuilder Ok, but the receiver is gathering data on a timer interrupt driven basis. I call "recv" which checks function "available()" and if there is data in the buffer, it copies it to the buffer with a memcpy statement. Thus, the data should be there when I return from some other function because the work was done behind the scenes with the timer interrupt.

We will work it out 🙂  I am just tied up most of the day with other things so unless you can figure it out yourself or someone else figures it out in the mean time it will just have to wait.

I’m coding a timer ISR and have it ready to test so I can check recv() quickly and often. Just as I got that ready for the first test ALL of the LEDs went haywire for no explainable reason

Back at it tomorrow 

Thanks for the comments 

@zander I used he interrupts with a single arduino & it worked great 

Now I want to use the radios. I am putting the recv() call into a timer interrupt. 
ASK uses timer 1 so I’m trying timer 3 (mega) using same structure that worked before 

@eliza Ok, good luck.

@eliza Ok, good luck.

@eliza

Posted by: @eliza

@frogandtoad I'm not exceeding maximum transmission of bytes. I'm transmitting 14 bytes every minute or so. If I "do nothing" between calls to recv it works perfectly. If I "do something" between calls to recv I get no data at all. I shortened my "do something" function to "do almost nothing" and it works perfectly. I need to do more than "almost nothing" between calls to the recv function. After I pared the function down to useless I can get the radio transmission.

I can't understand why data aren't held in the buffer long enough for me to do something and then check the radio transmission.

No worries, I asked as a process of elimination, but without seeing all of your code, we can only keep playing the guessing game.  History tells us, that most of the time it's a program issue, and that the person coding it can't see the problem, whereas a fresh set of eyes just might.

Any chance you can post the full code?

Cheers

@zander There is no pin connected to anything. Thus, no way to detect a pin change.

@robotbuilder I'm not checking any input pin for change, or data. I'm calling a function that returns true or false. When true there is data in a char array that was copied with a memcpy method.