search

RIOT-OS / RIOT

RIOT - The friendly OS for IoT
https://riot-os.org
GNU Lesser General Public License v2.1
4.94k stars 1.99k forks source link

[RFC] periph/i2c: Is it planned to run RIOT on an I2C slave #10587

Open gschorcht opened 5 years ago

gschorcht commented 5 years ago

Description

At the moment, the I2C peripheral driver interface is defined to work only as a master. To use RIOT on a slave device, the I2C interface would have to be extended. It should allow also

Question.

Is there already a possibility or is there any plan to let RIOT also work on an I2C slave device? Did I miss something?

MrKevinWeiss commented 5 years ago

There is nothing that I know of yet. Currently the API doesn't support that functionality.

This may be a bit more difficult then expected because most, if not all i2c master implementations are blocking (not even using the scheduler but using while(flag) type blocking). I believe for slave functionality an interrupt mode should be supported.

gschorcht commented 5 years ago

I believe for slave functionality an interrupt mode should be supported.

Probabely, some of MCUs are able to operate also in I2C slave mode and to register callbacks that are called when something is received. For the ESP32 I know that it can also be used in slave mode. Slave mode could also be realized in software using GPIO interrupts for SDA and SCL lines to detect the START condition. Once the START condition has been detected a blocking thread could realize the transaction as slave in software.

I was just thinking whether RIOT makes sense to be working on a slave. I would say yes. The use case would be an intellegent sensor.

kaspar030 commented 5 years ago

I was just thinking whether RIOT makes sense to be working on a slave. I would say yes. The use case would be an intellegent sensor.

+1

It might make sense to make the corresponding interface independent of periph/i2c instead of integrating the functionality there.

gschorcht commented 5 years ago

It might make sense to make the corresponding interface independent of periph/i2c instead of integrating the functionality there.

Probably yes because an API for a slave would be completely different. Almost all functions of periph/i2c require an address parameter which is only relevant for I2C masters. I2C slaves need instead an API that is event driven.

maribu commented 5 years ago

I'm also interested in using RIOT as I2C slave, but I did not had time to write any code yet. If someone is starting with this and needs help, feel free to ask me :-)

MrKevinWeiss commented 5 years ago

From experience getting MCUs to act as slave devices can be difficult from the timing perspective. This is more for register operations where one would use a read_reg command to interface with the riot slave. If you are running a fast clock then you need to read the master write data and switch your reg pointer before the the master read data starts.

it is not too bad to preload data though.

I2C could be doable but maybe we wait until the DMA for i2c is solid.

maribu commented 5 years ago

it is not too bad to preload data though.

That was also what I was thinking: The slave API being only able to operate on a buffer, which can transparently be accessed from the master. At creation the user would specify the size of the read-only and the read-write parts of the buffer. And two functions to access and set a byte "atomically" from the view of the I2C master.

(One could do clock stretching if the master is accessing while the buffer is "locked" by the application. But I'm not a fan of clock stretching at all.)

I2C could be doable but maybe we wait until the DMA for i2c is solid.

For those MCUs that have I2C DMA, but I think an 8bit MCU with a very low active power consumption is the "natural target" for an I2C slave. A decent ARM could be the master fetching the data collected by the low-power slave every now and then.

MrKevinWeiss commented 5 years ago

I'm not a fan of clock stretching at all

heh same

Just a some lessons I learned when doing PHiLIP, it is even worse for the spi. I had to bypass all the abstraction from the ST HAL library because it took to long with higher speeds.

roberthartung commented 5 years ago

I have a i2c slave for the atmega platform.

wysman commented 5 years ago

Any started works for I2C slave ? I am using a STM32 paltform.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

Citrullin commented 4 years ago

@wysman I would also be interested in a I2C slave for the STM32 platform. Would like to use a STM32F1 as slave to drive an epaper display and some other peripherals. Started with designing a board for it. Will take a look into it again, once I have one ready to use.

wysman commented 4 years ago

@Citrullin We have a POC of I2C slave with clock stretching on our RIOT fork. https://github.com/Power-Lan/RIOT/tree/i2c.slave

I hope it's can become mainline, using RIOT on small µC is useful in many of our use case.

Citrullin commented 4 years ago

@Citrullin We have a POC of I2C slave with clock stretching on our RIOT fork. https://github.com/Power-Lan/RIOT/tree/i2c.slave

I hope it's can become mainline, using RIOT on small µC is useful in many of our use case.

A PR would be helpful, I guess. At least to get some feedback on the PoC.

LittleNewton commented 2 years ago

So, does RIOT support configure a I2C module in slave mode yes?

maribu commented 2 years ago

No, nobody has implemented that. But as this issue proves, there is some interest in having it.

TimVosch commented 1 week ago

FYI, I have recently implemented the i2c patch from @Citrullin into 2024.07 to be used in a project of mine. It appears to work fine :)

https://github.com/Pollex/MFM4-EZO-EC-2/blob/main/0001-Feat-i2c-experimental-i2c-slave.patch