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.
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.
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.
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.
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 ?
