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

Re: Bus Pirate firmware v6.2 development

Reply #1
BPv4 SUMP mode should be on PORTD and not PORTB?

The change notifications SPRs also need to be reworked too?

Re: Bus Pirate firmware v6.2 development

Reply #2
Nice catch, thank you. Added to the list.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.2 development

Reply #3
Hopefully somebody will cross check this. I have known to be wrong before. One time at least when I thought I was wrong but really I was right :)

Code: [Select]
                        case SUMP_TRIG: //set CN on these pins

                            //BPv3
                            //      PORTB0, PORTB1, PORTB2, PORTB3, PORTB4, PORTB5, PORTB6, PORTB7, PORTB8, PORTB9, PORTB10
                            //PIN      4      5        6      7      11    14    15      16      17      18      21
                            //CN      4      5        6      7      1      27    24      23      22      21      16
                            //CNEN                                                  2:8    2:7      2:6    2:5    2:0
                            //Func                                                  CS      MISO    CLK    MOSI    AUX1


                            //BPv4

                            //      PORTD0, PORTD1, PORTD2, PORTD3, PORTD4, PORTD5, PORTD6, PORTD7, PORTD8
                            //PIN      46    49      50      51      52    53    54      55      42
                            //CN      49    50      51      52      13    14    15      16      53
                            //CNEN    4:1    4:2    4:3      4:4    1:13  1:14  1:15    2:0      4:5
                            //func    AUX2  MOSI    CLK      MISO    CS    AUX0                    AUX1

#ifdef BUSPIRATEV4                   
                            if (sumpRX.command[1] & 0b1000000) CNEN4 |= 0b10; //AUX2
                            if (sumpRX.command[1] & 0b100000) CNEN4 |= 0b100000; //AUX1
                            if (sumpRX.command[1] & 0b10000) CNEN1 |= 0b100000000000000; //AUX0
                            if (sumpRX.command[1] & 0b1000) CNEN4 |= 0b100; // MOSI
                            if (sumpRX.command[1] & 0b100) CNEN4 |= 0b1000; // CLK
                            if (sumpRX.command[1] & 0b10) CNEN4 |= 0b10000; // MISO
                            if (sumpRX.command[1] & 0b1) CNEN1 |= 0b10000000000000; // CS
#else                   
                            if (sumpRX.command[1] & 0b10000) CNEN2 |= 0b1; //AUX
                            if (sumpRX.command[1] & 0b1000) CNEN2 |= 0b100000; // MOSI
                            if (sumpRX.command[1] & 0b100) CNEN2 |= 0b1000000; // CLK
                            if (sumpRX.command[1] & 0b10) CNEN2 |= 0b10000000; // MISO
                            if (sumpRX.command[1] & 0b1) CNEN2 |= 0b100000000; // CS
#endif

Re: Bus Pirate firmware v6.2 development

Reply #4
Hello. I'm a newcomer here, though I'm not new to C nor PIC's.
I have managed to build successfully the 6.1 version of the Bus Pirate undel linux, using pic30-gcc toolchain & Eclipse CDT IDE as environment. If you want, I'd like to help in the development, at least I can help in configuring Eclipse for compiling & linking.
Best regards

Re: Bus Pirate firmware v6.2 development

Reply #5
Hi rmd,

That would be great. I am going to roll out v6.2 with JTR's updates and a few others hopefully by the end of this week.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.2 development

Reply #6
Ian,

What can I do? Its been a little while sence I got to code for the BP :D but thats because most of those items are a bit out of my league still. Im still trying to learn about how the PIC configurations work (They are not like AVR fuse settings from what I understand) So I am a bit behind. So items like make the STK500 mode work (which I would love too do; if I understood it a bit better) and OpenOCD...

I can:
* fix the translation files
* EEPROM in v4 is done; I have already created the Read and Write byte for the EEPROM and its already in OnBoardEEPROM source files. Though at the moment it reads or writes without careing what the NORMAL button is; which is good there should be a sepeare function for reading eeprom where it cares about the NORMAL button:
** I can create something like an 'bpReadSetting(Addr,Default)' like we said before; where if the NORMAL button is down it returns 'Default' otherwise the byte at Addr in eeprom.
* I can also uncomment the easter egg; unless you wanted to make it different in version 4 :)

Let me know what you would like me to tackle; I would enjoy performing the EEPROM functions and because its not PIC specific I know I can handle that easily; but I dont want to design a bunch of functions then find out you had a differnt idea of how the EEPROM settings should work... let me know.

edit: infact; if you would; explain how you forsee the EEPROM working as in how addresses will be set for everything (should it be a .h file full of defines eg: BP_EE_STARTMODE_ADDR 1333 and BP_EE_STARTMODE_DFLT 0). And what type of support the eeprom functions should have; as in just byte by byte? or should there be a read/write string function? or what would you like to do?

Re: Bus Pirate firmware v6.2 development

Reply #7
Quote
** I can create something like an 'bpReadSetting(Addr,Default)' like we said before; where if the NORMAL button is down it returns 'Default' otherwise the byte at Addr in eeprom.
* I can also uncomment the easter egg; unless you wanted to make it different in version 4 :)

Both of these would be ideal! Thank you.

