libmaple i2c API « LeafLabs Garden

LeafLabs Garden » Development

libmaple i2c API

(97 posts) (15 voices)

Started 5 years ago by bnewbold
Latest reply from 4rdu1n0

12…7 Next »

bnewbold
Ex-Leaflabs

I've been implementing hardware I2C in the maple library; my code should soon be visible in our github code repository on the development branch ("master" not "stable") at github.com/leaflabs/libmaple/tree/master. Once this is complete I will port the Wire arduino library over so that when using the IDE, programmers can access i2c the way they are used to. But the lower level implementation will also be available and I was wondering if anybody had any comments or requests on our implementation...

I spent a long time trying to come up with a simple but complete implementation that would allow any possible master combined message to be sent. This would require either a big data structure that would hold an arbitrary sequence of read buffers and write data, or a lot of callbacks that would wait for user code to specify what it wanted to read/write after every slave ACK. I decided to scrap this and just allow all read or all write master messages; the user code will send multiple messages to, eg, WRITE a memory location to an EEPROM chip and then READ out data sequentially; this seems to work across multiple messages for most i2c devices? This would cut down the maximum theoretical bandwidth for complicated read/write sequences, but I figure bandwidth will mostly matter for long undivided reads and writes. Any thoughts?

One feature we could add is a "soft" i2c library that would bit bang the protocol on any two open GPIO pins; this would be much slower and consume more system resources but would add a lot of flexibility; I know the soft SPI and USART implementations on the arduino get a lot of use. Is this worth our development time?

Here's what i've got now. Slave functionality is handled by first setting an address (which enables ACK) and configuring RX and TX callbacks. There are also optional BEGIN and END callbacks which get called after the slave address is matched and ACK'ed and the message ends; these could be used to configure/reset buffers or blink a status LED or whatever. The RX and TX callbacks are called byte by byte so user code will need to implement any buffering; if they are slow SCL will get stretched which is fine but kills the bandwidth. The master read/write functions set up buffers and then return; usercode can check the status of the read/write with the is_busy function. In the following i2c_num will be just a uint8 and will select the port (I2C_PORT1 or I2C_PORT2).

// freq sets the master SCL frequency; i've tested up to 800khz successfully
void i2c_init(uint32 i2c_num, uint32 freq);
void i2c_disable(uint32 i2c_num);
uint8 i2c_busy(uint32 i2c_num); // 1=still busy, 0=ready/done

// these block until not busy or timeout
void i2c_master_read(uint32 port, uint32 addr, uint32 *data, uint32 len);
void i2c_master_write(uint32 port, uint32 addr, uint32* data,
uint32 len);

void i2c_slave_set_addr(uint32 port, uint32 addr); // this enables ACK
void i2c_slave_set_begin_callback(uint32 port, void (*function)(void)); // optional
void i2c_slave_set_rx_callback(uint32 port, void (*function)(uint8*));
void i2c_slave_set_tx_callback(uint32 port, uint8 (*function)(void));
void i2c_slave_set_end_callback(uint32 port, void (*function)(void)); // optional

Posted 5 years ago #
DaemonMaker
Member

I grabbed a copy of the libmaple i2c branch but it doesn't have all the functions defined above. Should I be looking elsewhere?

Posted 5 years ago #
gbulmer
Moderator

bnewbold - Sorry I missed this before.

About 18 months ago, I was exchanging email with a guy who'd built some commercially successful hardware containing STM32F.
He had said " STM32 is a very nice little device, beware the built-in I2C controller - it's pretty broken, both in terms of not meeting setup/hold timing specs on its outputs and some logical bugs in the controller."

I noticed a LOT of errata in RM0008 (page 1064) which would have been significantly after he had finished his product, so ST may have fixed the problems.

Have you tested the I2C hardware with a few I2C devices?

Posted 5 years ago #
leaflabsandy
Member

Quotes:
Im working on porting a soft implementation of the "Wire" library right now!
By soft I mean that the i2c is done via bitbanging rather than the hardware i2c driver.
This is suboptimal, but i2c is a fairly slow protocol (400KHz in fast mode) so the only
real hit is that it will be synchronous rather than async. I will post when this is done
so you can use it!

Posted 5 days ago # <------ by poslathian

The I2C hardware is really designed to be used the DMA. At first setting
up the DMA was way below i2c on our priority queue, so we tried to setup a
HardwareI2C interface without DMA. We failed miserably after two fully fledged
attempts. So, were releasing a hold-over soft implementation and moving DMA up
the queue to (next!), then well setup the i2c peripheral using DMA.

tldr: i2c om nom nom

Posted 4 days ago # <------ by poslathian

---------------------------------------------------------------------------------
---------------------------------------------------------------------------------

Benewbold is your I2C hardware version with DMA?

Will the bit banged I2C be released at the same time?

Great ... we have two outstanding Leafblowers working on I2C.

Posted 5 years ago #
bnewbold
Ex-Leaflabs

Here was my STM forum post from 5 months ago when I was working on an interrupt based I2C implementation: https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/I2C%20with%20interupts%20last%20RXNE%20not%20getting%20thrown%20(EV7)&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E&currentviews=157

I made a second attempt at an interrupt-based implementation a few weeks ago but we decided it would be better to pursue a soft (bit banged) or DMA implementation for now. I was certainly able to get an interrupt-based implementation working for most individual use cases (aka, for communications with particular chips, like master mode only or slave mode only), but a very general implementation a la the Wire library was elusive.

Posted 5 years ago #
leaflabsandy
Member

Just curious ... So the interrupt driven I2C is off the table.

Quote: "but we decided it would be better to pursue a soft (bit banged) or DMA implementation for now."

Reply: Which one is it for now? (soft-bit banged or hardware DMA or both)

Posted 5 years ago #
Kenny9999
Member

Look like you guy's have some pressure to deliver an I2C library! :)

Posted 5 years ago #
DaemonMaker
Member

I'm particularly interested in the hardware implementation. If there is anything I can do to help, even if it's just testing or writing docs, please let me know.

Posted 5 years ago #
poslathian
LeafLabs

Hey guys, i2c is coming in 0.0.7, VERY soon. Yes, we definitely feel the pressure! However, this implementation (of the Wire interface) will be SOFT I2C. The Hardware I2C, unfortunately, is going to get pushed to 0.1.0, along with general DMA support. The lesson, after several attempts at DMA free i2c, is that the two features were clearly intended to work together and a DMA based implementation is just the way to go. If anyone wants to hack on DMA+i2C do feel free! There is a substantial opportunity to make a code contribution here. I can say that in all probability we will not be working on DMA+I2C until after maker faire. The SOFT implementation, however, should be out very soon.

Posted 5 years ago #
DaemonMaker
Member

What modes will the I2C implementation support? I.e. Master and slave? Multimaster? All of the above?

Posted 5 years ago #
Kenny9999
Member

Cool, I also have a couple of device that I can test, if you're interested!

Posted 5 years ago #
leaflabsandy
Member

Quote: "Have you tested the I2C hardware with a few I2C devices?"

Reply: I find if writing to a serial I2C EEPROM or a I2C Real Time Clock works without
any modifications then you got a very usable and stable I2C library module.

----------------------------------------------------------------------------------------
Test Code for the DS1307/DS3231 Real Time Clock.
----------------------------------------------------------------------------------------

#include "Wire.h" // For DS3231 I2C RTC

// ---------------------DS3231 I2C RTC Defines-----------------------------------------
#define DS3231_I2C_ADDRESS 0x68 //I2C Addresss of DS3231

//--------------------- Global variables----------------------------------------------

byte second, minute, hour, dayOfWeek, dayOfMonth, month, year; // DS3231 global variables

/* ----------------------- DS3231 I2C Functions -----------------------------*/
//DS3231 I2C

// Convert normal decimal numbers to binary coded decimal
byte decToBcd(byte val)
{
return ( (val/10*16) + (val%10) );
}

// Convert binary coded decimal to normal decimal numbers
byte bcdToDec(byte val)
{
return ( (val/16*10) + (val%16) );
}

// Stops the DS3231, but it has the side effect of setting seconds to 0
// Probably only want to use this for testing
/*void stopDS3231()
{
Wire.beginTransmission(DS3231_I2C_ADDRESS);
Wire.send(0);
Wire.send(0x80);
Wire.endTransmission();
}*/

