A new thread to discuss adding hardware I2C support for REV4 and later PICs.
First order is to detect the PIC revision and write it in the terminal info (i) report.
Next, update old hardware I2C library:
http://code.google.com/p/the-bus-pirate ... rce/I2Cb.c (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/I2Cb.c)
Add slave mode macro to hardware I2C library.
I've started working on this, but I can't seem to build a working firmware image. Is there anything else that needs to be done to generate the hex files you provide from the source in the repository? I'm using the Windows version of MPLAB in Wine with the evaluation version of C18 right now if that makes a difference.
Thanks!
You'll need the C24 or C30 (they changed the name...) compiler.
http://www.microchip.com/stellent/idcpl ... e=en535364 (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364)
Cool, I've got it working. I meant C30, I've only worked with 18F PICs in the past, so sorry for the confusion. My issue was not exporting the HEX file after compiling.
Now that it's all sorted, I've got a patch to re-enable the HW I2C component: http://dev.gentoo.org/~josejx/bus_pirate/i2c.patch (http://dev.gentoo.org/~josejx/bus_pirate/i2c.patch) I haven't yet tested it since I'm still at work, but I'll get to it tonight and follow up.
Also, I see you've added code to print the revision. Instead of using the inline assembly, why not use the builtins:
__builtin_tblrdl() and
__builtin_tblrdh()? I think they're easier to read. Perhaps it would also be a good idea to store these values somewhere so we can check them without having to read from the flash multiple times?
The Bus Pirate code (with a few exceptions) is a public domain/creative commons '0' licensed project, could you please release your patch under the same. I'm going to ask patch contributors to acknowledge this once, or include the license in their patch, so there's no confusion later on.
Built in functions sound great, I hadn't hunted them down yet. I've just been working with the example code from the datasheet to see how table read works.
Sure, I didn't specify any license because I usually just assume that the license is the same as whatever I'm patching! Sorry about that! Feel free to take any of my patches for this project under the correct license for the component I've written the patch for.
I actually got the built in functions from the bootloader code. :)
Okay, so the HW I2C seems to work okay with another PIC18F running as a slave at 100KHz. This is good, although I haven't checked to make sure the rate is actually 100KHz.
However, I haven't gotten it to work with a Wii Nunchuck which runs at 400KHz, perhaps it's a pullup issue, more testing and poking at it is required.
A few questions:
Should the hardware I2C module allow pullups on other hardware than the v0a? I suspect so.
Was there a reason for the characters at the start of many of the messages in the HWI2C module?
I've updated the hwi2c patch to reflect the above changes. Once I'm sure that the master module is working properly, I'll write the HW I2C slave module.
Thanks, I'll apply the patch.
v0a and v2 (both) should have pull-ups.
The three digit numbers, and sometimes just XXX, that precede output in older demos and code was supposed to be an RFC977-style (USENET) coding system so GUIs could interact with the Bus Pirate. I dropped it when I implemented the centralized terminal translation system that recycles the same text messages for each library.
What revision PIC do you have?
I've got:
DEVID:0x04 0x47
REVID:0x30 0x42
just checked mine as well
looks like i missed out.
HiZ>i
Hack a Day Bus Pirate v2go
http://www.buspirate.com
Firmware v2.1-nightly
DEVID:0x04 0x47
REVID:0x30 0x03
CFG1:0xF9 0xDF
CFG2:0x3F 0x7F
HiZ>
A3/A4=0x3003, B4=0x3042, B5=0x3043
Okay, I've moved some code around a bit and added the revision variables to the bpConfig register. If this is okay, we can then use these variables to determine if the hardware is new enough to use HWI2C. The patch is located at http://dev.gentoo.org/~josejx/bus_pirate/procver.patch (http://dev.gentoo.org/~josejx/bus_pirate/procver.patch)
Nicely done.
I moved the memory defines to the individual hardware profiles to make it easy to change for other chips.
Compiled to v2go nightly, untested.
adding... lets let rev3 chips use the hardware option, but print a big warning (perhaps every time).
A patch enabling the hardware I2C module is up at http://dev.gentoo.org/~josejx/bus_pirat ... wI2C.patch (http://dev.gentoo.org/~josejx/bus_pirate/enable_hwI2C.patch)
I made it print the warning once per session, more seemed like overkill (I tried it a bit and it was annoying). Instead, I've made the user press 1 to continue despite the warning or 2 to cancel and go back to Hi-Z mode, hope that's okay.
Note, you'll have to add I2Cb.c to your project before committing, it's not currently in the project and doing so really changes the project file, so I figured I'd let you do it.
Patched, with some changes.
Simplified the warning system to just a notice when entering the HWI2C library. This saves a variable and some code space. I'm a bit concerned by the dwindling space, I've removed the XSFV programmer from nightly builds because there was a space problem last week.
Put the warning inside the HWI2C.c file because it seemed specific to that library. This required giving HWI2C access to the bpConfig struct.
Adjusted the hardware I2C code to use centralized terminal messaging system. Added I2C stop and start messages to messaging system, these are shared by HW and SW I2C. Optimized the order of the switch to put the most commonly used operations first.
I eventually need to move all other single use text to the translation file as well, but not make it part of the messaging system. The way you added the REV3 I2C warning is great, it saves code footprint for text that's used only once, but still consolidates everything to a single translation file. That'll be a fun and easy code cleanup.
I tested it on both sides (REV A3/B4) and it functions as expected. Did not actually do anything with the I2C, just tested warning and new text messages. New nightly compile uploaded.
I integrated the I2C ACK/NACK updates from the software library (http://http://whereisian.com/forum/index.php?topic=23.msg269#msg269) and hardware master mode appears to work great now.
A updated firmware, v2.1-RC2, is available for v2go in the nightly compiles folder (http://http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/). If anyone is using a different hardware version, just let me know and I'll start doing nightly compiles for it as well.
MODE SET
Set speed:
1. 100KHz
2. 400KHz
3. 1MHz
SPEED>(1) >
HWI2C READY
HWI2C>W
POWER SUPPLIES ON
HWI2C>p
1. Pullup off
2. Pullup on
(1) >2
PULLUP RESISTORS ON
HWI2C>(1)
Searching 7bit I2C address space.
Found devices at:
0xD0(0x68W) 0xD1(0x68R)
HWI2C>(1)
Searching 7bit I2C address space.
Found devices at:
0xD0(0x68W) 0xD1(0x68R)
HWI2C>(1)
Searching 7bit I2C address space.
Found devices at:
0xD0(0x68W) 0xD1(0x68R)
HWI2C>
And reading and writing to the RAM in a DS1307, twice:
HWI2C>[0xd0 8 7 7 7 7 7]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
WRITE: 0x07 GOT ACK: YES
WRITE: 0x07 GOT ACK: YES
WRITE: 0x07 GOT ACK: YES
WRITE: 0x07 GOT ACK: YES
WRITE: 0x07 GOT ACK: YES
I2C STOP CONDITION
HWI2C>[0xd0 8 [0xd1 r:5]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x05 BYTES:
0x07 ACK 0x07 ACK 0x07 ACK 0x07 ACK 0x07 NACK
I2C STOP CONDITION
HWI2C>[0xd0 8 5 5 5 5 5]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
WRITE: 0x05 GOT ACK: YES
WRITE: 0x05 GOT ACK: YES
WRITE: 0x05 GOT ACK: YES
WRITE: 0x05 GOT ACK: YES
WRITE: 0x05 GOT ACK: YES
I2C STOP CONDITION
HWI2C>[0xd0 8 [0xd1 r:5]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x05 BYTES:
0x05 ACK 0x05 ACK 0x05 ACK 0x05 ACK 0x05 NACK
I2C STOP CONDITION
HWI2C>
Sorry I've been so busy with work for the past few weeks, I haven't had a chance to work on this at all. I am happy to report that the new firmware does work with my PIC18F slave device, so, nice work!
The PIC18F slave device code I've written would work for a slave implementation on the bus pirate, I'll get to work on porting it over as soon as I have more free time. Sorry again!
No problems. Thanks for all your help so far. I'll include the code when you have time.