Hi jdunfee. Premising that I don't have a Bus Pirate v5 and I don't know it in depth, from what I understand from the link you shared, the "flash" command alone does not exist, it must be accompanied by one or more options, something like:
You also wrote "flash h", which is not the correct syntax, you should try with "flash -h". So the "flash" and "flash h" commands you have written, actually do not exist, are not foreseen for the Bus Pirate v5. The Bus Pirate v5 interprets them as invalid commands, that is why they give you back the "Invalid command: flash. Type ? for help." message. I understand this from the link you wrote. I could very well make mistakes, but I think trying the syntax that I explained you don't cost you anything.
Hi Dmitriy. This you showed is a rather old revision of the firmware, so in my opinion the message "* Syntax error, type? for help" you get is normal. Please take a look at this: https://wherelabs.wordpress.com/2010/01/18/how-to-bus-pirate-bootloader-v4-upgrade/ The message is the expected behavior for the firmware release that is currently running on your Bus Pirate.
A clutch is added between the setup process and the start of using a protocol, Once setup is done all the pins are still at HiZ. only when you type in the 'W' commend does the clutch engage - pins are actualy connected to peripherals...
So after configuring the UART through m, 3, baudrate select , Data bits (1), Stop bits (1), Polarity (1), output type (2) following the instructions above and entering "W" followed by selecting the macro, (2) in case it is need for live monitor so (2), then it worked fine. It is a bit confusing since W turns the PSU on.
Therefore, so that UART works correctly, it is need to activate the power supply with the "W" command, being careful do not to connect the wire that brings +3.3 V / +5 V if this is not required, in this way everything should work without problems.
It depends on the application, it does not seem to me that there is a standard. About I2c the only sort of standard I know is SOFTWARE RESET ([1[1[1[1[1[1[1[1[1)
And can I read the data transmitted through the I2C bus?
You can try with a logic state analyzer or using the Bus Pirate as such (http://dangerousprototypes.com/docs/Logic_analyzer_mode), the client will decode the traffic for you but from there to interpret what is actually happening is not simple, because as I have already written there is no standard, it depends on the application. Possibly a datasheet of the component that manages the I2C bus could help to understand, but still it is not so obvious. The I2C Bus Sniffer macro is implemented in software and is not a substitute for a proper logic analyzer, It has limits (for example 8bit value addresses are more recognizable on a logic analyzer, snooper, debugger, etc).
Hi dirtypcbs. The on-board 3,3 volt and 5 volt BusPirate's power supplies can provide up to 150 mA (https://learn.sparkfun.com/tutorials/bus-pirate-v36a-hookup-guide/all), Si24R1's transmission current is typically about 12 mA (https://rqrorwxhriorop5q.ldycdn.com/DL-Si24R1-A+2.4G+Wireless+Transceiver+Module-aidlpBpoKprRoiSimpqoklpk.pdf?dp=), then choosing 3.3 V the Bus Pirate could directly feed the Si24R1 module (still from the datasheet, 5 V are too many for the SI24R1). In my opinion there are not any inherent problems with the DUT using a separate power source from the Bus Pirate if the levels for power supplies and data bus are respected. I took a look at the SI24R1's datasheet and it seems to me that rather than wiring BP.CE <-> SI24R1.CE, perhaps it would be advisable to use BP.CE <-> CSN (SPI Chip Selection Pin). I am dumb as hell, so I am not sure that can change the matter, but trying does not harm. I believe that observing the data bus with the aid of an oscilloscope could help to understand what is the signal or the signals that interferes with the regular Si24R1's functioning, as one or more levels will be likely outside specifications.
Hi dirtypcbs. Thanks for the clarifications. "3xAA battery pack" is a nominal 4,5 V power supply for the "Adjustable Bed remote control" you wrote, something that can be 5 V or so by using fresh batteries: are You sure that the logic levels in the data bus are 3,3 V and not 5 V? Thanks.
Hi dirtypcbs. About pull-up resistors on Bus Pirate it is useful to know that the Bus Pirate V3.6 has a 2 kohm pull-up resistor on MOSI to properly power 1-Wire devices, while the other pins have 10 kohm pull-up resistors.
That said, sorry, but I did not understand if you are using the pull-up resistors on board of your Bus Pirate or some external ones, anyway by simultaneously using on board and external pull-up resistors, the external ones will end up in parallel to those already present on board of the Bus Pirate, obtaining resistive values lower than the lowest value of the constituent parallel and that could be a problem.
Maybe 2 kohm resistor or worse about 1,666 kohm by simultaneously using on board and external pull-up resistors (2 kohm // 10 kohm = ~1,666 kohm) on MOSI it is a too low value for the data bus. It would be useful to try open-collector by using only external pull-up resistors and not activating the on board ones of the Bus Pirate and perhaps using resistive values greater than 10 kohm that could still be too low in value for the type of data bus, something like 22 kohm, 47 kohm and so.
Hi ermionesrl/Andrea. Sadly I believe that LCD adapter is out of stock and no longer produced. However, LCD adapter consists of a few components that can also be mounted on a breadboard card without using the specific PCB. Here all the information you need:
Hi DH. You are welcome. For what I know, you could use the utility named PicBaud.exe attached: I state that in any case you will not be able to get the exact Baud Rate you wish, but only approach its value as much as possible , cause limitations in the UART implemented in the PIC24 used on the Bus Pirate. You have to run PicBaud.exe setting it for PIC24 and 32MHz clock. Enter the desired baud rate 460800bps and hit calculate, then use the value from the BRGH=1 section. For 460800bps enter 8 at the Bus Pirate BRG prompt. (command "b" in HiZ). Please, take a look at these links:
It appears that you are reading your card in MSB format while it needs to be read in LSB order. In fact 0xC90xC4 0x08 0x89 is the ATR of the card even if actually 0xC9 MSB is equal to 0x93 LSB and not 0x92:
Hi guys. I took the trouble to analyze the behavior of the program with the help of the logic analyzer loaned to me by the usual friend of mine and I found the following. Once started, the program immediately initializes the Bus Pirate preparing it for reading / writing according to what is set in the command line, but it waits 8 minutes and 20 seconds to start reading / writing the chip! So actually the program is not as slow as it seems, it just waits for a long time before starting to do its job. It is not clear to me why such a long delay has been introduced (8 minutes and 20 seconds!), probably a typo or I do not know what else (could it be the compiler I use ? [MinGW & MinGW-W64], I do not think so, but I can not rule it out either and however, the timings are exact to the logic analyzer, so it remains a mystery to me). Decoding the I2C traffic with the logic analyzer it is obvious that, actually as already written by the author James Stephenson in his notes inside the C source, a 2 bytes addressing is used. This fact explains the behavior I detected when reading/writing a 24LC16 EEPROM, as this chip uses 1 byte addressing. I do not have a suitable chip available to verify the code but I must believe that it works correctly with chips that support 2 bytes addressing, as in the dangerousprototypes forum more than one user wrote that they used it without problems, even if there is the issue of 8 minutes and 20 seconds of waiting, which however may have been attributed to low clock rather than to a fixed delay:
So I took a look at the C source of the program, even if I totally have no skills as a programmer, and I noticed that on line 92 the command sleep (500) is entered. 500 seconds = 8 minutes and 20 seconds, bingo! That line is responsible for the 8 minutes and 20 seconds delay I mentioned in the opening, so I first modified it for 5 seconds of waiting and finally considering that time value too much, for a total of 3 seconds, that is:
92 sleep (3)
After that, I took care of line 24. In fact I had written in the first message that it is not clear at me what is meant with the phrase "the address must be 2 bytes", but now that it is I chose to change the related message in the command line. Then, since as I already wrote at the beginning the wording [chip addr 0-8] does not seem to make sense to me because in chips like 24FC64 the available blocks should be 8 numbered from 0 to 7 and not 9 numbered from 0 to 8, I also modified this message in line 24 and the code concerning it in line 28:
Once finished editing the C source, I compiled it to obtain the executables in 32bit and 64bit format that I enclose with the original and modified sources. As far as I can understand, the executables I have compiled work, but since I do not have adequate chips I can not fully test the result, if someone who can do it wants to try them and then report his impressions he is welcome, thanks!
