Skip to main content
Topic: Bus Pirate firmware v6.1 development (Read 61178 times) previous topic - next topic

Re: Bus Pirate firmware v6.1 development

Reply #30
Code: [Select]
#define BP_USBLED_ON() TRISB&=(~0x400);LATB|=0x400
#define BP_USBLED_OFF() TRISB&=(~0x400);LATB&=(~0x400)

@JTR That is how it is currently set. I believe it is correct. TRIS is output for both states, LAT is high for on, low for off

@Brent - thank you, I will check into it now.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #31
@Brent - Thank you, the changes are well done and ok, but not what I meant by that item.

With the USB CDC stack the device knows the speed of the serial terminal. If the user sets a bridge from a terminal at 115200, we can start at 115200. If they open the port again from eg arduino bootloader at 57600, we can again adjust to that.

This was a big problem with v3 because people setup UART for eg 57600 and go to bridge mode, but the PC-side UART is still at 115200 and when they swap to Arduino bootloader the programming fails. There is an extra step to use the b menu to set the PC-facing (FTDI chip side) PIC UART to the correct speed.

Your solution solves the issue on v3 by getting the user to match baud rates, but what I had hoped to do was use the USB-CDC meta-data to adjust the outward facing UART automatically depending ont he speed of the virtual serial port settings. JTR just posted a IR Toy firmware in another thread that has this feature, I intend to port it to the BPv4 when I get to see the code.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #32
[quote author="ian"]
Code: [Select]
#define BP_USBLED_ON() TRISB&=(~0x400);LATB|=0x400
#define BP_USBLED_OFF() TRISB&=(~0x400);LATB&=(~0x400)

@JTR That is how it is currently set. I believe it is correct. TRIS is output for both states, LAT is high for on, low for off

[/quote]

Ian, what I posted is what is in the latest BPv4 file I have and it is different from what you have. Don't know if you or I are looking at different places or if you fixed it previously.


//pseudofunctions for USB, MODE LEDs
#define BP_USBLED_ON() LATB&=(~0x400);TRISB&=(~0x400)
#define BP_USBLED_OFF() LATB&=(~0x400);TRISB|=0x400

I know I spent HOURS trying to get the USB LED to work and I just could not believe such a simple thing had me stumped. I know that I did get it to work eventually...

Re: Bus Pirate firmware v6.1 development

Reply #33
[quote author="ian"]@Brent - Thank you, the changes are well done and ok, but not what I meant by that item.

Your solution solves the issue on v3 by getting the user to match baud rates, but what I had hoped to do was use the USB-CDC meta-data to adjust the outward facing UART automatically depending ont he speed of the virtual serial port settings. JTR just posted a IR Toy firmware in another thread that has this feature, I intend to port it to the BPv4 when I get to see the code.[/quote]

The same code will work on the BPv4 if BAUDCLOCK_FREQ is defined in the hardware profile as 16000000. However this is a more efficient version that is available with the C30 math libraries (sadly, not the C18 libraries.)


Code: [Select]
void cdc_set_line_coding_data( void ) {		// JTR handling an OUT token In the CDC stack this is the only function that handles an OUT data stage.

        udiv_t z;  // JTR linecoding. Baudrate is now rounded rather than truncated.

memcpy(&linecodeing, (const void *) bdp->BDADDR, sizeof(struct cdc_LineCodeing));

        z = udiv((BAUDCLOCK_FREQ>> 2), (linecodeing.dwDTERate));
        if (z.quot > (z.rem << 1)) // if the quotient is greater than the remainder * 2
            // I.E. the remainder is not half or greater than quotient
            // then we don't round up
            z.quot--; // PIC's Baud rate generator value is normally -1 of quotient
        // if we are rounding up we simply don't decrement the quotient.
        UART_BAUD_setup(z.quot);

usb_unset_out_handler(0);              // Unregister OUT handler; JTR serious bug fix in macro!
usb_set_in_handler(0, cdc_set_line_coding_status); // JTR why bother?
usb_ack_dat1( rbdp, 0 ); // JTR common addition for STD and CLASS ACK

// JTR This part of the USB-CDC stack is worth highlighting
// This is the only place that we have an OUT DATA packet on
// EP0. At this point it has been completed. This stack unlike
// the microchip stack does not have a common IN or OUT data
// packet complete tail and therefore it is the responsibility
// of each section to ensure that EP0 is set-up correctly for
// the next setup packet.

//  This next line inverts the DTS so that it is now ready for
//  a DAT0 packet. However it only works because we had one data
//  packet. For any amount of EVEN data packets it would not be
//  correct.
// usb_ack_out(bdp);  // JTR N/A Good for only odd number of data packets.

//  The correct thing to do is to force EP0 OUT to the DAT0 state
//  after we have all our data packets.
bdp->BDCNT = USB_EP0_BUFFER_SIZE;
bdp->BDSTAT = UOWN | DTSEN;
}

This code is something that I posted previously but it had to be "pulled" because it would not work with the IR TOY (C18)

Re: Bus Pirate firmware v6.1 development

Reply #34
I have absolutly no knowledge in USB :3

I took out what I added; I understand what you want now. ill try a differnt action item :3

I have a reccomendation though for EEPROM support. I have seen this with the application I work for (I work for the software division of a company) and they have a similure thing with there configuration ini settings; where if needed you can override all the settings to there defaults by using a function to call the eeprom data like:

ReadEEPROM_Byte(ulong Addr, u8 Default)

Then simply in the ReadEEPROM_Byte function simply have:

If((BP_BUTTON_DOWN))
  return Default;
else
  EEPROM_READ_BYTE(ADDR)

or whatever.

Im thinking this might be a good idea because then no matter where in the source you happen to be; you can force the default value by holding down 'Normal' instead of just being on start-up.

Also the button could still be used for more as well.

If you like that idea Ian; that is forsure something I could handle, as in write those functions for future use and document them for development to use.

Re: Bus Pirate firmware v6.1 development

Reply #35
Thanks JTR, I will give that a try.

Brent - that is a great idea. Feel free to run with it! I plan to push v6.1 today.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #36
[quote author="ian"]Thanks JTR, I will give that a try.

Brent - that is a great idea. Feel free to run with it! I plan to push v6.1 today.[/quote]

Great move Ian. I have important updates on the USB stack done on a earlier version. Now I can port them across and we can all be on the same page again. This will save misunderstandings like we have seen on this thread.

There are a few other things that I have eyed off. There is some silicon errata to investigate that may require a hardware change. suggest you look at the latest errata sheet. http://http://ww1.microchip.com/downloads/en/DeviceDoc/80369n.pdf

Re: Bus Pirate firmware v6.1 development

Reply #37
Edit: Ok scrub previous issue posted here.

Instead: For BPv4 and MPLAB X some files need to be added to the project.

Anything like:

1wire*.*
onboardeeprom*.*

Correct linker script. p24FJ256GB106.gld

Re: Bus Pirate firmware v6.1 development

Reply #38
Quote
There is some silicon errata to investigate that may require a hardware change. suggest you look at the latest errata sheet.

I don't know about the USB errata, but the other stuff should be ok. I used this sheet and A3/A4 silicon to design the v4 hardware.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.1 development

Reply #39
[quote author="ian"]
Quote
There is some silicon errata to investigate that may require a hardware change. suggest you look at the latest errata sheet.

I don't know about the USB errata, but the other stuff should be ok. I used this sheet and A3/A4 silicon to design the v4 hardware.[/quote]


I was concerned about the voltage regulator as at first glance it appears that it is used as it is not explicitly turned off in the config words and the schematic shows that it does to a cap. But on closer look it is off by default and the cap is just a standard bypass cap on the rails so she is all good. However there are a couple of things that need to be updated on the USB stack.

Re: Bus Pirate firmware v6.1 development

Reply #40
Hello Ian,

I have integrated the support of XSVF Player within the current 6.1 BP firmware as a new bitbang mode. I have created mode 0x18 for it which looked unused.

As we now need to activate bitbang mode and XSVF Player mode from the PC, I have modified the Windows application too.

The places i made change in sources are identified by a  //---  sequence.

I can now program succesfully my XC9572xl CPLD board

Best Regards
  JM

[attachment=0]
[attachment=1]

Re: Bus Pirate firmware v6.1 development

Reply #41
Just to add the following comments about my previous message :

- This integrated XSVF Player firmware is only compatible with BPv4 hardware. An other solution with a dedicated xsvf player firmware was already available for BPv3.
- Windows application has been compiled with Dev-C++
- The "official" word in the firmware package name only stands for the initial 6.1 release used to build this new one

  JM

Re: Bus Pirate firmware v6.1 development

Reply #42
This development cycle is starting to get really messy. To which source should I be adding features ?
Right now there are about 3-5 different branches for BPv4 (the one in SVN, JTR's 7 package, xsvf player, etc.)

Could someone merge them into one single project ?

Re: Bus Pirate firmware v6.1 development

Reply #43
Hello robots,

I initialy tried to start from the JTR's 7 packages release but unfortunately, the BP4 release (before trying to add xsvf) was not working correctly. It is not identified correctly on PC side.

Then i decided to start from the SVN 6.1 official package.

All the changes i made are identified in source code and it should be quite easy to port them to an other release.

  JM

Re: Bus Pirate firmware v6.1 development

Reply #44
Hi Ian,

I would like to update the Bus Pirate SVN repository with the changes i made to support a fully integrated XSVF Player for BP4 and with the Windows associated application. I published these releases a few posts upper.

Can you please send me a password in order i can get access to upload my files.

Best regards
  JM