#1

So my end goal is to talk to a STM32F103 from Crow, but I have had no success with I2C on it thus far, so for now I have switched to an Arduino Uno.

I’m trying to replicate the TXi ii protocol, but I get this result in druid:

> print(ii.txi.get(‘param’,1))
nil
^^ii.txi({name=[[param]], device=1, arg=1}, 2.303607)

Does this indicate that the i2c clock speed is wrong or something? I’m not very familiar with i2c yet, so I’m just not really sure what to try here. I’m a professional developer, but ironically the only one at my company at the moment that’s not an embedded engineer.

#2

This looks to me like crow reporting it received a ii message, what values are you expecting your query to send back? Crow’s i2c ii.$device.get calls enqueue an outgoing ii message and then return. Responses are handled asynchronously by the ii.$device.event callback. The default event callback formats the ^^ii.txi message and _c.tells it out the serial port. The idea is that lines starting with ^^ act as “out-of-band” messages for host applications to potentially filter out and handle differently from regular text printed by Lua evaluation on crow.

It might be useful to expose a Lua API on crow for raw i2c interaction with arbitrary addresses and bytes, to facilitate debugging, developing devices with i2c support, and experimentation. Made an issue.

1 Like
#3

Ah okay, I guess I just misunderstood the interface, I was expecting ii.txi.get to return a value. I don’t have any ii modules yet, so this was my first time trying to use it.

So presumably I need to set up a handler with ii.txi.event( e, value ). Thanks for the help.

#4

The reason this is a callback is 1) we don’t know if there’s a device at the target address at all, in which case we just don’t get a response and 2) the i2c spec allows both transmission and response to take an arbitrarily long time, since any follower can “stretch the clock” for as long as it wants, stalling all communication on the bus until the slowest recipient is ready for more data.

2 Likes
#5

Yeah that makes a lot of sense. I didn’t realize i2c can have an arbitrary response time.