Current beta Wire library implementation with support for hardware I2C

LeafLabs Garden » Support » Maple Hardware Support

Current beta Wire library implementation with support for hardware I2C

(52 posts) (11 voices)

Started 1 year ago by crenn
Latest reply from gbulmer

12…4 Next »

crenn
Moderator

http://www.crennsmind.com/Code/Maple/Wire-Snapshot-110913.zip

Currently I'm not happy with the current implementation because to use multiple Hardware I2C ports, you'd need to create new instances of the class. I'm looking at doing something similar as with the Serial ports. So an instance of the class TwoWire called Wire will be a software implementation (using the Wire implementation currently included with Maple IDE v0.0.11) on pins 19 and 20 (for Arduino shield compatibility reasons), another instance of TwoWire called Wire1 will use Hardware I2C port 1, and another called Wire2 will use Hardware I2C port 2. Any thoughts on this?

Anyway, the main difference between the Arduino implementation and the current implementation is calls to begin(). This is subject to change:

Wire.begin();
Defaults to using Hardware I2C Port 1 at 100kHz.

Wire.begin(<I2C Maple Address>);
Same behaviour as above, currently own addresses are not yet supported in the i2c.h and i2c.c files. However, implementation in Wire library is possible.

Wire.begin(<I2C Maple Address>, <I2C Type>);
You can pick which Hardware I2C port you wish to use at 100kHz, or use the software I2C (master mode only) with the default pins (20 and 21). Selections are for the I2C Type:

-PORTI2C1
-PORTI2C2
-I2CSOFT

Wire.begin(<I2C Maple Address>, <I2C Type>, <I2C Flags>);
This follows the above call but allows for flags to be passed to allow for I2C_FAST_MODE (400kHz instead of 100kHz), I2C_DUTY_16_9(Alternative duty cycle of the clock), and I2C_REMAP(Only available for hardware I2C port 1, remaps to 9 (SDA) and 8(SCL)) . These flags will have no effect for Software I2C which will automatically ignore the flags and set itself using the default software I2C pins.

Wire.begin(<I2C Maple Address>, <I2C Type>, <SDA Pin or I2C Flags>, <SCL Pin>);
This allows for different pins to be used for the software I2C implementation, but this isn't available for the hardware I2C ports to change pins (apart from port 1 being remapped). You can pass flags for the Hardware I2C port as above though.

I believe that should be enough information to get people going, there is still work to be done before this will be finalised and finished.

-Crenn

Posted 1 year ago #
mbolivar
LeafLabs

I'm too tired to respond cogently to your code ATM, but:

Currently I'm not happy with the current implementation because to use multiple Hardware I2C ports, you'd need to create new instances of the class. I'm looking at doing something similar as with the Serial ports.

New instances aren't so bad. They avoid wasted space, etc. We only did that Serial behavior because Arduino did. See e.g. HardwareSPI.

Same behaviour as above, currently own addresses are not yet supported in the i2c.h and i2c.c files. However, implementation in Wire library is possible.

Implementation by patching i2c.h is very desirable :). If you'd like advice on that, you know where to find us.

Posted 1 year ago #
crenn
Moderator

New instances aren't so bad. They avoid wasted space, etc. We only did that Serial behavior because Arduino did. See e.g. HardwareSPI.

I guess it would be possible to do it like HardwareSPI, so that you do HardwareI2C Wire1(1); when you need it, although I'm going to keep an instance of TwoWire called Wire for Arduino shield compatibility though.

Implementation by patching i2c.h is very desirable :). If you'd like advice on that, you know where to find us.

True, I'll talk to perry about it next week. I might have some time to do some more maple developments during my week break next week. You might have noticed I haven't been active on the forums during the last few weeks (although I've been a bit more active) recently due to the workload at my university.

Posted 1 year ago #
mbolivar
LeafLabs

I'm going to keep an instance of TwoWire called Wire for Arduino shield compatibility though.

Sounds good.

You might have noticed I haven't been active on the forums during the last few weeks (although I've been a bit more active) recently due to the workload at my university.

I did notice; it's good to see you back. Good luck with your studies, and we can talk more when you have time.

Posted 1 year ago #
crenn
Moderator

Well, I'll be getting back into development of the improved I2C shortly and will be doing things slightly differently to how I thought before. I haven't been active at all lately due to trying to organise moving out of home as well as sorting out some other events.

Since the aim is to make I2C easier to use but keep the option of having software I2C still available, I thought it would be best to have a sort of 'I2C' Print abstract class so that the interface for both Hardware and I2C is the same (Although with minor differences for implemented classes for Hardware and Software). This should enable slightly faster development once the base class is completed. I'll be starting this work most likely tomorrow evening (as I have appointments tomorrow morning) and will update this thread as parts are completed and commented.

Posted 1 year ago #
gbulmer
Moderator