// 1) Sets the date and time on the DS3231
// 2) Starts the clock
// 3) Sets hour mode to 24 hour clock <-----------------MILITARY TIME !!!!!!!!!!!!-------------
// Assumes you're passing in valid numbers

void setDateDS3231(byte second, // 0-59
byte minute, // 0-59
byte hour, // 1-23
byte dayOfWeek, // 1-7 Sunday = 1
byte dayOfMonth, // 1-28/29/30/31
byte month, // 1-12
byte year) // 0-99
{
Wire.beginTransmission(DS3231_I2C_ADDRESS);
Wire.send(0);
Wire.send(decToBcd(second)); // 0 to bit 7 starts the clock
Wire.send(decToBcd(minute));
Wire.send(decToBcd(hour)); // If you want 12 hour am/pm you need to set
// bit 6 (also need to change readDateDS3231)
Wire.send(decToBcd(dayOfWeek));
Wire.send(decToBcd(dayOfMonth));
Wire.send(decToBcd(month));
Wire.send(decToBcd(year));
Wire.endTransmission();
}

// Gets the date and time from the DS3231
void getDateDS3231(byte *second,
byte *minute,
byte *hour,
byte *dayOfWeek,
byte *dayOfMonth,
byte *month,
byte *year)
{
// Reset the register pointer
Wire.beginTransmission(DS3231_I2C_ADDRESS);
Wire.send(0);
Wire.endTransmission();

Wire.requestFrom(DS3231_I2C_ADDRESS, 7);

// A few of these need masks because certain bits are control bits
*second = bcdToDec(Wire.receive() & 0x7f);
*minute = bcdToDec(Wire.receive());
*hour = bcdToDec(Wire.receive() & 0x3f); // Need to change this if 12 hour am/pm
*dayOfWeek = bcdToDec(Wire.receive());
*dayOfMonth = bcdToDec(Wire.receive());
*month = bcdToDec(Wire.receive());
*year = bcdToDec(Wire.receive());
}

void read_RTC_DS3231() // DS3231 local library function call - FOR TESTING ONLY!
{
// second, // 0-59
// minute, // 0-59
// hour, // 1-23
// dayOfWeek, // 1-7 1=Sunday
// dayOfMonth, // 1-28/29/30/31
// month, // 1-12
// year) // 0-99

getDateDS3231(&second, &minute, &hour, &dayOfWeek, &dayOfMonth, &month, &year); // <----- uses global variables !!!!
Serial.print(hour, DEC);
Serial.print(":");
Serial.print(minute, DEC);
Serial.print(":");
Serial.print(second, DEC);
Serial.print(" ");
Serial.print(month, DEC);
Serial.print("/");
Serial.print(dayOfMonth, DEC);
Serial.print("/");
Serial.print(year, DEC);
Serial.print(" Day_of_week:");
Serial.println(dayOfWeek, DEC);
}

void set_Time_Date()
{
// Change these values to what you want to set your clock to.
// You probably only want to set your clock once and then remove
// the setDateDS3231 call.
second = 00;
minute = 21;
hour = 21; //<---------------Military Time !!!!!
dayOfWeek = 2; // Sunday = 1
dayOfMonth = 24;
month = 8;
year = 9;
setDateDS3231(second, minute, hour, dayOfWeek, dayOfMonth, month, year);
}

void setup()
{

Wire.begin(); // DS3231 I2C pins setup
//set_Time_Date();

} // End of setup code

void loop()
{
// Read DS-1307 RTC
getDateDS3231(&second, &minute, &hour, &dayOfWeek, &dayOfMonth, &month, &year); // <----- uses global variables !!!!

}// end of main loop

Posted 5 years ago #
leaflabsandy
Member

Bnewbold ... I have a spare DS3231 ChronoDot RTC. If you need it for I2C testing, I will
ship it to Leaflabs ASAP? You give the word.

Posted 5 years ago #
poslathian
LeafLabs

I've been testing off of the xl345 i2c/spi ports for now. Let me get you some code later today to run on your RTC clock and let us know how it goes.

Posted 5 years ago #
crenn
Moderator

I might try later today (6:17AM here!) to get a software based I2C working. Although I won't be able to test it until when I get home.

Posted 5 years ago #

RSS feed for this topic

12…7 Next »

Reply »

You must log in to post.