The future of JP1 in the 64-bit world

cauer29 · Post by **cauer29** » Tue Dec 04, 2012 6:51 pm

carsonlittle wrote:
Tommy Tyler wrote:(2) a PIC or ATMEL processor that does it all, in which case we could go with the HID driver. Either approach would be cost competitive with using the Delcom chip. This doesn't sound like rocket science to me, but then it never does to those who don't know how to do it. Major issue: Flash uploading is in large packets of data, whereas EEPROM uploading is limited to 8 or 16 bytes per packet, with a pause while that packet is transferred from a receive buffer into the EEPROM. Are there simple handshake signals that would enable the interface to control the data transfer rate to accommodate this, without problematic changes to the IR software?

If anyone reading this with PIC or ATMEL programming experience is looking for a nice little project that will endear him (or her, Vicky) to the JP1 forum, I will volunteer to help with defining objectives, digging up specs, and all hardware chores, including prototypes for development.
Tommy ,

I apologize for resurrecting this very old thread, but I would be interested in working on this project.

It would be wonderful if we could speak over the phone to exchange some thoughts but I want it to be a "all-in-one" PIC solution - using those nice USB capable PICs. I also have a PickKit3 and OpenProg that I built myself.

The code will be in C18 but I would like to restrict the source code to people who actively contribute to this project (HEX will be available to everyone). Projects I have worked on in the past have been ripped off before by small time overseas hobby shops that openly sell these projects at a profit without contributing anything back.

I also have a scope at school that I can use.

I am interested in JP1 because the "learning" remote I DIY can only handle RC5 and I am fed up trying to implement NEC and SIRC is so poorly documented that I would rather focus on the JPx project that works.

Since the Microchip HID framework does not have a working demo of implementing all 5 pins of a serial port, I might have to come up with a way to control a GPIO pin to put the remote in programming mode (we can discuss that in details, and how to integrate it with IR)

Looking forward to working with you.

If you didn't already know, the widget FW has been ported to a PIC with USB already. See it here:

http://dangerousprototypes.com/docs/USB_IR_Toy_v2

The normal FW for that one doesn't do widget, but there is an alternative FW that does. I don't know how full the memory is on that, but there may be sufficient space to add the JP1.x serial port stuff and the JP1.x to JP1 conversion. That would be the holy grail combo does everything device.

I've thought about other ways of doing a combo, but they all require changes to the precious JP1 software and I wouldn't expect to get much support for that. For example; FTDI has USB to serial boards that do I2C comm with eeproms pretty straightforward and that would cover JP1, but it would mean a major change to the JP1 software tools to use the FTDI eeprom capabilities. The same FTDI chip can easily do the JP1.x serial port stuf and there, no changes would be needed in the software. There isn't any easy way to make the FTDI chip behave like a widget, but there are actually better ways to do what the widget does. The FTDI chip can be setup to stream continuous data sampled at 1 MHz and this would be actually better than how the widget does it. Again, no JP1 tool support likely for such a radical change. Still, it could be done from a hardware standpoint. There just isn't much point in doing it, unless someone is willing to step up and make the required software changes to the JP1 tools.

A.A.

Barf · Post by **Barf** » Wed Dec 05, 2012 2:25 pm

I would like to add my $0.02 to this.

cauer29 wrote: If you didn't already know, the widget FW has been ported to a PIC with USB already. See it here:

http://dangerousprototypes.com/docs/USB_IR_Toy_v2

The normal FW for that one doesn't do widget, but there is an alternative FW that does. I don't know how full the memory is on that, but there may be sufficient space to add the JP1.x serial port stuff and the JP1.x to JP1 conversion. That would be the holy grail combo does everything device.

I do not want to throttle someones enthusiasm, but, in the light of the current status of JP1 interfaces, in particular this design, this sounds (to me) about as needed and interesting as a combined tooth brush and bottle opener.

I've thought about other ways of doing a combo, but they all require changes to the precious JP1 software and I wouldn't expect to get much support for that. For example; FTDI has USB to serial boards that do I2C comm with eeproms pretty straightforward and that would cover JP1, but it would mean a major change to the JP1 software tools to use the FTDI eeprom capabilities. The same FTDI chip can easily do the JP1.x serial port stuf and there, no changes would be needed in the software. There isn't any easy way to make the FTDI chip behave like a widget, but there are actually better ways to do what the widget does. The FTDI chip can be setup to stream continuous data sampled at 1 MHz and this would be actually better than how the widget does it. Again, no JP1 tool support likely for such a radical change. Still, it could be done from a hardware standpoint. There just isn't much point in doing it, unless someone is willing to step up and make the required software changes to the JP1 tools.

A.A.

I am not sure what you mean by "changes to precious JP1 software". Adapting SW to new HW does not "break" it, unless of course you are trying to squeeze too much into one program that was designed for another purpose.

I have had as a goal to incorporate support for something like the IR Widget into IRMaster for a long time. I temporarily gave up due to lack of time (not lack of knowledge or other resouces), If someone comes up with a HW/API solution that can be accessed reasonably from Java (for example using the RXTX library) I will be more than happy to support it in IrMaster.

xnappo · Post by **xnappo** » Wed Dec 05, 2012 3:17 pm

cauer29 wrote: I've thought about other ways of doing a combo, but they all require changes to the precious JP1 software and I wouldn't expect to get much support for that.

Just curious where in the world that negativity came from - the architecture of RMIR makes adding in a new interface device fairly straight-forward..? It is an open source project you know!

xnappo

BTW PIC? Yuck. Kinetis!
http://www.freescale.com/webapp/sps/sit ... rettyPhoto
($12)
Overkill? Maybe - but lots of possibilities.

cauer29 · Post by **cauer29** » Wed Dec 05, 2012 10:27 pm

Perhaps I should've mentioned that my programming skills are nil. Hardware design I can do, but not programming. Any cool hardware designs that require someone else to write the software, would just go begging around here since we see comments about finding a combo device as useful as a toothbrush/bottle opener.

A.A.

Post by **The Robman** » Thu Dec 06, 2012 7:48 am

Whenever we've needed the JP1 software to be changed to support a new JP1 interface, or to support a new UEI communication protocol, the group has indeed stepped up and the software got changed/written.

On the other hand, if someone wants the tools modified to support something outside of the normal JP1 realm then they may have to be the one to step up, or they would need to clearly outline (a) the benefits and (b) what changes are needed.

However, comments like "changes to the precious JP1 software and I wouldn't expect to get much support for that" are probably a self-fulfilling prophecy in that you've already pissed of the programmers that would have been the ones to help you.

carsonlittle · Post by **carsonlittle** » Sat Dec 08, 2012 3:35 pm

The Robman wrote:Whenever we've needed the JP1 software to be changed to support a new JP1 interface, or to support a new UEI communication protocol, the group has indeed stepped up and the software got changed/written.

I know and that's what I am counting on!

The Robman wrote:On the other hand, if someone wants the tools modified to support something outside of the normal JP1 realm then they may have to be the one to step up, or they would need to clearly outline (a) the benefits and (b) what changes are needed.

However, comments like "changes to the precious JP1 software and I wouldn't expect to get much support for that" are probably a self-fulfilling prophecy in that you've already pissed of the programmers that would have been the ones to help you.

cauer29 has been a long time contributor to this forum and I am sure he has his own reasons for his opinions, but let me share with you all the plan I have regarding this "combo widget":

1. It uses a USB capable PIC that connects to your computer natively over USB - no more costs of an additional cable
2. This PIC is not going to be "just another" USB <-> SERIAL translator. No. The original JP tools were written with the RS232 standard in mind and use legacy RS232 signalling which I see has become more of a liability than an asset.
I understand most of the responsibility is mine and I will take it up.

Expect a lot of questions from me on this forum.

Some ideas:

i. The IRWidget design for example, could be re-written, to use only RxTx lines. This would entail redefining the protocol it uses to send captured data to the host. Yes - akin to packets of data our very remotes send over IR.

ii. Similarly, the DTR line is just a signal to reset the remote controller. However, because of this line being important to our tools, we cannot employ "just any" USB <-> SERIAL adapters that just handles RxTx lines
Again, the solution to this is to update the software to use "packets of data" instead of serial port signalling.

Now understanding how all the tools work is critical to making this happen and I will need all the support I can get from you gentlemen. I intend to come up with working prototypes by January, if not earlier.

I am expecting "high bandwidth" communication with Mr. Tommy Tyler though - I want to ask him questions over the phone and I expect him to question me as well, at least to find out if investing his time in me is worth it.

If anyone of you is interested in doing the same as well, I will be grateful. Please PM.

cauer29 wrote: The normal FW for that one doesn't do widget, but there is an alternative FW that does. I don't know how full the memory is on that, but there may be sufficient space to add the JP1.x serial port stuff and the JP1.x to JP1 conversion. That would be the holy grail combo does everything device.

USB comms is built in to the MAL firmware. I haven't had a look into the Hoken stack yet, but I expect it to be similar. Hence, the "actual" firmware I will be writing is the "JP1x stuff".
I will begin with Jp1.x support and am not sure if I will implement stock JP1 support as well, but the code should be available to all core contributors and they can add it I guess.

cauer29 wrote: I've thought about other ways of doing a combo, but they all require changes to the precious JP1 software and I wouldn't expect to get much support for that. For example; FTDI has USB to serial boards that do I2C comm with eeproms pretty straightforward and that would cover JP1, but it would mean a major change to the JP1 software tools to use the FTDI eeprom capabilities. The same FTDI chip can easily do the JP1.x serial port stuf and there, no changes would be needed in the software. There isn't any easy way to make the FTDI chip behave like a widget, but there are actually better ways to do what the widget does. The FTDI chip can be setup to stream continuous data sampled at 1 MHz and this would be actually better than how the widget does it. Again, no JP1 tool support likely for such a radical change. Still, it could be done from a hardware standpoint. There just isn't much point in doing it, unless someone is willing to step up and make the required software changes to the JP1 tools.

I thought you said you were just a hardware guy but I can se you have a good grasp of software as well. What I am trying to achieve is factor out RS232 signalling and replace it with native USB packet based communication.
This is a substantial undertaking and would requiring modifying the way our JPx software "talks" with the hardware.
Yes, this can be viewed as an extra burden by those of us who already have the existing tools that does serial (be it native or though a USB translator), and our software might require to support two separate interfaces for a while, but I assure you, as time goes by, all of this pain will be forgotten and will pay off handsomely.

I invite honest feedback from all of you, and if anything in my plan looks too ambitious and very difficult, share your opinions freely.

Kevin Timmerman · Post by **Kevin Timmerman** » Sat Dec 08, 2012 4:31 pm

I built a prototype JP1 EE / JP1 Flash / IR Widget combo device about 4 years ago. The JP1 serial protocol was extended to support JP1 EEPROM and IR Widget operation. Firmware could be updated via USB. Tommy wasn't interested in mfg it, so no more work was done on it.

The JP1 EEPROM adapter was built with code from that project. It can also work as an IR Widget, but is not supported by IR Scope due to changes in the protocol.

Post by **The Robman** » Sat Dec 08, 2012 4:57 pm

carsonlittle wrote:I am expecting "high bandwidth" communication with Mr. Tommy Tyler though - I want to ask him questions over the phone and I expect him to question me as well, at least to find out if investing his time in me is worth it.

Be prepared for Tommy to not be as available to you as you would hope.
http://www.hifi-remote.com/forums/viewt ... 886#102886

carsonlittle · Post by **carsonlittle** » Sat Dec 08, 2012 4:58 pm

Kevin Timmerman wrote:I built a prototype JP1 EE / JP1 Flash / IR Widget combo device about 4 years ago. The JP1 serial protocol was extended to support JP1 EEPROM and IR Widget operation. Firmware could be updated via USB. Tommy wasn't interested in mfg it, so no more work was done on it.

The JP1 EEPROM adapter was built with code from that project. It can also work as an IR Widget, but is not supported by IR Scope due to changes in the protocol.

It is wonderful to see your involvement in this!

If you are interested in sharing the details, I would find them to be helpful.

It seems you used a bootloader, as that's the only way the firmware could be updated on the fly. In the design I have planned, I will use a modified MCHPUSB bootloader.

I had some clarifications about the pulse count mode of the IRWidget, but perhaps for you, it will be easier to have a look at this C code and just confirm if it deviates much from your reference ASM implementation:

Code: Select all

    #define tx_port PORTD
    #define tx_bit 1
    #define mode1_port PINB
    #define mode1_bit 7
    #define mode2_port PINB
    #define mode2_bit 5
    #define status_led_port PORTB
    #define status_led_bit 0
    #define ir_demod_port PIND
    #define ir_demod_pin 2

    void setup()
    {
      DDRB = B01011111;
      PORTB = B00000000;
      DDRD = B00101010;
      PORTD = B00110000;
      TCCR0A = 0;
      TCCR0B = (1<<CS02)|(1<<CS01);
      TCCR1A = 0;
      TCCR1C = 0;
      TCCR1B = (1<<CS11)|(1<<CS10);
      Serial.begin(115200);
    }

    uint16_t time_save;

    void report_time(int period)
    {
      uint16_t temp = TCNT1L | (TCNT1H << 8);
      temp-=time_save;
      time_save+=temp;
      temp>>=1;
      temp|=period;
      //Serial.print(temp&0xFF,BYTE);
      //Serial.print(temp>>8,BYTE);
      Serial.println(temp,DEC);
    }

    void loop()
    {
      int tx_data;
      int prev_count;
      int temp;
    // cli();
      while(Serial.available()==0);  //Wait for host to decide what mode to execute.
      temp = Serial.read();
      if((temp==0)||(temp=='0'))
      {
        while(1)    //Count Mode
        {
          while(Serial.available()==0);
            Serial.read();
          cli();
          //Count_First
          tx_data = TCNT0;
          do
          {
            temp = TCNT0;
          } 
          while (temp==tx_data);
          digitalWrite(8,HIGH);
          //do
          while(1) {
            //cli();
            prev_count = tx_data;
            Serial.print(tx_data,BYTE);
            //delayMicroseconds(100);
            delayMicroseconds(93);    //Make this loop exactly 100 microseconds.
            __asm__ __volatile__ ( 
            "nop\n\t"  //When I traced, the loop was exactly 99.5 microseconds.
            "nop\n\t"  //7 nops, to make the loop 99.9375 microseconds long.
            "nop\n\t"
            "nop\n\t"
            "nop\n\t"
            "nop\n\t"
            "nop\n\t"
          );
            tx_data = TCNT0;
            if(tx_data==prev_count)
            {
              __asm__ __volatile__ (
              "nop\n\t"  //And this nop makes the loop 100 microseconds long,
                             //when there is no change in counts.
          );
              digitalWrite(8,LOW);
            }
            else  
            {              //The branch to here makes 100 microseconds
                           //when the count has changed.
              digitalWrite(8,HIGH);
            }
              
            //sei();
          }// while(Serial.available()==0);
          Serial.read();
        }
      }
      else    //Time mode
      {
        while(1)
        {
           while(digitalRead(4));
           report_time(0x0000);
           digitalWrite(8,HIGH);
           while(!digitalRead(4));
           report_time(0x8000);
           digitalWrite(8,LOW);
        }    
      }

    }

I got this from http://forums.adafruit.com/viewtopic.php?t=5052

If you want, you can also comment to the OP at that forums since you area long time member there as well

Hope to see more of you, and nice weekend!

carsonlittle · Post by **carsonlittle** » Sat Dec 08, 2012 5:01 pm

The Robman wrote:Be prepared for Tommy to not be as available to you as you would hope.
http://www.hifi-remote.com/forums/viewt ... 886#102886

I wanted to speak with him over the phone because of this very reason. I think talking requires the least amount of effort while conveying better quality information.

At the very least, the issue about the USB cables is solved thanks to the CP2102 cables like the one I posted about: http://www.hifi-remote.com/forums/viewtopic.php?t=14424

Post by **The Robman** » Sat Dec 08, 2012 5:07 pm

Btw, if you check "Disable BBCode in this post" when you post, all the BBCode that you use gets displayed as code. I have to keep editing your posts to uncheck this so that your BBCode works.

carsonlittle · Post by **carsonlittle** » Sat Dec 08, 2012 5:11 pm

The Robman wrote:Btw, if you check "Disable BBCode in this post" when you post, all the BBCode that you use gets displayed as code. I have to keep editing your posts to uncheck this so that your BBCode works.

... and all this time I was wondering what the hell was wrong with this board software. Consider it fixed - see!

Post by **The Robman** » Sat Dec 08, 2012 5:13 pm

Cool!

Kevin Timmerman · Post by **Kevin Timmerman** » Sat Dec 08, 2012 6:22 pm

carsonlittle wrote: It seems you used a bootloader, as that's the only way the firmware could be updated on the fly. In the design I have planned, I will use a modified MCHPUSB bootloader.

I had some clarifications about the pulse count mode of the IRWidget, but perhaps for you, it will be easier to have a look at this C code and just confirm if it deviates much from your reference ASM implementation:

I used a FTDI FT232R chip for both host comms using UART mode and firmware update using the bit-bang mode.

I have considered using CDC ACM with a USB microcontroller but there are a few problems with that approach that have discouraged me.

If you want to do the IR Widget in C, then use a hardware timer. Configure the timer for 100 uS period. Read the IR pulse count and send it out a hardware serial port in the timer ISR

carsonlittle · Post by **carsonlittle** » Sat Dec 08, 2012 8:25 pm

Kevin Timmerman wrote: I used a FTDI FT232R chip for both host comms using UART mode and firmware update using the bit-bang mode.

I have considered using CDC ACM with a USB microcontroller but there are a few problems with that approach that have discouraged me.

I am well aware of the shortcoming of the Microsoft CDC driver not implementing the handshaking lines -
infact the CDC protocol is very loose about handshaking signals. (So this issue could very well be in Linux ttyUSB drivers as well?))

The only solution to this problem is to write custom usb-serial
drivers: to that end the effort-vs-payoff would be too little for a
one man shop like us - hence I will sidestep this entire issue by
purchasing a FTDI cable

The reason why RTS or CTS is requires is just because the JP1x cable
essentially talks serial - however, with additional code, it can just
"talk" USB instead - and NOW we can use the usual CDC drivers!

Kevin Timmerman wrote: If you want to do the IR Widget in C, then use a hardware timer. Configure the timer for 100 uS period. Read the IR pulse count and send it out a hardware serial port in the timer ISR

That's exactly what I want to do - use one of the 16 bit timers on the PIC18F, but servicing the data output at a sample rate of 100 uS when using the USB firmware might pose challenges (aka, "I never did this before at this rate").

However, the pic18f2550, does have a 256 bytes Data EEPROM, and 2K RAM - this should be enough to buffer the counts at a relaxed data output rate.

Did your "all-in-one" widget use just the FDTI or FDTI+PIC (like the USB IRWidget)?