Is it possible with the current firmware to use the bus pirate as a uart bridge ? If prototyping, it isn't always practical to implement a 232 chip, and using the bus pirate for this task would be sweet indeed. If not implemented, is this a feature people would be interested in ?
It's not implemented, but it should be there, no doubt. I need it all the time.
It would probably be easiest to implement it as a macro in the UART library. Go into an infinite loop that reads and writes bytes.
The UART library should also be upgraded with an auto baud rate detect macro. There was a great post about that linked on hack a day (it might be in the issue tracker too).
Are there any possibilites compiling the firmware for the bus pirate in linux ? I mostly use atmels, and just got my pirate, but I could take a look at implementing the macro if there are any compilers for linux.
I'm not sure, I thought there was a linux version of MPLAB and C30 compiler, but I'm not sure. Maybe they run in Wine? The manual has a link to a post with the stuff you need to compile (in Windows).
I uploaded a new nightly 2.2 with a uart bridge as undocumented macro (1). You can download the compiled .HEX from SVN.
Do you have a project to test this on?
yes, will download and test now.
Here's my notes from the source:
// could use a lot of improvement
//buffers for baud rate differences
//it's best to adjust the terminal to the same speed you want to use to avoid buffer overuns
//it will fail silently (buffer overruns will be unreported)
Also: uploading source and new .hex with menu and prompts now.
are there any known problem with using 2 stopbits in the current firmware ? data consistently flow (with live display) when I burst some data, but it is garbled in a non consistent way. bridge mode seems to work; although with garbled data it isn't of much use at the moment :) I'll look more into it tomorrow, it's probably something i have overlooked in the manual.
I'm not sure, but the UART library hasn't been tested since I used the very first Bus Pirate to read a GPS. There could certainly be a few bugs in the origional code, or maybe a few crept in. I'll take a look today, it should be using the exact same code that drives the user terminal, so any problems should be evident on the user side as well (?)...
checked it some more yesterday, with 1 stopbit, and still no go; it almost seems as if the baudrate is of, but using the 232 chip on the board and the same baudrate yields a correct dataflow. I'll do some more experimenting tonight and get back with the results.
I connected two Bus Pirate 2gos with firmware 2.2-nightly. Unfortunately, they're different PIC revisions, so that might leave room for problems.
I sent some characters each way at 300/8/n/1. Data from one to the other was fine. But data the other way was always corrupt (same value).
I attached a logic analyzer and looked at the output from the BP that was arriving corrupted, it's just fine. So it appears to be an RX problem (on my B4 chip only, not sure if that makes a difference). I'd like to look at the data between them to verify there's no noise, but I don't have enough USB cables.
I'm looking at the errata (http://http://ww1.microchip.com/downloads/en/DeviceDoc/80470b.pdf) for the PIC and found a bug for your two stop bit scenario, not sure if it applies:
39. Module: UART
When the UART is operating using two Stop bits
(STSEL = 1), it may sample the first Stop bit
instead of the second one. If the device being
communicated with is one using one Stop bit in its
communications, this may lead to framing errors.
Work around
None.
I'll keep looking. I don't see anything immediately in the code. Sometimes changing from bit operations to proper &= |= prevents stupid compiler tricks, I might try that next.
There's also issue 11, but it applies only to A4, and I'm seeing this on B4 only (?).
11. Module: UART
When the UART is in High-Speed mode, BRGH
(UxMODE<3>) is set; some optimal UxBRG
values can cause reception to fail.
Work around
Test UxBRG values in the application to find a
UxBRG value that works consistently for more
high-speed applications. The user should verify
that the UxBRG baud rate error does not exceed
the application limits. If possible, it is
recommended to use a comparable baud rate in
Low-Speed mode.
What PIC revision do you have (press i in the terminal).
I don't have access to my pirate atm, but it is from the second hackaday preorder. I don't think it is an issue with the stopbits; I also tried with 1 stopbit, and it yielded the same results as with 2.
Bus Pirate v2go
http://dangerousprototypes.com (http://dangerousprototypes.com)
Firmware v2.2-nightly
DEVID:0x0447 REVID:0x3043 (B5)
Hi alohre - I fixed this issue:
http://whereisian.com/forum/index.php?t ... 607#msg607 (http://whereisian.com/forum/index.php?topic=119.msg607#msg607)
Sorry it took so long.
great!
no worry about the time, as long as it works :)