April 25, 2017, 03:25:49 am
News:
Pages: 1 [2]
Print
Author Topic: WebKit on the OSD  (Read 13076 times)
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #15 on: January 09, 2013, 10:29:58 am »


This is one of the things that bugs the hell out of me with respect to the OSDs, the RPis, the Beagles, etc. The serial port implementation is extremely minimal (RX/TX/GND); but it just so happens that a heck of a lot of serial-using hardware (for example the Psion 3a link) requires the additional pins as it signals out-of-band stuff, like, say "device connected" plus taking power from one or more of the pins. Hmm...

Keep in mind that for most of the things to which refer (but not the OSD), the serial port implementation is not only "minimal" (a good description), but is also only 3.3V.  So, you generally need a converter board in order to use them with anything non-3V3.  So, that board might as well supply the rest of the pins/signals/power.
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 338



View Profile WWW
« Reply #16 on: January 09, 2013, 03:19:27 pm »

Keep in mind that for most of the things to which refer (but not the OSD), the serial port implementation is not only "minimal" (a good description), but is also only 3.3V.

The Beagle (at least the xM, don't remember about the older/slower one) has a MAX-blah line driver chip so it has a regular serial port... though wired unusually (needs a modem cable (straight-through), not a computer link cable (TX/RX cross-over)). It is almost as if they are going out of their way to be a pain [thinks of the OSD having the wrong gender plug on the end of the serial lead!]. Wink


Quote
So, that board might as well supply the rest of the pins/signals/power.

Therein lies the second part of the problem. The SoC has a UART. Well, modern SoCs have several for various different reasons. But let's assume we have a UART and it behaves in a 16550-like manner. There will be some GPIO kicking around to provide the serial output. For those unfamiliar with System-on-(a)-Chip (SoC), there are like a hundred I/O pins and several hundred things that can be done. Depending on the chip, each pin could have five or six different functions, and it is up to the bootloader and OS to set them up according to the hardware configuration. Now, minimal serial is easy to do (two pins), easy to implement (two wires, a single bi-di line driver), and actually has a purpose; mid-level debugging (higher than JTAG, lower then using the command line) can work over serial, plus it's often the only way to talk to the bootloader if it all seems to go wrong.
True serial, on the other hand, requires a more capable line driver, seven or eight I/O pins, and a rather more complicated circuit - for a function that may be less necessary than, say, an SD card interface.

So we run into the problems: 1, are the necessary pins being used for different functions? and 2, are they tracked out to where we stand a hope of being able to access them? For this reason, even having an adapter board would often make no difference whatsoever. You might be able to fake up enough to run a serial mouse, however anything that uses the extra pins for signalling (ie RTS/CTS flow control) won't be able to do so. As these things are supposed to go into the UART to be handled by the serial hardware. It is technically possible to route the signals to GPIO and do it in software...just as it is technically possible to implement a serial port with GPIO but it's an ugly thing to do [see note].

So. Grr-aargh!, as the Mutant Enemy said so eloquently.


Best wishes,

Rick.


Long nerdy note: For reception, you need to figure out your clock rate, 19200bps is 19,200 potential changes per second. Then you need to work out a 4x oversample to be sure you are reading a true level and not a glitch. This means you need to read the serial GPIO pin 76,800 times per second, at as close to 13.025uS per bit (although you can (re)synchronise with the start bit). You'll find code kicking around for PICs that doesn't oversample, but that's possibly due to getting a low clock-rate PIC to run at those sorts of speeds is asking a lot (single sample is less reliable unless you can be absolutely damn certain you will always sample right in the middle of a clock period; but it only needs to run at 52.1uS/bit). Due to the necessity to run to exact timings, you will need to know your instruction set very well to pad out the code so whatever path it takes it will always run to the same number of clock cycles plus disable all interrupts during the serial read. Your processor will need to do nothing but look at the serial input.
For transmission, it is pretty much the same story; but you can run a little slower - there's no need to set the IO pins more times than necessary so the 52.1uS timing will do. Note, however, that serial hardware only has a limited capacity for dealing with bitrate errors, so your processor will have to not only always take the exact same time per bit, there can be no interruptions of any sort. So your processor will need to do nothing but set the serial output.
And this is only for reliable 19,200bps operation!

In essence, it is a damned freaky way to take a GHz(ish) modern multi-core processor and coerce it into doing what a $5 thirty-year-old chip can do effortlessly. Cool
Logged
Pages: 1 [2]
Print
Jump to: