Bus Pirate v6.1 development thread
Would like to:
[s:]*Detect v3b/v3.5/eBay versions (uses different chip/id) and show in v3[/s:]
[s:]*V4 firmware doesn't detect chip revision correctly[/s:] seems ok
*OpenOCD to v4?
*XSVF integrated to v4?
[s:]*Do we need the USB updates from IR Toy for 8 and 48 byte errors[/s:]
[s:]*Add autobaud to macro too
*Trim the autobaud text a little for size
*Move SVN completely to DP, update old SVN with forwarder[/s:]
*EEPROM use in v4?
---
v4 fixes
*read bootloader version info
[s:]*Correct version detect (this should be A1 I think)[/s:] seems ok
*update bootloader jump. Should disable USB pullups and pause 10 seconds so computer sees it go away
*UART bridges, etc should match the virtual serial port setting (or offer to)
*Put easter egg back
*Something useful with EEPROM
*Add STK500 mode, make stick with EEPROM setting
*NORMAL button overrides any EEPROM settings for rescue
[s:]*Bus Pirate bitbang mode IO fix:[/s:] viewtopic.php?f=28&t=3403&p=34198#p34196 (http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=3403&p=34198#p34196) Thanks tes!
---
Pietja:
[s:]*Fix the USB led[/s:]
*Support for a passive LCD adapter
----
[s:]Make baud detection sample 10 bit samples x 3 calculation samples before submitting baud
Make the 'Nearest Common Baud' function smarter[/s:]
Fix translation files names (eg BPv4*.h & BPv3*.h instead of how they are now, as they are confusing)
[quote author="ian"]*The self-test expects a connection between ADC and +5V "Connect (ADC to +5V)" however you cant fit a jumper between those pins, you can fit a jumper between ADC and +3.3V.
So change the expected voltage from 5v to 3.3v.[/quote]
I have already submitted a code for this, is it still the old one? It was basically a change of 2 lines.
BTW, shall I continue developing code for SMPS board (pic programming adapter)?
I have already submitted a code for this, is it still the old one? It was basically a change of 2 lines.
Probably, this is a to-check list from an old thread that I unstickied. Don't put too much stock in it.
BTW, shall I continue developing code for SMPS board (pic programming adapter)?
Please, that would be great, and means v4 can program also the new chips.
YAY :D This should be fun. Im starting to know PICs much better, so this should be really fun!
Also add:
Make baud detection sample 10 bit samples x 3 calculation samples before submitting baud
Make the 'Nearest Common Baud' function smarter
Fix translation files names (eg BPv4*.h & BPv3*.h instead of how they are now, as they are confusing)
Whats the 'Autobad' macro too? So instead of just saying the baud there should also be a macro to set the baud rate?
I was thinking a macro that does the autobaud measurement in addition to the autobaud setting in the setup menu. That way you could do (5) and it will run the measurement routine and report (but not set...) the baud of the serial traffic.
[quote author="ian"]Bus Pirate v6.1 development thread
Would like to:
*OpenOCD to v4?
[/quote]
?? I looked at the what I had here and the port appeared to be done AFAIK. I mean the USB part of it. What am I missing?
[quote author="ian"]
*Do we need the USB updates from IR Toy for 8 and 48 byte errors
[/quote]
No, the BPv4 enters double buffer mode and stays there unlike the IR TOY pre IR TOY 2012 that switched modes leaving its left flank open for a surprise attack by phantom zombie non-existent bytes.
[quote author="ian"]
*Move SVN completely to DP, update old SVN with forwarder
[/quote]
Would be great if it could be intergrated with MPLAB X sub version.
[quote author="ian"]
*read bootloader version info
[/quote]
I thought you had done that already. I seem to remember it was the last hold up with the V1 dp30 bootloader.
[quote author="ian"]
Make the 'Nearest Common Baud' function smarter
[/quote]
Personally, I would trust the auto baud detect to find the best baud rate. That way if it is connected to something running from an internal RC oscillator any error is adjusted for.
?? I looked at the what I had here and the port appeared to be done AFAIK. I mean the USB part of it. What am I missing?
I need to double check, but I recall noting that the Open OCD mode robots wrote used the UART interrupt and UART hardware directly, I thought that part had not been ported yet. I believe I also noted an error changing into that mode on Bus Pirate v4. I would be happy to be mistaken :)
Thanks for clarifying that we don't need updates to the USB part.
[quote author="ian"]I was thinking a macro that does the autobaud measurement in addition to the autobaud setting in the setup menu. That way you could do (5) and it will run the measurement routine and report (but not set...) the baud of the serial traffic.[/quote]
oh thats still there.
[quote author="ian"]
?? I looked at the what I had here and the port appeared to be done AFAIK. I mean the USB part of it. What am I missing?
I need to double check, but I recall noting that the Open OCD mode robots wrote used the UART interrupt and UART hardware directly, I thought that part had not been ported yet. I believe I also noted an error changing into that mode on Bus Pirate v4. I would be happy to be mistaken :)
[/quote]
Sadly, you are not mistaken, even sadder, I am. Indeed there is an interrupt driven aspect that is not ported. Is the source code for V6 in the SVN?
Possible changes required to openOCD.c. Not tested but it is a starting point and by some fluke it may actually work.
Note the the asm code will need to be changed so as to NOT transmit the TX data, instead just buffer it until it RETURNS.
case CMD_TAP_SHIFT:
inByte = UART1RX();
inByte2 = UART1RX();
IFS0bits.U1RXIF = 0; // reset the RX flag
j = (inByte << 8) | inByte2; // number of bit sequences
// this fixes possible buffer overflow
if (j > 0x2000)
j = 0x2000;
i = (j + 7) / 8; // number of bytes used
buf[0] = CMD_TAP_SHIFT;
buf[1] = inByte;
buf[2] = inByte2;
binOpenOCDAnswer(buf, 3);
UART1RXBuf = (unsigned char*) bpConfig.terminalInput;
UART1RXToRecv = 2 * i;
UART1RXRecvd = 0;
UART1TXBuf = (unsigned char*) (bpConfig.terminalInput + 2100); // 2048 bytes + 3 command header + to be sure
UART1TXSent = 0;
UART1TXAvailable = 0;
#ifdef BUSPIRATEV4
do {
WaitOutReady();
UART1RXRecvd += getsUSBUSART((bpConfig.terminalInput + UART1RXRecvd), CDC_BUFFER_SIZE); //JTR2
} while (UART1RXRecvd != UART1RXToRecv);
#else
// prepare the interrupt transfer
// enable RX interrupt
IEC0bits.U1RXIE = 1;
#endif
binOpenOCDTapShiftFast(UART1RXBuf, UART1TXBuf, j, OpenOCDJtagDelay);
#ifdef BUSPIRATEV4
for (UART1TXSent = 2100; UART1TXSent < (2100 + UART1TXAvailable); UART1TXSent++) {
UART1TX(bpConfig.terminalInput[UART1TXSent]);
};
#endif
break;
default:
buf[0] = 0x00; // unknown command
buf[1] = 0x00;
binOpenOCDAnswer(buf, 1);
break;
Thanks JTR, I will try to test, and also invite robots to give some feedback.
[quote author="JTR"]Possible changes required to openOCD.c. Not tested but it is a starting point and by some fluke it may actually work.
Note the the asm code will need to be changed so as to NOT transmit the TX data, instead just buffer it until it RETURNS.
[/quote]
Just buffering will make it slow. The beauty of the original design is, that it can transfer data back to host while still receiving and processing incoming data. (not just buffering them).
I think the idea would be to put the data into the "output" buffer. When usb is ready it would just take the processed chunk.
This would require minimal changes to the asm routine.
If 0.03 seconds per 2100 bytes less time saved is blowing the budget then of course it would be easy enough to re arrange the code like that. It would be my instinct to do that even though I cannot agree (having done some basic math) that it will make the BPV4 "slow." Possibly marginally slower, like one second over 64kB.
However, the other side of the coin is that it is not "faster" like it could be. The BPv4 should blow the BPv3 away if the transfers are interleaved. The USB coms aught to be 2.5 - 3x faster plus time saved by dumping the UART ISR plus the extra 4MIPS to play with.
Everything else I have done with the IR TOY and the BPv4 goes to some length to double buffer and interleave all the transfers and there are plenty of examples showing the code. If that could be ported to within the ASM code that would be fantastic.
I am not really familiar with the USB and CDC code used in BP firmware. Is there some documentation of the USB stack implementation ? I have just briefly looked at the code and there are few things i don't understand:
- Why is the (fast)usb_handler called from user code ?
- is the timer T1 needed? The code could have been triggered by USB SOF interrupt.
The original Openocd code I have written is here (C implementation):
http://code.google.com/p/the-bus-pirate ... nOCD.c#310 (http://code.google.com/p/the-bus-pirate/source/browse/v4.3/source/OpenOCD.c#310)
This one can be easily modified to use UART1RX and UART1TX functions. (the new USB buffered functions, wouldn't work reliably with the UART peripheral). I just hope that JTAG won't mind the jitter introduced by the USB code.
[quote author="robots"]I am not really familiar with the USB and CDC code used in BP firmware. Is there some documentation of the USB stack implementation ? I have just briefly looked at the code and there are few things i don't understand:
- Why is the (fast)usb_handler called from user code ?
- is the timer T1 needed? The code could have been triggered by USB SOF interrupt.
[/quote]
The USB stack needs to be serviced periodically, to ensure that setup packets are not blocked as this is a requirement of the USB spec. We also need to clear the USB TRNIF flag that is set after every usb transaction otherwise the PICs USB FIFO will fill and then block any and all new transfers. That is why there is a sprinkling of calls to the USB handler that generally have a one to one relationship to each packet we send or receive. If we put the USB stack on interrupts we do not need to call the handler but the effect of this is that we surrender deterministic timing for our I/O routines and this is not desirable IMHO. By polling the usb stack we can interleave the stack servicing in "dead time."
Regarding the use of T1, this is simply a throw back to the way both early versions of the BPv4 and IR TOY were coded when they used the microchip stack. It is not necessary and indeed the SOF can be used. I have long removed the use of T1 from the IR TOY and the BPv4 will follow at some stage.
At this time the usb stack used on the BPv4 is an earlier version and somewhat outdated. However it works and I imagine that slowly over 2012 it will be updated to use the latest and greatest stack now that many niggles are understood and the differences in how the stack needs to work in different ways between the IR TOY and BPv4 are accounted for.
[quote author="robots"]
The original Openocd code I have written is here (C implementation):
http://code.google.com/p/the-bus-pirate ... nOCD.c#310 (http://code.google.com/p/the-bus-pirate/source/browse/v4.3/source/OpenOCD.c#310)
This one can be easily modified to use UART1RX and UART1TX functions. (the new USB buffered functions, wouldn't work reliably with the UART peripheral). I just hope that JTAG won't mind the jitter introduced by the USB code.[/quote]
I cannot see any grounds for your concerns. You seem to be overlooking that even on the BPv3 the comms goes through an FTDI chip and this also is going to turn a data stream into packets and introduce some amount of "jitter." Perhaps at this point I will point out that by default the FTDI chip wait 16ms before sending back short packets.
16ms!
Nowhere in any dangerous prototypes documentation is this even mentioned. Can't be that much of a problem now, can it?
As it is the BPv4 firmware will execute 160 instruction cycles in the time it takes the BPv3 to receive 1 (ONE!) byte via the UART. And the BPv4 is receiving packets of 64 Bytes and is double buffered. "Jitter" on the BPv4??
At worst on the BPv4 there is a one off 0.5ms average overhead cost for the whole block of data whether it is one byte or 1MB. Compare that to the accumulated overhead of having to send two extra bits per byte via the hardware UART, plus the ISR and at only 1Mb/s. Run the BPv4 through a USB 2.0 hub and that average overhead will be around 64us. Again, as for the FTDI latency timer setting, I have not seen anyone discuss the use of a USB 2.0 hub and its effects on transfer times.
I would suggest the best way to intergrate the OCD code into the BPv4 is to break the asm file up to handle chucks of 64 bytes and call it in between packet arrivals and departures in the C code. That way you don't need to worry about the usb part and the slight additional overhead may well be less than the overhead savings by the elimination of the ISR.
I was not really looking for an argument. But ...
160instruction but not in OpenOCD mode. In Openocd mode that is more like 16-20instructions. OpenOCD mode runs with 1Mbit/s serial speed. And the PIC24 is running @ 16Mips.
16ms on way back (meaning CHIP to host) not the other way around. The other way around, it is ~1ms. 16ms is not my concern, openocd can handle that.
When FTDI receives packets from host, it puts the data info fifo, and spits those bytes to UART evenly spaced. The UART ISR is small compared to USB ISR handler. Even if there is no interrupt to be served the USB will take longer to finish than the UART isr.
In BBv3 you have small ISR that is executed every time byte is received/transmitted. This creates small jitter for every byte transferred on Jtag bus.
In BBv4 you have huge USB ISR that is to be executed once every 64bytes are received/transmitted. (Thats 64bytes transfered with no jitter at all, and one big pause - when entering the usb isr).
What I have not taken into account is the periodic 1ms poking from host that needs to be served. Creating another jitter on the Jtag bus.
Do you still think that there is no jitter!?
Now back to topic.
I think that best way would be to make BP understand JTAG commands, at least the high level commands (like scan, run test, etc) that OpenOCD uses. This would reduce the number of bytes transfered. And for some cases the internal SPI peripheral could be used (transfer data with size of multiple of 8)
I have had this idea for a long time, but there was not enough space in the BBv3 to implement it in.
[quote author="robots"]I was not really looking for an argument. But ...
160instruction but not in OpenOCD mode. In Openocd mode that is more like 16-20instructions. OpenOCD mode runs with 1Mbit/s serial speed. And the PIC24 is running @ 16Mips.
[/quote]
Quoting myself "As it is the BPv4 firmware will execute 160 instruction cycles in the time it takes the BPv3 to receive 1 (ONE!) byte via the UART"
Notice I said BYTE so the equation is the same.
[quote author="robots"]
16ms on way back (meaning CHIP to host) not the other way around. The other way around, it is ~1ms. 16ms is not my concern, openocd can handle that.
[/quote]
You mean it is in the same ball park with the BPv4 usb stack?
[quote author="robots"]
When FTDI receives packets from host, it puts the data info fifo, and spits those bytes to UART evenly spaced. The UART ISR is small compared to USB ISR handler. Even if there is no interrupt to be served the USB will take longer to finish than the UART isr.
In BBv3 you have small ISR that is executed every time byte is received/transmitted. This creates small jitter for every byte transferred on Jtag bus.
In BBv4 you have huge USB ISR that is to be executed once every 64bytes are received/transmitted. (Thats 64bytes transfered with no jitter at all, and one big pause - when entering the usb isr).
What I have not taken into account is the periodic 1ms poking from host that needs to be served. Creating another jitter on the Jtag bus.
Do you still think that there is no jitter!?[/quote]
This is a huge USB stack?
BYTE FAST_usb_handler(void) {
if (USB_RESET_FLAG) {
usb_handle_reset();
ClearUsbInterruptFlag(USB_URST);
}
if (USB_TRANSACTION_FLAG) {
trn_status = GetUsbTransaction();
if (USB_STAT2EP(trn_status)) {
usb_handle_transaction();
ClearUsbInterruptFlag(USB_TRN); // EP0 only
return 0x0;
} else {
ClearUsbInterruptFlag(USB_TRN); // non-EP0 only
return 0;
}
}
return 0;
} usb_handle_transaction is only called if something really has gone wrong in the USB bus. The same would also happen if the FTDI chip was fitted. In pratise this does not happen. Again if it did, the FTDI chip would also have to abort the transfer.
Here is a disassembly is the BPv4 FAST_usb_hander:
891: BYTE FAST_usb_handler(void) {
07F30 FA0002 lnk #cmp_id_bit
892: if (USB_RESET_FLAG) {
07F32 BFC48A mov.b 0x048a,w0
07F34 604061 and.b w0,#1,w0
07F36 E00400 cp0.b w0
07F38 320006 bra z, 0x007f46
893: usb_handle_reset();
07F3A 07FBD4 rcall usb_handle_reset
894: ClearUsbInterruptFlag(USB_URST);
07F3C 200010 mov.w #0x1,w0
07F3E 882450 mov.w w0,0x048a
895: return 0xFF;
07F40 200FF0 mov.w #0xff,w0
07F42 780F00 mov.w w0,[w14]
07F44 370019 bra 0x007f78
896: }
897: if (USB_TRANSACTION_FLAG) {
07F46 BFC48A mov.b 0x048a,w0
07F48 604068 and.b w0,#8,w0
07F4A E00400 cp0.b w0
07F4C 320013 bra z, 0x007f74
898:
899: trn_status = GetUsbTransaction();
07F4E 802490 mov.w 0x0492,w0
07F50 784080 mov.b w0,w1
07F52 224B80 mov.w #0x24b8,w0
07F54 784801 mov.b w1,[w0]
900: if (0 != USB_STAT2EP(trn_status)) {
07F56 224B80 mov.w #0x24b8,w0
07F58 784010 mov.b [w0],w0
07F5A FB8000 ze w0,w0
07F5C DE0044 lsr w0,#4,w0
07F5E FB8000 ze w0,w0
07F60 60006F and.w w0,#15,w0
07F62 E00000 cp0.w w0
07F64 320003 bra z, 0x007f6c
901: ClearUsbInterruptFlag(USB_TRN); // non-EP0 only
07F66 200080 mov.w #0x8,w0
07F68 882450 mov.w w0,0x048a
07F6A 370004 bra 0x007f74
902: } else {
903: usb_handle_transaction();
07F6C 07FC17 rcall usb_handle_transaction
904: return 0xFF;
07F6E 200FF0 mov.w #0xff,w0
07F70 780F00 mov.w w0,[w14]
07F72 370002 bra 0x007f78
905: }
906: }
907: return 0;
07F74 EB0000 clr.w w0
07F76 780F00 mov.w w0,[w14]
07F78 78001E mov.w [w14],w0
908: }
07F7A FA8000 ulnk
07F7C 060000 return
28 instructions @ 16MIPS to check that there has not been a bus reset or setup packet and to clear the transfer flag. If either of the first two happened then the whole transfer should be aborted in any case. Same deal with the FTDI chip, if you had a way of knowing they happened that is.
28 instructions @ 16MIPS is less than 2us.
About the same as time as the start + stop bit of a single byte sent via the UART. If that is too much "jitter" for you I can always dump the test for a bus reset and set up packet as they should not really happen.
How about:
ClearUsbInterruptFlag(USB_TRN); // non-EP0 only
07F66 200080 mov.w #0x8,w0
07F68 882450 mov.w w0,0x048a
Two instructions and no call overhead. I have actually done this on the latest IR TOY but there is a BIG difference between the PIC24 and PIC18 performance and such short cuts are just not required on the PIC24.
The context save alone for a PIC24 ISR is 14 instructions...
533: void __attribute__((interrupt, address(0xF00), no_auto_psv)) _T1Interrupt() {
00F00 F80036 push.w 0x0036
00F02 BE9F80 mov.d w0,[w15++]
00F04 BE9F82 mov.d w2,[w15++]
00F06 BE9F84 mov.d w4,[w15++]
00F08 BE9F86 mov.d w6,[w15++]
00F0A FA0000 lnk #c
00F4E FA8000 ulnk
00F50 BE034F mov.d [--w15],w6
00F52 BE024F mov.d [--w15],w4
00F54 BE014F mov.d [--w15],w2
00F56 BE004F mov.d [--w15],w0
00F58 F90036 pop.w 0x0036
00F5A 064000 retfie
I am not trying to argue either. I am just pointing out that your concerns are not founded. At this point I hope you can see that...
While we still working on the bootloader we still need to fix the PID to use the DangerousPrototypes one.
[quote author="pietja"]Everything uses the MC VID (0x04D8) around here ;) we only get the PID from them.
Right now the bootloader uses the MC PID (0x000A) and not the DP PID (0xFAFF).
This is also in the .inf so before Seeed Studio ships any BPv4 the bootloader and the .inf should be updated to use the right VID_0x04D8 PID_0xFAFF combination.
in "bootloaderboot_config.h"
"#define USB_PID (0x000A)"
should be
"#define USB_PID (0xFAFF)"
and twice in "infmchpcdc.inf"
"%DESLOADER%=DriverInstall, USBVID_04D8&PID_000A"
should be
"%DESLOADER%=DriverInstall, USBVID_04D8&PID_FAFF"[/quote]
Alright;
I have fixed all the baud detection related fixes commited; including:
Add autobaud macro too
Trim autobaud text a little for size
make baud detection sample 10 bit samples x 3 calculated samples
Make the nearest common baud function smarter
So these can be taken off the list or better yet strikes out.
Add autobaud macro too:The Autobaud macro never left; its available in both v3 and v4; no update needed
Trim autobaud text a little for size:I cut the text used for the function down in both v3 and v4 translation files
make baud detection sample 10 bit samples x 3 calculated samples:After talking with Arhi we decided that this is not neccissary for multiple reasons; no updated needed.
Make the nearest common baud function smarter:Updated. The function should be much smarter now. It now goes through the common baud list and minuses it from the calculated baud and only keeps the smallest distance between them. so your left with the common baud rate nearest the calculated. I do have a couple ideas to optimize it; will implement in the future. it is NOT any bigger then the last function; so no worries about v3 it fits fine (tested).
Attached is patch that fixes some things in OpenOCD mode:
- ADC now uses defines for different HW (you will get more readings on BPv4)
- removed Serial speed setting for BPv4 (relevant only for v3)
- added tap shift function for BPv4, this is highly non-optimal solution, and I just want to have something that is working :-)
Another patch contains change to the usbbuf structure. I have implemented FIFO that can
hold 2 USB packets. The asm openocd routine is written in a way that it eats 4 bytes at a time (16bit * 2 - tdo, TMS).
This way there will be always enough data to consume. (except for the last "cycle" when bit_count % 16 != 0)
Size of fifo is CDC_BUFFER_SIZE * 2 + 1, because of the properties of the fifo. The max fill is size-1.
I consider these two to be a small step towards the optimized OpenOCD routine.
Next step will be to fix OpenOCDtapshift to use usbbuf.buf, with indexes modulo USB_BUFFER_SIZE.
Last patch (baseio_patch) removes some unused junk from baseIO.c.
BTW I have not tested this code. I don't own v4 hardware to test it on.
I would be glad if someone can review, comment on these patches.
Thanks Brent, it looks good. I added an alpha compile with that fix to the first post.
Thanks robots - I will send you a BPv4.
I also fixed an error in SUMP logic analyzer mode (tested v3 but not v4). The input tracking variable was made not-static at some point and long commands were not properly received and executed.
HiZ>i
Bus Pirate v3.5
Firmware v6.1-a1 r1662 Bootloader v255.255
DEVID:0x0447 REVID:0x3042 (24FJ64GA002 B4)
http://dangerousprototypes.com
HiZ>
Expanded hardware version detect. Now detects v3a, v3b, v3.5, and knows the sandbox electric clone by its wrong PIC ID. Latest compile is attached to lead post.
//now check the revision
//Version | RB3 | RB2
//2go, 3a | 1 | 1
//v3b | 1 | 0
//v3.5 | 0 | 0
Can anyone describe the issue with the USB LED on v4? The early v4 was an open collector output, but the production version is normal H/L. The hardware profile seems to do that correctly.
[quote author="ian"]Can anyone describe the issue with the USB LED on v4? The early v4 was an open collector output, but the production version is normal H/L. The hardware profile seems to do that correctly.[/quote]
Have you turned OFF the JTAG enable in the config words?
Hy all, today a wanted to communicate with my MS5540C so i used the 3Wire protocol but the MOSI out not worked as expected.
After a fast dig in source i found the bbPins try to use the LATB but in the bpv4 the MOSI coneccted to D port.
So here the patch:
--- Firmware/bitbang.c 2012-01-07 00:12:08.000000000 +0200
+++ Work/bitbang.c 2012-01-09 16:17:22.000000000 +0200
@@ -271,7 +271,7 @@
IODIR &=(~pins);//direction to output
}else{
if(modeConfig.HiZ==0){
- LATB |= pins;//normal output high
+ IOLAT |= pins;//normal output high
IODIR &=(~pins);//direction to output
}else{
IODIR |= pins;//open collector output high
After this patch BP4 working as expected, i can read the values from sensor.
Another question: I want to use the BP with RS485 so i must control the direction with AUX1/2 but how to control in transparent uart and binary mode?
Thank you for the patch. I will commit it.
Another question: I want to use the BP with RS485 so i must control the direction with AUX1/2 but how to control in transparent uart and binary mode?
I'm sorry, there is no support for that yet.
Yes, JTAG OFF is set. Thank you for the suggestion.
[quote author="ian"]Yes, JTAG OFF is set. Thank you for the suggestion.[/quote]
Are you sure you have fixed this in hardwarev4a.h?
//pseudofunctions for USB, MODE LEDs
#define BP_USBLED_ON() LATB&=(~0x400);TRISB&=(~0x400)
#define BP_USBLED_OFF() LATB&=(~0x400);TRISB|=0x400
Firmware Update/Commit on action item list:
ActionItem: *UART bridges, etc should match the virtual serial port setting (or offer to)(Went with Offered too, always better then forcing)
Ian,
I have commited a update to the UARTmacro function that allows the user to auto set the bauds to match for bridge.
2 Files affected:
UART.c (Main update)
bade.h (Added define to disable/enable it. Also so its easy to delete; just delete everything within the define)
Notes:- First it makes modeConfig = bpConfig (not bpConfig = modeConfig, im not sure which way you want it.)
- It is hidden behind a ENABLE_MATCHBAUDBRIDGE_BETA define in base.h so it can be disabled or enable (currently enabled)
- Because the speeds are not stored as bauds; they are stored as BRG's. I had to use a simple math formula to show the user what each UART is set too, but it comes out as (13334=300 for example, it shows 301.0000442) So I also used my, much smarter 'get nearest common baud' to fix that and make it readable. (That was updated as well, see log or diff file).
- I cant test this at the moment; but it works the same way as my UARTsetup update i did that allows the user to type in his own BAUD instead of a BRG. And I know that works. so it should, so please try it and let me know.
- Enabled on BUSPIRATEV4 define only; will not be available on BPv3.
- Also note; at this time only the BAUD rate is changed; nothing else is changed. It inherits what the user setup for the UART mode (modeConfig) and uses that. but if the full UART2setup should mimic the bpConfig setup that is just a matter of setting a couple variables; not a big deal.
So please review the changes, and let me know if it works and if its appropriate or if there is abetter way you wish to do it.
#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.
@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.
[quote author="ian"]
#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...
[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.)
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)
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.
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 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
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
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 author="ian"]
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.
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]
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
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 ?
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
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
The branch I am currently submitting my patches against is this one:
http://code.google.com/p/dangerous-prot ... Bus_Pirate (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn%2Ftrunk%2FBus_Pirate)
I will work on cleaning up the mess this week, and plan to release v6.2 :)
Thanks JM! Please check this out and send me your google code email and I'll add you to to the SVN:
http://dangerousprototypes.com/docs/Using_SVN (http://dangerousprototypes.com/docs/Using_SVN)
Hello ian,
That is done. Revision number is 1857.
Best Regards
JM
Greetings,
I'm new to the forum and recently discover the capabilities of using the device as xsfv player. Does any try to use this to program the PROM memory XCF02S or anyother? Is that possible? What about altera devices?
Thanks in advance