The future of JP1 in the 64-bit world

[3FG]

Looking at the Delcom site it appears that they have source code for some of their apps available. Therefore, would it be possible to create our own 64 bit driver using any of the source code that they have provided?

I think (probably because I haven't examined the problem sufficiently ) that the software would be fairly easy to write. The documentation from Delcom is helpful, but two other resources are key.

1. Microsoft released, a year or two ago, the WinUSB driver. It was made available originally for Vista, but is also now available for XP (at least SP2), and of course Windows 7. It is much simpler to use than writing a kernal-level driver (e.g. the Delcom driver) or using DeviceIOControl with the setupapi.dll. WinUSB is itself a kernal-mode driver, and so it hides the details of a 64 bit versus 32 bit OS. Instead it exposes an API to the application. It does have a limitation: only one application at a time can access the device (e.g. the JP1 interface.) For us, that's not significant.

2. Lakeview Research (the technical writer Jan Axelson, actually) provides free unrestricted code for a variety of USB situations. I used one of her demo programs for USB recently, and it took me longer to get Visual Studio installed than to get meaningful exchanges going with the USB device.

The WinUSB driver should make interfacing to the Delcom chips about the same level of difficulty as using a HID device. And a lot of the coding work, including understanding how to get started with WinUSB, has already been done.

Microsoft--How to interface to WinUSB
Laveview Research WinUSB page

I would be willing to work on this, since I have some, but not extensive, background in programming and interfacing to Cypress USB micros. If this idea is interesting, and not obviously a non-starter, I would want to borrow a JP1 cable and remote. I use 32 bit XP, and intend to continue with that OS, so I would need willing and patient testers who have an unsupported OS. Preferably, Tommy would provide me with the exact chip identification. I'd also need some help in understanding how to hook into IR.exe. I am a little bit familiar with the serial dll, but I have no idea how the I2C stuff hooks in.

[Thomas]

Robman,
True, PDIP is much easier to breadboard, but vendors sometimes do not stock some EEPROMs in PDIP form - 24Cxx series should not be a problem.

I dredged up Tommy Tyler's 2002 post on building JP1 interface with theory of operation. Have on hand some 93LC86s and 25LC640s and an FTDI MM232 breakout board. Should be enough to start analyzing. My system is XP/SP3 with stock USB ports and FTDI 2.0.4.16 32-bit drivers. Goal is to get handshake signals to switch fast enough to read/write EEPROMs at a reasonable speed. Going to ignore the parallel version for now.

Will also look at URLs that 3FG mentioned (thanks!)

[Thomas]

For JP1<>USB, I have not had any success with the handshake signals via FTDI. I scrounged a 24C256 EEPROM and can read/write it with a PIC. Realterm can communicate via VCP with the PIC, and thus far, I can download binary files in a rudimentary, piecemeal fashion and upload EEPROM contents to a capture file.

Sending just the raw data will require program(s) to parse IR or RMIR files and communicate with the VCP, with software handshake - EEPROMs require ~5ms pause to write each page of data, one page = 16 bytes for 24C8/16 or 64 bytes for 24C256. The PIC would piggyback on Tommy Tyler's USB interface. Receiving data from a remote's EEPROM should be faster, but I have not considered what to do about putting it back into an IR file. ':?'

At this point, I still don't know enough about IR.exe or JP1, particularly the command structure for transferring data. Still very low on the learning curve.....

[Thomas]

I am now to the point where I can write the contents of the first xxx lines of ASCII data from an IR file to my 24LC256 EEPROM, and then read it back into IR format.

Using RealTerm and FTDI interface, my PIC program extracts the EEPROM data and sends it via USB (VCP) for capture. Then, using a text editor, I can copy that capture file to the first part of an IR file and use IR to examine and modify. Crude, but it works.

Next goals:

Speed up the EEPROM writes by using 'page write' and generally optimize the entire program.

Modify the program to work with an 18-pin PIC chip, 18F1220 or such. Currently using 18F4520, which has code for handling I2C and simplifies firmware and timing issues (but easy to debug) 1220 ($3) is a bit cheaper than 4520, smaller footprint, should have enough capability.

Write some code to automate this process - extract raw data from IR file, signal RealTerm to send it to remote, or signal to download from remote, restore data to IR file.

Test some JP1 remotes. Hoping that they all use 24C series EEPROMs.

BTW RealTerm is freely distributed, current version 2.0.0.57, works well with XP - possibly somebody can advise whether it is compatible with Win7.

http://realterm.sourceforge.net/

[Thomas]

I have now got the 18F4520 version of the interface working, with FTDI, to talk with IR and JP1 remotes (a couple of them, anyway). I got my 18F14K50, hooked it up and ported the program over to it. Not too difficult, so far. Both chips have hardware to handle I2C and UART, but the K50 additionally has the USB module. I am just starting to delve into that - I did not realize that I was going to need a 12MHz crystal in order to get the proper USB clock, did not read the datasheet until after I made the order.

At some point, I expect to have something which will handle both JP1 and JP1.2/3 - just the command set that IR uses. One other feature that might be added is a bootloader, which would install software upgrades sent over the USB port.

Still in the experimental phase, please stay tuned.....

[Kevin Timmerman]

If you are doing this in C, then the PicKit 2 firmware source code may be of interest.

It has USB comm, USB bootloader, serial comm, IIC comm and more.

The PicKit 2 can be used for JP1 EE/Flash programming, but not with IR/RM.

[The Robman]

The PicKit 2 can be used for JP1 EE/Flash programming, but not with IR/RM.

Why can't it be used with IR?

[Kevin Timmerman]

IR doesn't know how to talk to a PicKit 2. That could be fixed if someone had the motivation and skill. I am not suggesting that this should be done, nor that is should not. Just an observation.

[unclemiltie]

At some point, I expect to have something which will handle both JP1 and JP1.2/3 - just the command set that IR uses. One other feature that might be added is a bootloader, which would install software upgrades sent over the USB port.

This would be way cool! Now all we need is a driver for Mac!

-bill

[The Robman]

IR doesn't know how to talk to a PicKit 2. That could be fixed if someone had the motivation and skill. I am not suggesting that this should be done, nor that is should not. Just an observation.

But someone could write a DLL program to call the PicKit2 that could be used by IR, right? We've already split out the flash I/O code from the main IR program, and I think it would be a good idea to do the same with the E2 code at some point.

[Tommy Tyler]

I built my last JP1 (EEPROM) Interface today. I've discontinued that product and am now selling Kevin's JP1 EEPROM Programming Adapter, which can be used with any JP1./2/3 (Flash) Interface to program a JP1 remote. See my catalog page in the Market Place for more details.

R.I.P. Delcom !

[The Robman]

That was quick!

[Thomas]

[If you are doing this in C].......
No, I am using assembly - don't really need to optimize for program memory space in this case, but C18 is known to add bulk to code and sometimes mess up hardware timing. Also, I have little interest in typing those long, 'descriptive' variable names.

I have ICD2 and a prototype board, with MPLAB this makes debugging code pretty easy. Mounted sockets can be used as header strips, interconnect things by plugging in pieces of 22ga solid wire.

Since higher level PIC chips have a substantial amount of memory, developers of OBD-II interfaces, among others, have been moving towards bootloaders. That makes it simple to provide firmware upgrades to their clients. Just download the patch file, plug your device into the computer, and execute the file.

Pickit2 is a nice gadget, but the average hacker can build a freeware interface, which does just as much, and provides more insight into in-circuit serial programming (ICSP) and debugging. For just programming, a simple JDM interface and something like WinPic is a good place to start. ICSP may not be totally incompatible with programming remotes à la IR, but doing so would not provide any new functionality.

Tommy's new product looks nice - this stuff is getting awfully small for me to manage with my big clumsy fingers.........

[Kevin Timmerman]

Very happy to hear you program in asm. So many people use C because "assembly is hard." Bah!

I currenly have two ICD-2 and will probably get an ICD-3 sometime this year - don't really need it right now.

JDM and Tait must die!!! PICKit 2 is only $35 and worth every penny.

Tommy does an amazing job with packaging. I didn't understand why he wanted to make a USB IR Widget. When I saw the final product I was amazed and finally understood.

[Thomas]

Ah, well, I did say that JDM is a good place to START - using that, you can learn a bit about PIC architecture (and the pitfalls), then build and program any of a number of PICKit2 clones. Schematics and assembly files are freely available on the internet. However, already having an ICD2, I am currently not in the market for PICKit hardware. Microchip have been discounting the ICD2, but I suppose at some point I will be forced to get the ICD3 upgrade to work with the newer chips.