1
Messages
This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.
Messages - macboy
2
Bus Pirate Development / Re: I2C Clock Stretching
3
Bus Pirate Development / I2C Clock Stretching
I was thinking of hacking it in there this week (time permitting). The issue has come up several times, and it really can be a significant limiting factor to using Bus Pirate I[sup:]2[/sup:]C for things like sensors or other real-world interfacing devices... basically anything other than an EEPROM, which is the only thing I would always 100% depend on to work at full bus speed.
Since we use a software library (on v3) for I[sup:]2[/sup:]C, it should be very easy to add. I had a look at the code, and I am sure it can be done with less than 10 lines of code added. For hardware I[sup:]2[/sup:]C on v4, well, I'd implement that too if I had a v4. The I[sup:]2[/sup:]C peripheral supports it, but does require extra code.
4
Bus Pirate Support / Script (BASIC) mode enhancements
script mode in my custom firmware now has:
- operators ^ (XOR), ~ (bitwise inversion), and % (modulus).
- support for LSb-first transmission if that is selected in your setup mode.
- support to break out of a loop by pressing Ctl-C.
- support for hex number input (e.g. LET X=0xA0)
- ability to PRINT variables in hex format
- better debug memory dump in the format:
[font=Courier:]0x0000: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 0123456789:;<=>?
0x0010: 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F @ABCDEFGHIJKLMNO[/font:]
(i.e., address, then 16 bytes per line in hex format and ASCII format).
I also added Ctl-C support at the command line (both normal mode and in script mode), which allows you to 'abort' a command by pressing Ctl-C, which works in a similar way to DOS or UNIX shell command lines. Whatever you have typed is not executed and discarded, and you get a new prompt.
Since nobody ever replied to this thread, I assume nobody is interested in these improvements?
I am joking of course. Is there a how-to or for new developers? I'd like to make more contributions.
5
Bus Pirate Support / Re: Everything returned 0xFF, please advice
Quote
I2C>(1)Seems no devices are found. There's your first problem. Did you activate and give power to the pull-up resistors? Use command "i" and post the output here. The data and clock lines should be "High".
Searching I2C address space. Found devices at:
I2C>(1)
Searching I2C address space. Found devices at:
You are getting NACK to almost everything. That is a problem. You should be getting ACK to everything. You get NACK to sending 0xA0 or 0xA1 address, so there is no device at that address. First critical step is determine your device address, and make sure the device sends ACK when it is addressed.
Then you need to understand basics of talking to I2C EEPROMs. They have I2C address always in the format 0b1010XXXY where XXX is a 3-bit address, and Y is "Read" (or "Not Write"). You set this bit of the I2C address to start a Read cycle to the EEPROM, and clear it to do a Write. That means that the read and the write address are not the same. The 3-bit address XXX is usually determined entirely or partly by pull-up/-down resistors on the board and/or internally (multiple "devices" on one chip). Check the datasheet. Based on your sniffer output, you should have a device at 0xA0/0xA1.
Depending on EEPROM size, you either send one or two bytes of address. I haven't looked up your device but I hope you worked that out. Based on your sniffer output, it looks like two bytes.
To address a specific memory address of the EEPROM, you send a START ("[") then the device write address (e.g. 0xA0) then one or two bytes for the memory address. You can then optionally send STOP, then send START and device read address (e.g. 0xA1) and perform the read.
6
Bus Pirate Support / Re: Help with Bus Pirate
If you get the prompt, the command "?" will give you a short list of commands. Documentation is here.
If you don't get the prompt, then something may be wrong with your Bus Pirate.
7
Bus Pirate Support / Script (BASIC) mode enhancements
I was playing with the script mode and found some issues.
The first and most important is that the LSb/MSb setting is not honored when sending data in script mode. I didn't try receiving data but I assume it is the same. Data is always sent MSb - most significant bit first. I have tried both SPI and 3-wire and they share the same issue. As an example, let's say you configured to use SPI and LSb (command L) and send 0xA3 (decimal 163) while not in script mode. The bit pattern sent will be 1100 0101. Great. Now enter script mode (s) and do "10 SEND 163" and RUN. It will send the bit pattern 1010 0011. This is "correct" data, but bit reversed (MSb first). Obviously, the script engine should send the data in the bit order that has been configured. It would also be useful to have a command (say, "FLIPB") which would reverse the order of the bits in a byte. (for that matter, SWAPB would also be nice, to swap the two bytes of the 16-bit variable).
Another issue is the inability to forcefully break a script that has gotten into an infinite loop or which is stuck waiting on some external condition (waiting for specific data input that never comes). Conventionally, sending a Control-C (ascii ETX, End of Text) should terminate the operation. It would be extremely useful to have Bus Pirate respond to Control-C.
I wonder if we could expand beyond 1 kB for script storage?
The last issue is the silent removal of the script engine from v6.1, but I see that is resolved (or will be resolved) in v6.3, whenever that happens.