Quote
infact; if you would; explain how you forsee the EEPROM working as in how addresses will be set for everything (should it be a .h file full of defines eg: BP_EE_STARTMODE_ADDR 1333 and BP_EE_STARTMODE_DFLT 0). And what type of support the eeprom functions should have; as in just byte by byte? or should there be a read/write string function? or what would you like to do?

Here are my ideas -
1. Keep the first few pages free for user experimentation, put saved stuff at the end
2. We'll need a function that can take a struct and save it to EEPROM (and load it back) in the 8byte (?) sectors used in the EEPROM

Allocation something like this:
1) 2 pages (64 bytes I think) for saving bpConfig struct and some extra. This should include the startup modes (eg xsvf, STK500v2). There is also extra room for expansion (maybe too much!)
2) one page (?) per mode to save mode presettings. Settings are stored at (page + bp mode number) offsets. Leave some extra pages for new modes maybe?
3)Section to store scripts (maybe at the very end?)
4) section to store macros (the <1> <2> stored macros). If we store 10 macros, maybe it should be prefaced with a 10byte allocation table. The allocation table tells the Bus Pirate where in the macro storage area each macro sits, that would let us do a mix of sizes of macros, rather than allocate a fixed area for each. So to find macro 2 start point, lookup the value for 2 in the table and go to that offset. If the area is bigger than 256 bytes, then the offset table could be multipled by eg 2,4, or 8 etc.
5) Maybe a place to store the user's name or the Bus Pirate's "name". We might even use this with the USB descriptor.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.2 development

Reply #8
Hy,

My bp4 not working in UART bridge mode (1), it sending but fail to receive. The live watch macro working. Connected together the TX and RX and after few keypress the Mode led turning off (overrun).
I checked the source, it seems to be fine, but...
So i added a break on rx, if i press a key it's stoping, and if i press 'r' then give 0x00 and again and again. But if i don't read with 'r' and enter again into (1)macro then fail to enter again in rx and no break!
So i changed to this:
Code: [Select]
//				if((U2STAbits.URXDA==1)&& (U1STAbits.UTXBF == 0)){
if((U2STAbits.URXDA==1)){
UART1TX(U2RXREG);
//U1TXREG = U2RXREG; //URXDA doesn't get cleared untill this happens
//break;
}
Now it's fine, working as expected but why? Somebody can explain?

Re: Bus Pirate firmware v6.2 development

Reply #9
What?

Re: Bus Pirate firmware v6.2 development

Reply #10
Code: [Select]
if((U2STAbits.URXDA==1)&& (U1STAbits.UTXBF == 0))
This line check if any received in txbuf AND if tx buffer ready THEN copy U1TXREG = U2RXREG;
If tx buffer not free wait in external loop.
But not working.(only for me???)

Then with my change
Code: [Select]
if((U2STAbits.URXDA==1)) UART1TX(U2RXREG);
This line check if anything in rxbuf THEN check OR wait on INSIDE LOOP for tx ready then copy the char to U1TXREG.

Again the question, where is the problem in first implementation? Because my implementation add wait on rx when usbtx full,  if anything coming from usb will not handled as well. So it's not preferable but working for me.

Re: Bus Pirate firmware v6.2 development

Reply #11
Hello,

I have used BPv4 to generate a signal using G command to check a PIC18f based frequency measurement.
Then i have seen some differences between the frequency set in the G command and the effective frequency.

I then would suggest, in the "PWM active" answer to the G command to display the effective frequency and effective pulse width ratio.

Best Regards
  JM

Re: Bus Pirate firmware v6.2 development

Reply #12
@tes - thanks for the bug report. That appears to be a system that has not yet been adapted to the new USB drivers. (U1STAbits is no longer used in bpv4.

@JM - thanks for the suggestion. The PWM freq is not exact, but the closest that the PIC can deliver with the given clock and dividers.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate firmware v6.2 development

Reply #13
on BP V4 I try to run a continuous voltage measure command D, it freezes after a few seconds.
and is there a way to calibrate the voltage measurement ? it`s a little off on my BP.

regards,
Cosmin

Re: Bus Pirate firmware v6.2 development

Reply #14
[quote author="tes"]
Code: [Select]
if((U2STAbits.URXDA==1)&& (U1STAbits.UTXBF == 0))
This line check if any received in txbuf AND if tx buffer ready THEN copy U1TXREG = U2RXREG;
If tx buffer not free wait in external loop.
But not working.(only for me???)

Then with my change
Code: [Select]
if((U2STAbits.URXDA==1)) UART1TX(U2RXREG);
This line check if anything in rxbuf THEN check OR wait on INSIDE LOOP for tx ready then copy the char to U1TXREG.

Again the question, where is the problem in first implementation? Because my implementation add wait on rx when usbtx full,  if anything coming from usb will not handled as well. So it's not preferable but working for me.[/quote]


There is little wrong with what you have done. It is correct for the BPv4 but not for the BPv3. The only thing that needs to be added is conditional compile directives for the different BP versions. The usb stack will pretty much always be ready to receive a byte so you do not need to test for it as the usb stack does not return to user code until there is at least one buffer available. It provides handshake by blocking if (like, never) both buffers are full.