September 25, 2017, 03:34:57 pm
News:
Pages: 1 ... 8 9 [10]
 91 
 on: January 09, 2013, 03:19:27 pm 
Started by greyback - Last post by heyrick
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

 92 
 on: January 09, 2013, 10:29:58 am 
Started by greyback - Last post by pfft2001

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.

 93 
 on: January 08, 2013, 08:12:35 pm 
Started by greyback - Last post by heyrick
I am also curious to know... According to me, it is not possible...

Correct.
Serial mice need both RTS and DTR to be positive (this is what provides power to the mouse). Toggling DTR will soft-reset the mouse (it should reply with 0x45), and toggling RTS for at least 100ms will hard-reset the mouse. When the computer boots from cold, RTS usually defaults to negative, so this will hard-reset the mouse on power-up.

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...

Gerry - if you're still around these parts, did you get any further with webkit or Qt4? Do you have any executables to download and install/run? Cheesy

 94 
 on: December 31, 2012, 02:30:25 am 
Started by greyback - Last post by alexemil5
Just wondering if it would be possible to use the RS232 port for the mouse?

I am also curious to know... According to me, it is not possible...

 95 
 on: December 25, 2012, 06:33:53 am 
Started by heyrick - Last post by heyrick
Hi all!

This is the time of year when the OSD comes into its own - Ratatouille, Ponyo, Detective Dee and The Mystery of the Phantom Flame (!), Dr. Who, etc etc; scheduled and recorded for watching later on... So much more flexible than videotape!

So, whoo. Merry Christmas all!
[or "Happy Holidays" if you're non-Christian]

 96 
 on: December 05, 2012, 02:13:24 pm 
Started by gtibay04 - Last post by gtibay04
Awesome, thanks. I'll try getting a cheap one first to test the functionality.

 97 
 on: December 03, 2012, 09:33:45 am 
Started by pfft2001 - Last post by pfft2001
Update:

According to http://pinoutsguide.com/DigitalCameras/tvout_rca_pinout.shtml, the pinout used on the OSD is the standard for camcorders.

And, it looks like you can buy them here: http://www.techcables.com/3-ft-3-5mm-4-pole-mini-av-to-3-rca-camcorder-a-v-cable-p-44.html for $3.  Yey!

I can now confirm that the cables from techcables do, in fact, work on the OSD.  Yey!

 98 
 on: December 03, 2012, 07:33:25 am 
Started by gtibay04 - Last post by ChadV
As far as I know the database is mostly available for all models...  I know my Harmony One can download the OSD settings.  It's really very nice, since it automates so much of what you need to do (you tell it what device controls volume, what needs turned on in what order, etc.).

 99 
 on: December 03, 2012, 01:38:05 am 
Started by gtibay04 - Last post by gtibay04
Thanks Chad. Question with the Harmony remotes... I've never been one for universals but I looked up some basics on them... are there specific model numbers of the remote that can get the OSD control or can I just buy the cheaper old model from ebay (I think the cheapest was the 880) and it is capable of downloading the programming from the database?

 100 
 on: December 02, 2012, 08:50:11 am 
Started by gtibay04 - Last post by ChadV
The OSD is in the Logitech Harmony database, but I'm not sure if an $80 remote is worth it for most people.  (Though, they do control a whole entertainment center, so that might work for you.)

Alternately, you can *try* Sony VCR codes on a regular universal remote, and it usually works for some of the functionality.

Pages: 1 ... 8 9 [10]