this allows us to put a serial port into non-blocking mode, so that
writes that don't fit in the transmit buffer are dropped. This will be
used in flight to prevent stray printf() calls from causing large time
delays in the code
space() was actually intended to be tx buffer space, it just had a
bug. The name txspace() is clearer however, and should prevent
confusion as to which buffer its for
git-svn-id: https://arducopter.googlecode.com/svn/trunk@3247 f9c3cf11-9bcb-44bc-f272-b75c42450872
This can make re-opening a port faster (as the free/malloc pair can be avoided) and possibly more robust (in the case where e.g. the heap has been corrupted).
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1479 f9c3cf11-9bcb-44bc-f272-b75c42450872
Add support for re-opening a port without changing the baudrate or buffer sizes. By passing zero for the parameters that aren't to be changed, code can reconfigure a port without needing to know how it was originally configured.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1462 f9c3cf11-9bcb-44bc-f272-b75c42450872
Drop some unused, old vector code.
Strip the UDR pointer from the class instance, since it's never used.
Fix up the comment describing RAM savings.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1145 f9c3cf11-9bcb-44bc-f272-b75c42450872
Strip the stdio integration from FastSerial as we aren't using it and it just wastes space.
Note that this does not attempt to fix the bogus floating point handling in ::print(ln). That's an issue for another day.
BetterStream::printf(_P) aka FastSerial::printf(_P) support is now as documented for avr-libc printf with floating point support enabled.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@895 f9c3cf11-9bcb-44bc-f272-b75c42450872
Add print_P and println_P implementations to give folks wedded to the vanilla Stream methods a way to print PROGMEM strings.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@715 f9c3cf11-9bcb-44bc-f272-b75c42450872
Verified that when configured for 115200, the actual output as seen on a scope is around 117600Hz consistent with the +2.1% error in the datasheet.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@542 f9c3cf11-9bcb-44bc-f272-b75c42450872
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
Andrew Tridgell
Randy Mackay
Mike Smith
James Goppert
tridge60@gmail.com
DrZiplok
james.goppert
mich146@hotmail.com
DrZiplok@gmail.com
rmackay9@yahoo.com
analoguedevices