crenn - I assume you posted to get some feedback. Based on that (possibly incorrect) assumption, here's my $0.02

It seems pretty clear that there might be significant API commonality between an I2C device interface implemented on top of I2C hardware vs simple GPIO and software.
Some facilities may differ between a software vs hardware slave I2C.

I'd be more interested in a hardware I2C working reliably, with low-overhead, and being easy to use and install than being able to replace a hardware implementation with a software one.

A 'Print' abstraction sound like a poor fit for I2C.

Every I2C device has an address,
I2C devices return values
I2C devices could be on any of several different I2C (hardware) interfaces
Multiple instances of the same I2C device could be on different I2C interfaces.
I2C is a binary transport
The real complexity might be in talking to the specific I2C device (i.e. handling the devices higher-level protocol) rather than I2C itself

So what is the benefit of a 'print' abstraction to these sorts of semantics and use cases?

Posted 1 year ago #
crenn
Moderator

gbulmer, I believe you miss understand what I'm trying to achieve with this abstraction. This library is about a Wire implementation with interface to the i2c hardware or toggling the gpio to create the I2C signal.

Low overhead isn't the aim for this library, ease of use is for users who are used to the Arduino Wire library. If you want low overhead, the I2C C implementation is quite good, however is not as efficient as the leaflabs team would like (note the comments in the file), although more commits could have occurred since I last looked.

I brought up 'Print' due to it being used for LCD displays and the Serial interface, it's similar to how I'm looking at implementing the code, but not exactly the same. What I want to do is to create that Wire abstraction class so that if you have an I2C peripheral or a software I2C implementation, the interactions you have are the same except for maybe the initialiser.

Benefits to this type of system is that the Wire functions (wire.available, wire.send, wire.endTransmission, etc) do not need to be defined if you wanted to make your own software I2C driven implementation. You'd just need to define a single function called process/write.

Posted 1 year ago #
feurig
Member

Crenn the hardware i2c here actually works pretty well afik when is it going to get rolled into maple?

Posted 1 year ago #
crenn
Moderator

The problem isn't that it doesn't works, it's that it's messy and harder to use than what I'd like. It's why I've been rewriting the library to separate Hardware I2C (the C driver is already provided by the Maple IDE) and software I2C. It's not going to be rolled into the libraries for Maple.

Posted 1 year ago #
feurig
Member

Crenn. Thanks a lot for what you have given us in the mean time. Keep us posted on the rewrite. We will gladly test for you.

Posted 1 year ago #
crenn
Moderator

feurig, I'll post the new update as soon as I run some tests to ensure it compiles. I apologise to everyone waiting for this about the slow updates, currently doing a bit including writing a 'project' proposal document (been at that one for about 2 weeks).

Posted 1 year ago #
trunet
Member

Your Wire library is working fine for me.

some questions:
- Why leaflabs don't merge your code to the master?
- Do you have a github repository or some repository we can take look?

Posted 1 year ago #
crenn
Moderator

The code is currently not commented completely, and it's not in a way that I'd be happy for it to be included with libmaple. The new version should be being tested some time this week (I'm a student at Swinburne University and my holidays start after tomorrow for a week) and if testing goes well, a release should be made here very shortly afterwards for user testing.

I have a github account, but currently not developing using it (which I should be doing) nor do I have a public repository.

Posted 1 year ago #
crenn
Moderator

I'm posting this up now for people to start testing with the Hardware Side of the new library, the software side is yet to go through testing/verification but I should be doing that sometime tomorrow.

Here's the new library, HardWire: http://www.crennsmind.com/Code/Maple/Libraries/HardWire/HardWire-alpha-120407.zip
And here is some example code for the ADXL345:
http://www.crennsmind.com/Code/Maple/Libraries/HardWire/Wire_Test.pde

The main difference is the ability to use it as you would normally use wire instead of having to change the begin command previously. The library is styled after HardwareSPI. To select an I2C port, you need to select the port number and any flags to send to it:

HardWire <VarName>(<I2C Port Number>,<I2C Flags>);

VarName is your Variable Name
I2C Port Number is the I2C Port you wish to use
I2C Flags is the flags you want to give the I2C peripheral such as:

-I2C_FAST_MODE
-I2C_DUTY_16_9
-I2C_REMAP

The follow example of using this is in the code above:

HardWire TestPort(1,I2C_FAST_MODE);

TestPort is using I2C1 and has set it to 400kHz.

If you have any questions, please reply here, I'll get back to you as soon as possible. If all goes well, a release of the whole library should be in a few days. This will hopefully also include comments.

Posted 1 year ago #
cajt
Member

Just gave it a quick test with a LSM303 and I got it running right out of the box. Nice work ;)

Posted 1 year ago #

RSS feed for this topic

12…4 Next »

Reply »

You must log in to post.