CharlesLinquist:
My dream is to find an ISR that looks for a START byte (0xFE), and when received, grabs the next byte (data length) and then loads (data length +6) bytes, set a flag and exit - all in the background.
That's just a dream.
It would be totally impractical to have an ISR hanging around twiddling its thumbs while slow serial data arrives or fails to arrive.
I reckon the general approach that I suggested in Reply #8 will do what you want. Why not give it a try? The worst that can happen is that you waste an hour of your time.
No, I don't mean the ISR would wait for the data.But it could process the packet byte-by-byte in the background.
if Flag set -> get next byte -> store in var length, If length > 0 -> grab next length +6 bytes (byte by byte). When the the number of bytes = length + 6, set DONE flag.
In MAIN:
Check for DONE flag, read bytes, calc checksum, clear DONE flag, length var, and START flag.
All ports are bidirectional. Data is received from either 915Mhz radio or 4G on port A or port B. Validated data is then sent out to the flight controller connected to port C. But data received from the flight controller on port C is always sent out to both the 915Mhz radio and the 4G link using ports A and B.
Because the data is always sent out two ways, the receiver can automatically pick whichever one is currently available.
The above scheme works very well with my current PIC-based system. But as I mentioned before, I cannot easily add object avoidance to the current system without a lot of work. I would have the Raspberry pi do more, but I use it to process live streaming HD video over the 4G link (using webRTC). And it doesn't have enough serial ports (without translators) anyway.
It is true that I don't have live video without 4G, but that isn't as important as telemetry, control and object avoidance, since I usually fly "full Auto". And I store the video locally for later retrieval anyway.
CharlesLinquist:
All ports are bidirectional. Data is received from either 915Mhz radio or 4G on port A or port B. Validated data is then sent out to the flight controller connected to port C. But data received from the flight controller on port C is always sent out to both the 915Mhz radio and the 4G link using ports A and B.
Thanks. That explains why there needs to be validation for port C.
But I still have not heard any reasons why my suggested approach is not practical.
After writing with PBP for so long, I get frustrated with Arduino. In PBP (in a PIC), I know EXACTLY what is going on since I write my own ISR's and (more or less) manipulate the hardware directly. With Arduino libraries, I have to inspect them in detail to figure out what is going on "under the hood" - and I'm not yet that familiar with the code flow to understand everything. I'm probably LESS skilled at Arduino code than most beginners because I am so familiar with PBP. I'll get it eventually.
My dream is to find an ISR that looks for a START byte (0xFE), and when received, grabs the next byte (data length) and then loads (data length +6) bytes, set a flag and exit - all in the background.
You can do this sort of thing by putting a state machine in the ISR, which would then essentially queue packets to the application, instead of individual bytes. But it does mean that you replace the normal Arduino-core-provided ISRs with your own code, which is easier said than done in the arduino world.
You should also worry about implementing some sort of timeout to handle missing data - what if it tells you there are 30 bytes, and then you only get 28 bytes...