So the project I'm working on is an Autonomous Trailer Hitching Robot, where we plan to use many many many forms of sensors (IMU, GPS, Ultrasound, Current Sensors, etc etc etc) to take a trailer over to a hitch ball and set it upon it with the push of a button.
With that being said, we are using two arduino megas communicating over serial with each other (one as a movement brain and one as advanced sensory). Obviously I am concerned about timing requirements for each sensor to transmit it's data to the micro and to not be held up waiting for counting or timing.
So...for counting the pulses off of our motor encoders I recently found the 74HC4020 which can do the counting and transpose the number to binary (the amount of pins used in this situation is of no issue) so that saves the micro from being either interrupted or waiting for pulses...
My question is does something exist to do the same kind of intermediate processing for an ultrasound sensor with a trigger and echo pin....perhaps something that can measure a time delay between two inputs? The sensor is an HC-SR04 btw...
Basically I want to convert any sensor that could cause a timing issue to some form of digital or analog input that can be read in the downtime between other crucial steps (such as user input from our controller in manual mode or other data) without sacrificing much sample time.
Dedicated logic could do what you want. Most would implement it either a PLD or CPLD. Bare decade counters and octal latches could be configured to accomplish what you want. But you need to formalize the design requirement before you build it. Software is easily mutable, hardware is fixed.
Depending on the complexity of your sensors you could use Arduino Chips as I2C slave device. Each slave would control a sensor, or a group of sensors. They would have the control logic to do their simple task only. Complex integration would be handled by a Master processor.
Also on an unrelated topic, is there a way to offset serial data on the mega so that two serial data streams are not competing for processing time? Ex. GPS data and Arduino communication. I'm just not sure how the mega handles it's different channels of serial data.
The serial processing on Arduino's are interrupt driven. Each byte in causes an interrupt to service that received byte. The 'new' byte is added to the end of the received data buffer, and the buffer pointer is incremented if possible. If the buffer is full, it overwrite the last byte received.
Outgoing data is processed the same way. The UART hardware has a two byte output pipe, the the TX buffer is a single byte register that holds the 'next' byte to be send. The Shift register holds the current byte being send. It sends each bit out it's shift register, when the last of the data bits have been send it transfer the 'next' byte from the UDR TX register to the shift register, issues a UDRE interrupt(which the Arduino HardwareSerial object answers by moving data from its 64byte output buffer to the UDR register). if the UDR register was empty it will issue a TXC (transmission complete interrupt) when the last bit + parity + stop bits has been shifted out.
The Mega has four hardware Serial UARTS, if you had all four of them sending and receiving at 115,200 baud, they are only moving 2X4 bytes 11,500 times a second or less than 100k bytes a second. The Mega runs at 16mhz, and can actually execute one instruction most clock cycles so you can execute over 160 instructions per character moved. You will have to do some cycle counting to see exactly howmany cycles are required to service each interrupt, I expect somewhere between 10 and 50. With these rough guesses, supporting the serial streams takes between 1/3 and 1/16 of the total performance of the processor.
How much data are you moving per second? You should not be receiving 11kps from a GPS sensor?
If 16mhz Mega's are not fast enough, look at the SAM D20E 32bit (48mhz, 128k pgm, 16k ram). They are less than $4 in single qty, $1.75 @2000.