Nice read Peter, thank you for the info:)
Would be nice to use some voltage reference differencing
Instead of using a Max 232, but the Max is probably a cleaner approach.
A nerdy aside, I heard the 18F4550 and 18F2550 can run up to 12MIPs from
a 4MHz crystal, they've got a whopping 16K of flash, and they have a
Full-Speed USB v2.0 hardware.
Now if I could only run Linux on a PIC;)
[mailto:email@example.com] On Behalf Of Peter Stuge
Sent: Thursday, December 30, 2004 1:57 PM
Subject: Re: Memtest+
On Wed, Dec 29, 2004 at 04:58:57PM -0500, Dave Aubin wrote:
Has no one else hit this? One idea I have being a
PIC lover is To
use some LED's on the mother board and make a serial protocol Over the
LED's, much like a software UART for a PIC.
Anyone have an input on this?
That will work just fine, but watch out for running the "GPIO serial
bus" too fast for the PIC.
(With GPIO I'm referring to pins driving the LEDs on the target system,
not a PIC GPIO port.)
If simplex is fun enough, you could use a single GPIO pin and connect
that to RX on the PIC, connect TX on the PIC to a MAX232 and plug that
into a regular serial port on a PC running a terminal emulator.
All the PIC has to do then is read from RCREG and send everything back
out through TXREG. Any PIC with a USART in async mode should do for
For duplex (etherboot/filo menu) you may need a separate GPIO pin for
flow control, the usual serial start/stop bit handshake may not be very
reliable without a hardware UART on the target system. The easy solution
is to use a synchronous serial interface instead; add a clock signal
driven by the target. This also overcomes any problems caused by the PIC
baud rate generator being controllable only with relatively low
The 16F87x series have both an MSSP and a USART; the MSSP could be used
in SPI Slave mode for duplex communication with the target system, and
the USART for talking to the PC running the terminal emulator. One thing
to keep in mind is that SPI always transmits data in both directions,
this means that the serial port wont be 8-bit clean unless you make a
small protocol to indicate when data actually is available, this wastes
twice the bandwidth, but may still be good enough.
A USB device with a 16C745 or possibly 18F2550 if they can be sourced is
tempting, but that also requires writing some kind of driver for the USB
device, or figuring out how an existing USB<->serial adapter works and
reimplementing that. Too much work. Plus the 16C7x5 only do low-speed
Hope it works out though!
Linuxbios mailing list