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;)
-----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Peter Stuge Sent: Thursday, December 30, 2004 1:57 PM To: LinuxBIOS 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 this.
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 precision.
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 USB.
Hope it works out though!
//Peter _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios