Skip to main content


This section allows you to view all Topics made by this member. Note that you can only see Topics made in areas you currently have access to.

Topics - JTR

AVRDude / BPv4 AVRDUDE required patch
The BP6.3 -> AVRDUDE code needs to be patched for the BPv4. Cut and paste this over the same section in spi.c and see how it goes. If it works then push it to the SVN else disregard.

                    case 6: // AVR Extended Commands
                        UART1TX(1); // send 1/OK (ie, AVR Extended Commands accepted)

                        inByte = UART1RX(); //grab it

                        switch (inByte) {
                            case 0x00: // null operation, return OK
                                UART1TX(1); // send 1/OK
                            case 0x01: // version check
                                UART1TX(1); // send 1/OK
                                UART1TX(0x01); // version 1
                            case 0x02: // bulk memory read from flash
                                // read in the start address (4 bytes, MSB first)
                                saddr = 0;
                                for (j = 0; j < 4; j++) {

                                    inByte = UART1RX(); //grab it
                                    saddr = (saddr << 8) | inByte;

                                // read in the bytes to read (4 bytes, MSB first) [inclusive]
                                length = 0;
                                for (j = 0; j < 4; j++) {

                                    inByte = UART1RX(); //grab it
                                    length = (length << 8) | inByte;

                                // FIXME - Can't handle pages past the first 64kb
                                if (saddr > 0xFFFF || length > 0xFFFF || (saddr + length) > 0xFFFF) {
                                } else {
                                    // just assume it'll work...
                                    UART1TX(0x01); // send 1/OK

                                    for (j = saddr; length > 0; j++) {
                                        // fetch low byte from this memory word
                                        spiWriteByte(j >> 8);
                                        spiWriteByte(j & 0xFF);
                                        UART1TX(spiWriteByte(0x00)); // fetch byte that was read

                                        if (length == 0) break;

                                        // fetch high byte from this memory word
                                        spiWriteByte(j >> 8);
                                        spiWriteByte(j & 0xFF);
                                        UART1TX(spiWriteByte(0x00)); // fetch byte that was read
USB Infrared Toy / IR TOY SUMP 2012
Remember the original IR TOY SUMP mode? 4096 BIT samples @ 10kHz. It only sampled the demux IR (from TSOP38438) and not the RAW IR signal (from the QSE159).

This is a screen shot of the the latest somewhat upgraded IR TOY SUMP mode working fantastically well with Jawi's OLS client.

This is effectively V2 of the JTR-SUMP mode and contains some bug fixes, greater bandwidth and quadruple buffering to smooth out the variable USB latency. Gone are the occasional artifacts from the previous version. This one is smooth.

Shown is all of PORTB that includes the RAW and DEMUXed IR streams. (The DEMUXed is on two channels). The sample rate here is 240kHz * 8-bits. That is sort of maxed out. I may be able to get 250kHz or a bit more, just haven't tried it yet and probably will just leave it @ 240kHz. Also note the the firmware has inverted the outputs of both IR detectors.

That leaves 5-bits of PORTB that can be used as a low speed analyzer for other purposes. Any of the PORTB IOC pins can be used to trigger the start of sampling or you can writer your own code.

The waveforms shown are from a NEC IR remote and @ 38.4kHz. Of course we are going to get a little aliasing but the RAW IR shown contains the useful information - 22 pulses per ON time at about 40% duty cycle.

You can also see the real time lag of the DEMUX receiver. I will point something interesting out about this in the new firmware's documentation.   

Now that I have this working so well with the PIC18 on the IR TOY, I will port it to the Bus Pirate and perhaps get 1MBs sampling rate. Doesn't exactly replace the OBLS but for reduced requirements and greater samples (potentially limited only by your hard disk) it is not a bad bonus feature, especially considering the price. :)

USB Infrared Toy / Critical bug in REC and PLAY
It is so dangerous delete any copy you have and use the attached .exe. Bad BAD BAD!

Good 'n'
01A6 00D2 001B 0019 001D 0018 001D 0018 
001B 001A 001B 0019 001C 0017 001C 001A
001C 0017 001E 004C 001D 004D 001B 004E
001D 004D 001C 004C 001C 004E 001D 0018
001A 004E 001D 0017 001C 004E 001D 004C
001D 0018 001D 0017 001C 001A 001C 0018
001D 0018 001B 004D 001E 0018 001B 001A
001B 004D 001B 004D 001E 004C 001D 004C
001C 004E 001D 077E 01A5 0068 001D FFFF

Bad 'n'
00A6 00D2 001B 0019 001D 0018 001D 0018
001B 001A 001B 0019 001C 0017 001C 001A
001C 0017 001E 004C 001D 004D 001B 004E
001D 004D 001C 004C 001C 004E 001D 0018
001A 004E 001D 0017 001C 004E 001D 004C
001D 0018 001D 0017 001C 001A 001C 0018
001D 0018 001B 004D 001E 0018 001B 001A
001B 004D 001B 004D 001E 004C 001D 004C
001C 004E 001D 007E 00A5 0068 001D FFFF

Sorry I am not sure how to compile for other OSes.

The updated source code will be part of a complete new IR TOY release soonish. Let me know if you need the beta source to compile for Linux etc in the meantime.
USB Infrared Toy / irrecord. does it work?
Is anyone having any success with irrecord and the IR TOY? I have tried with the latest irrecord and various IR TOY firmwares and it almost always gives a "something went wrong" message when I try to record the actual keys. Occasionally it does receive  a key on a retry.

Up until that point it works correctly. I have used the -f option and that did not help.

I have everything working on the new IR TOY firmware and this is the only thing that is not working correctly. All my other tests show that the firmware is working correctly and in any case the same issue is happening with V22 firmware.

There is no problem using irgraph or rec and play or anything untoward visible with terminal software. It is just irrecord so I am wondering has anyone got this to work (on windows) or is there a problem with irrecord itself?

Edit: This was with the official IRTOY  DLL and not with my modified DLL.
USB Infrared Toy / Bug in winlirc
In /SendReceiveData.cpp

395    // put back into sampling mode
396    //
397    temp[0] = 's';
398    serial.Write(temp,1);
399    Sleep(50);

These three lines should not be there. The IR TOY is already in irS mode so the 's' does not need to be sent. If it did then winlirc would then have to read the response "SO1" from the serial port. It does not do this. If it did then it would fail with the older firmware, if it does not then the "S" becomes the first "send packet size" token.

In any case if it were required and actually did re-enter the irS mode then the new settings that have just been sent to the IR TOY would be clobbered and the defaults restored.

I have managed to recompile the IR TOY DLL and it *seems" to me to be working but to recompile I had to change the #include "afxres.h" to windows.h and add another define for something that was missing (I think this is a VS++ 2010 problem but I am not sure...). I would rather have someone who really knows what they are doing fix this and recompile just in case there is a problem with what I did that still lurks unseen.
Client software / IRToy problems...
Jawi, The new client looks really good and has some nice features added. I gave it a try out and found that the device.samples.reverseOrder  mode option for the IR TOY does not work any more.  The client always shows the output in reverse mode regardless of the setting. Somewhere between ols-0.9.5-b2 and ols-0.9.6-b3 this feature got broken.

(It appears to be broken on the logic shrimp too...)

Also noted that the comment in the cfg file is still opposite to the function.

Finally, did you ever implement  the infinite samples mode that was floated quite some time ago now?

Anyway apart from the above it worked well with the latest IR TOY firmware and I love that you got rid of the mouse movement screen artifacts.
USB Infrared Toy / Firmware V22 bug
In irS.c

Last byte of frequency is not sent at all.

                        if ((irToy.HardwareVersion > 1)) { // end of capture flush

                            for (j = 0; j < [s:]5[/s:]; j++) {

                    case IRIO_FREQ:
                        if ((irToy.HardwareVersion > 1)) { // end of capture flush

                            for (j = 0; j < 6; j++) {
General discussion / Yet more new USB PIC18 family members
Hot of the press microchip have more K series PIC18s with USB coming.

28-pin and 40/44-pin replacements for the 18Fx450 & 18Fx550 families.

High performance PIC18 core with 8x8 Hardware Multiply
Flash Program Memory with self read/write capability
256 Bytes of integrated EEPROM
Internal 48MHz Oscillator with USB Accuracy -Via Active Clock Tuning from USB Host
Universal Serial Bus 2.0 Module
Enhanced Capture Compare PWM (ECCP) Module with up to 4 outputs
Integrated Temperature Indicator Module
Up to 25 Channel 10-bit ADC with Voltage Reference
2 Analog Comparators
5-bit Digital to Analog Converter (DAC)
MI2C / SPI Module (MSSP)
Enhanced Addressable USART Module
Charge Time Measurement Unit (CTMU) for measurement applications
25mA Source/Sink current I/O
2x 8-bit Timers
2x 16-bit Timers
Extended Watchdog Timer (WDT)
Enhanced Power-On/Off-Reset
Low-Power Brown-Out Reset (LPBOR)
Programmable Brown-Out Reset (BOR)
In Circuit Serial Programming and Debug (ICSP/ICD)
PIC18LF2xK50 (1.8V – 3.6V) with nanoWatt XLP
PIC18F2xK50 (1.8V – 5.5V)

Given that the K series are usually way less than half the cost of the standard legacy family it looks to me that we could have a much lower cost 5V IR TOY 3 someday.
General discussion / Sneak preview of microchip's new USB PIC24FJ64GB502
There are no links on the microchip site for these items but I found them with a site search.

No crystal required for USB

Microstick for USB PIC24F ... 52070a.pdf

Video of above microstick. ... nZsvYeZL04

No idea when these will be available but hopefully soon. I can see people mocking up their own low cost "bus pirate lite" with these parts.
Open source USB stack / Seven DP projects one usb stack.


Pretty much this is getting to be the final work on the current generation USB stack and the DP hardware. At least for the time being... While the usb stack is not the latest I have it is the best trade-off between many competing issues and at a level that is fully understood should I need to revisit it. Some hardware got an improved stack and some got rolled back a level so that it was all compatible and modular.

Because of on going problems with MPLAB X that I an working with the microchip dev tool team to sort out, mostly these projects are MPLAB 8.xx based. MPLAB X is fine for all the PIC18 projects but it tends to not want to load the BPv4 firmware.

Keep in mind that I have not fully tested all the projects as such, rather only the usb stack and the general workings of the cdc API. 

The USB stack is organized like this.

[project folder]
[usb stack folder]

The project folder requires these files that are referenced by the usb stack:

prj_usb_config.h (replaces cdc_config.h)
descriptors.h (For the most it is the same file for all projects with only the strings changed. However this could need to be changed at anytime so I did it this way for forward compatibility.)

The project needs to be built with these files:


The usb stack header files need to be included in each and any module that uses the usb stack.

#include "..dp_usbusb_stack_globals.h"    // USB stack only defines Not function related.

main.c (only!) needs to include the configwords and the descriptor header:

#include "descriptors.h"           // JTR Only included in main.c
#include "configwords.h"   // JTR only included in main.c

For the PIC18F14K50 the cdc bulk endpoint size specified in prj_usb_config.h needs to be set to 32 as there is not enough usb ram for the cdc double buffering otherwise.

Both the paths for the project and the usb stack need to be included in MPLAB's search path at least for C30 projects. C18 seems to work without them though.

project -> built options -> project -> directories -> show directories for -> include search path



With this stack I have (hopefully) completely separated the stack and the project that uses it.

PLEASE! DO NOT break this by putting project items in headers or source files belonging to the usb stack like I/We did in the past. usb_stack_globals.h is for the usb stack. I suggest the use of prj_globals.h for items belonging to the application.

I also got rid of the requirement to include files from the microchip MAL. No more generictypedefs.h, compiler.h etc. There was not much point in moving away from the microchip usb stack if we where still using files from the MAL.

While, of course, there will be a requirement to change the directory structure between projects and the usb stack for the purposes of packaging complete projects I "suggest" for the time being that any work done on the project is done in the current structure as in my zip file at least until it is debugged and ready for release. I do not wish to have any more copies of the usb stack on my harddrive and I will not touch anything that has absolute paths...

OK, now it is over to all of you to finalize this work and get all these projects finished with the new open source stack. Let me know if you find any issues.


P.S. Happy Australia Day!
Bus Pirate Development / JTRs BPv4 V6.something with JTR_SUMP
Attached is a zip file with the firmware for JTR's latest work on the BPv4. It is somewhere between V6.1 and V6.2 therefore I do not consider this an official release, just a work in progress looking for testers to thrash it around a little. Only the USB stack and the SUMP mode are in my keeping and that is what I want feedback on.

Basic change log, complete with oversights.

New USB stack with permanent, full duplex  double buffered comms.
UART1 baud rate set from PC.
Recoded SUMP mode that is 100% protocol compatible with existing mode.
Code has been highly refactored and is a joy to read and understand. Well, relatively so.... :)
Trigger on port change enabled via client.
Data sent first sample first.
Up to 65535 samples.
Should sample at a few hundred kHz, yet to be characterized.
8 channels with AUX1 moved to B7 in firmware.
All digital I/Os on the BPv4 header are available.

The trigger on port change is enabled BUT at the last moment I realize that the actual mappings in the sump client may or may not be correct for the I/O pins. This is minor and you can find the triggers via trial and error if they are not where they should be.

Included in the zip file is the new BPv4 cfg file for the OLS client 0.9.5. Copy this into the plugin folder.

Also included is a screen shot showing a binary counter on the I/O. OK, I cheated, it is actually showing the buffer pointer but it was a good way to verify the USB stack and the SUMP mode liked each other.

The source code was too large to post here. You can get it here. http://

Please post comments here so that I can track issues with either the SUMP mode firmware or the USB stack. Any other problems please refer elsewhere on the forum.
General discussion / New USB PICs. 16F145x
Just spotted this new USB PICs. ... e=en556971

16F enhanced core with 48MHz internal oscillator and USB clock recovery. I take it this means that there will be no problem using the USB module at FULL SPEED with the internal oscillator. (Hopefully some other issues with the SIE will be addressed too otherwise the firmware stack just get to bloated...)

Enhanced Mid-range Core with 49 Instruction, 16 Stack Levels
Flash Program Memory with self read/write capability
Internal 48MHz Oscillator
Universal Serial Bus 2.0 Module with clock recovery from USB host
2x Standalone PWM Modules
Complementary Waveform Generator (CWG) Module
Integrated Temperature Indicator Module
10 Channel 10-bit ADC with Voltage Reference
2 Analog Comparators
5-bit Digital to Analog Converter (DAC)
MI2C / SPI Module
Enhanced Addressable USART Module
25mA Source/Sink current I/O
2x 8-bit Timers (TMR0/TMR2)
1x 16-bit Timer (TMR1)
Extended Watchdog Timer (WDT)
Enhanced Power-On/Off-Reset
Low-Power Brown-Out Reset (LPBOR)
Programmable Brown-Out Reset (BOR)
In Circuit Serial Programming (ICSP)
Integrated In-Circuit Debug Circuit
PIC16LF145x (1.8V – 3.6V)
PIC16F145x (1.8V – 5.5V)

Really excited about these PICs. Already planning to port my assembler stack to them. :)

EDIT: Product brief available here. http://
USB Infrared Toy / IR TOY 2012 Sneak preview.
Attached is "tester" for the reworked IR TOY firmware. This version is hardcoded to just use the usb2uart mode without the requirement to enter it or without it returning a sign-on message. It really is just a USB2UART mode.

    Fully double buffered and real time. Should easily support 1 Mbit/s transfers.
          Optional compile time enable/disable of CDC handshake signals DTR and RTS, both directly from host
          Supports polarity inversion of RX/TX and DTR, RTS handshake via pin strapping on RB3 and RB5 respectively.
          Added Auto flush on timeout. No "orphan" bytes.
          Auto ZLP handling for both IN and OUT transfers.
          Baud rate set by host via SET_LINECODING in cdc.c
          Works like a typical USB to RS232 chip except that some signals are not supported and there is no BREAK command.


1) Installation

There are no specific installation procedures. The USB2UART mode uses the same VID/PID
as the IR TOY and therefore the required drivers should already be installed.

2) Signals

By default the polarity of the TX and TX signals will be normal. To invert the logic of
the TX and RX pull PORTB-RB3 LOW.

The same applies for the DTR and RTS signals. To invert pull PORTB RB5 LOW.


The DTR signal is output on PORTA RA2

The RTS signal is output on PORTA RA1

Note: Due to a bug in the windows CDC driver the RTS signal is only updated when
the DTR signal is also updated. This bug applies to all versions of windows but not
to other O/S's

This firmware may or may not contain an easter egg.