The missing piece: porting BPv4 to the open source USB stack

Topic: The missing piece: porting BPv4 to the open source USB stack (Read 13476 times) previous topic - next topic

The missing piece: porting BPv4 to the open source USB stack

August 28, 2011, 09:13:12 am

Now that the JTR-Honken USB stack is blazing away on the IR Toy, I'm going to try to get it going on Bus Pirate v4.

JTR already laid all the groundwork for a port by abstracting the UART stuff in the source.

Here's my plan of action:
*Add updates from IR Toy stack
*Do mini echo test
*Hook the stack into the firmware
*Start manufacturing of BPv4 :)

I'm hoping to announce BPv4 at the OHS, the way the Arduino UNO was launched there last year.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #1 – August 28, 2011, 09:42:12 am

I merged in all the updates ok. Getting a compile error:

Quote

In file included from base.h:28,
from globals.h:20,
from main.c:16:
usb_stack.h:133: error: redefinition of 'struct BDENTRY'
usb_stack.h:137: error: redefinition of typedef 'BDentry'
picusb.h:526: error: previous declaration of 'BDentry' was here

The struct is defined in both places in IR Toy too, but doesn't give an error. I guess I need to straighten out some include logic.

My source is attached.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #2 – August 28, 2011, 01:51:19 pm

I think the two definitions of BDENTRY are a mistake. I removed the one in usb_stack.h and left the one in picusb.h. Should ask JTR if that is wise.

Had to move typedefs for BYTE to globals.h

Around 108 of cdc.c sets the UART speed for a CDC line coding data packet. PIC 18 uses 2 SPRG(H) registers. On the PIC 24 we use U1BRG (16bits). I added a define for UART_BAUD_setup(dwBaud) for each PIC in picusb.h.

The BPv4 version uses the old stack function names and stuff. I removed the old ones at the top oc baseIO.c and added the ones from the IR TOy:

Code: [Select]

extern unsigned char usb_device_state; // JTR2 corrected type
extern unsigned char cdc_trf_state;
extern BYTE cdc_In_buffer[64];
extern BDentry *Inbdp;

Almost compiles. The USB integration functions need to be updated with the new IR Toy double buffer variables and functions.

Latest version attached.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #3 – August 28, 2011, 02:21:57 pm

That was wrong. these are the top of baseIO.c

Code: [Select]

extern BYTE cdc_In_buffer[64];
BYTE CDC_In_count;
extern BYTE *InPtr;
extern BYTE *OutPtr;

Re: The missing piece: porting BPv4 to the open source USB s

Reply #4 – August 28, 2011, 03:29:27 pm

This is probably it for now...

Enabled interrupts in usb_stack.c usb_start() (should be defined for easy portability, but hey, lets get it going first)

I verified that the USB interrupt is firing under debug.

Can open the port every time.

The Bus Pirate does not see any data from the PC terminal (verified under debug)
The Bus Pirate cannot transmit to the PC. Verified with a character send loop.

I'm not sure if it is a Bus Pirate firmware problem, PIC24 version stack problem, or interrupt mode stack problem.

Tomorrow I make a minimal echo demo from the IR Toy firmware. Then I will get it banging on the PIC24, I hope. Then we can worry about interrupts and the BPv4 firmware if that works out.

Any help is always welcome :P

Re: The missing piece: porting BPv4 to the open source USB s

Reply #5 – August 29, 2011, 10:21:46 am

Good news everyone ;) This isn't working yet, but I do have a simple echo demo working now on BPv4!!!

Re: The missing piece: porting BPv4 to the open source USB s

Reply #6 – August 29, 2011, 10:57:23 am

Cool! I'll try it out on my BPv4 in a few mins. Hmm, I wonder if it will work on a PIC18F4550 board I have...

Re: The missing piece: porting BPv4 to the open source USB s

Reply #7 – August 29, 2011, 11:44:27 am

It should. Start with the 18f2550/IR Toy version in the echo demo and customize it for config words, etc.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #8 – August 29, 2011, 11:52:47 am

Yeah, I will. I'm kinda worried about that button thingy. I'll check out it a little more, then it should work I guess. Basically they have the same structure, they share the same datasheet.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #9 – August 29, 2011, 02:02:14 pm

Now that the echo demo basically works, I'm going to try to figure out why BPv4 integration isn't working.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #10 – August 29, 2011, 02:52:52 pm

Getting somewhere. Here's demo test for bpv4 with interrupt and polling version. Startup device error seems to be gone.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #11 – August 29, 2011, 06:10:30 pm

Here's my final BPv4 work for the day. Almost but not quite.

I could never get USB interrupts to work well, so I put the usb_handler function on timer 2.

I can get a bit of output, but any more than one packet or so and it gags on it. In the image I got unlimited HiZ> prompts, but the m mode command crashed it.

When it crashes it is stuck in WaitInReady();

A simple echo test is ok, there are defines for it in baseIO.c

The main firmware parts:
main.c - usb setup
baseIO.c - functions that pretend to be a UART to work with the old BPv3 code (end of code)

Any help and debugging is greatly appreciated, this is almost there.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #12 – August 29, 2011, 07:12:18 pm

Another release. This one actually works :) Not very well, still lots to do.
*fixed include issues
*added simple single-buffer TX method (works slowly)

The attached firmware should bootload into BPv4 with teh new bootloader and work.

Re: The missing piece: porting BPv4 to the open source USB s

Reply #13 – August 29, 2011, 11:09:27 pm

It seems to crash on the 60th byte added to the buffer. If you send less then this within the timeout period things would go ok (hence the HiZ> get over the line ok)

I studied a bit at the sourcecode and it appears that after 62 chars (line 469 in baseIO.h) a new buffer is filled and the (old) data is transferrred. It seems that the same buffer is used for both and this will hang the uC (the program is accessing the buffer and the USB hardware). I think you should set the pingpong buffers to 3 @ line92 in cdc_config.h THis condition is not handled in the stack atm and raises a compile error.

Need to dive more into it :) just some thoughts for now ;)

Re: The missing piece: porting BPv4 to the open source USB s

Reply #14 – August 30, 2011, 07:16:18 am

OK, I have been looking at this for a while, no progress. A few points:

- USB_PP_BUF_MODE only works for 0, if you set it to 1, 2 or 3 you get a compile error (cdc_config.h line93)
- Current compiled firmware has the same connection error that Ian solved. You have to press reset after plugging in for it to connect to a serial port.
- If you comment out #define DOUBLE_BUFFER (baseIO.c line 455), I guess you get the single buffer mode(right Ian?). I didn't feel any slowness and managed to print out the help in 1 sec or so.
- Out of curiosity I changed FAST_usb_handler() to usb_handler() (baseIO.c line 471), it compiles, attaches to COM port but you cannot connect to it.

OK, one question: I guess when we enable double buffer we first fill a buffer with all the characters, then burst it out in one time, but if we disable it, we send character by character, am I right? Maybe we can check if the buffer is filled or not, then if the buffer is filled, disable writing any more characters to it (like checking if TX buffer is ready when using UART), send the whole buffer, enable buffer write and continue writing to it. I don't know, just an idea that popped in my head right now.