At 115200 we expect ~100us between interrupts, or around 5% CPU overhead. 4us latency is probably acceptable for servo signal jitter too if we decide to consider using the Arduino Servo library.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@513 f9c3cf11-9bcb-44bc-f272-b75c42450872
This provides an opportunity for saving memory in the case of ports that do little or no work (e.g. the console) as well as increasing buffering for ports that receive large amounts of data in a short time (e.g. high-bitrate NMEA).
git-svn-id: https://arducopter.googlecode.com/svn/trunk@425 f9c3cf11-9bcb-44bc-f272-b75c42450872
bytes by shrinking the constructor.
I don't quite understand why g++ is emitting two identical copies of
the ctor, but it wastes a bunch of space. 8(
Integrate FastSerial with the C library's standard I/O. Add new
::printf and ::printf_P methods that do the obvious thing, and a
::getfd method so that a caller can use the other stdio functions with
the port if that's interesting.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@361 f9c3cf11-9bcb-44bc-f272-b75c42450872
creating port drivers for ports that aren't used.
This lets us save the RAM (~200 bytes per port) that would otherwise
have been used for buffers. It also frees up the port's interrupt
vectors so that on Mega we can use the ports for other things
(e.g. SPI Master mode).
Better to fix this now than later when we have more consumers.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@355 f9c3cf11-9bcb-44bc-f272-b75c42450872
The receive side is basically a copy of the HardwareSerial driver, whilst the transmit side
uses the same algorithm as the APM_FastSerial driver.
See the example sketch for usage details.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@276 f9c3cf11-9bcb-44bc-f272-b75c42450872
DrZiplok@gmail.com
analoguedevices