JP1 Remotes

It looks like jp12serial is the "API" between other JPx tools and the hardware interfaces.

Since FTDI is "baked in" on Linux, the Linux code path for jp12serial is pretty agnostic to the usb converter used, so I can use any usb converter I like.

However, on Windows, it assumes that FTDI is the usb converter exclusively!

How do I then, make jp12serial work with usb converters that are NOT FTDI (but implement Tx break and RTS/DTR correctly) - for example the CP2102, and coming soon my own PIC18F based interface?

Would it involve creating separate code-paths for each custom driver using a maze of ifdef statements?

I do not believe the assertion in bold is correct; in fact JP12Serial has been used with Prolific chipsets for years to communicate with remotes. In principle, any USB serial converter to TTL-type signals should work. The Widgets (as opposed to remotes) I'm aware of all use FTDI chips, and JP12Serial does look for that chipset first, but it doesn't preclude use of other chipsets, I think.

For the 2102, see this comment by Kevin Timmerman. Depending on the remote type, it probably won't work, but the issue is not in JP12Serial.

The Prolific chips are also problematic, in part because the chips are frequently counterfeit, and Prolific has allegedly put traps in their drivers. Additionally, it seems that these chips (at least as implemented in the DIY Gadget cables) don't always recognize both low and high levels while reading from the remotes. We see this especially with JP2 (MAXQ) remotes.

BTW, I think at least some of the comments in JP12Serial.cpp regarding high/low levels on IDC pin numbers are incorrect.

3FG wrote:I do not believe the assertion in bold is correct; in fact JP12Serial has been used with Prolific chipsets for years to communicate with remotes. In principle, any USB serial converter to TTL-type signals should work. The Widgets (as opposed to remotes) I'm aware of all use FTDI chips, and JP12Serial does look for that chipset first, but it doesn't preclude use of other chipsets, I think.

You are correct - this is what I do when I am awake for 12 hour straight and read through dense specs and C code, and then printout the FTDI headers while thinking they are the JP12Serial headers and finish the day with the conclusion.

JP12Serial is pretty agnostic to the underlying chipset and uses FTDI library to enhance port lookups.

My bad.

3FG wrote:Additionally, it seems that these chips (at least as implemented in the DIY Gadget cables) don't always recognize both low and high levels while reading from the remotes. We see this especially with JP2 (MAXQ) remotes.

More details on the "recognize both low and high levels" please?

3FG wrote:BTW, I think at least some of the comments in JP12Serial.cpp regarding high/low levels on IDC pin numbers are incorrect.

What confuses me is that there are two separate "enter programming mode" sequence for JP1.3 and JP1.2/JP1.3.

As far as I could make out - the JP1.3 sequence (with RTS low) would work for JP1.2 as well?

With the MAXQ processor (JP2), the DIY Gadget (Prolific) JP1.3 interfaces seem to be able to send data to the remote correctly, but the response is generally wrong, and sometimes shorter than expected. I interpret this as the interface can't reliably detect when its Rx line has been driven low (or perhaps high). I don't know any details of the circuitry in these interfaces.

https://www.hifi-remote.com/forums/viewt ... p?p=106972

3FG wrote:With the MAXQ processor (JP2), the DIY Gadget (Prolific) JP1.3 interfaces seem to be able to send data to the remote correctly, but the response is generally wrong, and sometimes shorter than expected. I interpret this as the interface can't reliably detect when its Rx line has been driven low (or perhaps high)

Sounds like a level shifter issue. The PL2303 specs notify support of 3 voltage levels which should do away this issue but it requires the adapter to implement it correctly (which might not happen in cheap adapters or fake chipsets)

Once I am done with JP1.x, I will look into this (.. and not require FTDI chipset at all)

I would like to make some custom changes to the code and recompile this DLL: Will it compile (correctly and run without issues) if I use this: http://mingw-w64.sourceforge.net/

Or is it this that I should be using: http://www.mingw.org/

I am confused.

carsonlittle wrote:I would like to make some custom changes to the code and recompile this DLL: Will it compile (correctly and run without issues) if I use this: http://mingw-w64.sourceforge.net/

Or is it this that I should be using: http://www.mingw.org/

I am confused.

The version packaged so far seems to be built using the toolchain from http://www.mingw.org/.

I am trying to make it work using http://mingw-w64.sourceforge.net/ here:
https://www.hifi-remote.com/forums/viewforum.php?f=9

So far it looks good