ESP8266 Community Forum

- Tue Apr 16, 2019 10:29 pm #81843 I'm using a slightly modified driverlib file - but all I use it for is diagnostic logging so it's good enough for now.

I'm in the process of rewriting all the drivers so that they more closely follow the linux kernel driver model, which means I can drop in IIO driver code for sensor chips more easily. It also means I can also use I2C mux chips as if they were just another I2C bus.

I2S has been completely rewritten so that the various values in the control registers are a lot more transparent, and it can run both single value and buffered input and output. The I2C function they use in the existing I2S code is simply to start the 160Mhz PLL clock for the bus.

- Wed Apr 17, 2019 11:16 am #81855

I'm using a slightly modified driverlib file - but all I use it for is diagnostic logging so it's good enough for now.

Ok fair enough. I'm using the UART for "production" (data bridging to network and driving led pixels) so it must work efficiently.

I'm in the process of rewriting all the drivers so that they more closely follow the linux kernel driver model, which means I can drop in IIO driver code for sensor chips more easily. It also means I can also use I2C mux chips as if they were just another I2C bus.

I already have support for I2C mux chips And indeed it's following a framework that allows easy expansion with new devices and even autoprobing (which is often a pita on I2C).

I2S has been completely rewritten so that the various values in the control registers are a lot more transparent, and it can run both single value and buffered input and output.

You mean in your code? If I'm ever going to use I2S, I'll definitely have a look. The demo code from Espressif is hideous.

The I2C function they use in the existing I2S code is simply to start the 160Mhz PLL clock for the bus.

I know... The crux is that it's called "i2c" but it has nothing to do with "i2c", it's "i2s" and therefore it's misnomer. There is no hardware I2C support in the ESP8266...

That often makes me wonder why they ended up with a SoC with such a weird combination of function modules. It almost looks like they did a mis-spelling twice: ordered I2C (which would be logical for a general purpose SoC) but got I2S, and ordered PWM (which also would be useful for a general purpose SoC) but got PDM instead (the "sigma-delta" module, which is actually just PDM). Those two would make a lot more sense to me.

I am truly a bit sad our ESP8266 doesn't have hardware support for both PWM and I2C, but on the other hand, the CPU is quick enough and it allows for far more flexibility. I now have PWM up to 18 bits width (which you'll never see in a hardware implementation) and a very robust I2C implementation (if you're using I2C sensors, you know what I mean...) that runs configurable up to 800 kHz. So I guess I shouldn't complain. It was very interesting and learning to make those implementations.

I guess I don't have to say again that the code for both (I2C and PWM) from Espressif suck big time again, here. It's clear they're hardware developers and they're good at it too. But software is difficult for them.

- Wed Apr 17, 2019 4:48 pm #81860

I'm using a slightly modified driverlib file - but all I use it for is diagnostic logging so it's good enough for now.

Ok fair enough. I'm using the UART for "production" (data bridging to network and driving led pixels) so it must work efficiently.

I'm in the process of rewriting all the drivers so that they more closely follow the linux kernel driver model, which means I can drop in IIO driver code for sensor chips more easily. It also means I can also use I2C mux chips as if they were just another I2C bus.

I already have support for I2C mux chips And indeed it's following a framework that allows easy expansion with new devices and even autoprobing (which is often a pita on I2C).

I2S has been completely rewritten so that the various values in the control registers are a lot more transparent, and it can run both single value and buffered input and output.

You mean in your code? If I'm ever going to use I2S, I'll definitely have a look. The demo code from Espressif is hideous.

I've looked at your project and it's lovely, especially the UART streaming. And I have already looked at 'borrowing' your I2C code when I redo the driver for that.

Key thing for me is that I don't want to reinvent the wheel when new sensor chips come out, and there's already a lot of support for all sorts of sensors in the IIO section of the Linux kernel, so if I can just lift and drop that code as much as possible it means I don't have to write it, or I can contribute to it in their project. What I find strange is that Espressif had the chance to standardise the driver approach when they went to IDF and they have done it half and half - they have completely rewritten the code, but then didn't follow any of the common architectural patterns for device driver frameworks! It wouldn't have taken much.

IIO is quite a reasonable approach, where they extend the existing device driver model with the concept of channels, triggers and buffers. Most existing frameworks define key entities of bus, driver, device and class. The Linux kernel has also fairly recently provided options for probing that work much better for I2C devices where in most cases the device doesn't identify itself properly, and so the driver needs to be able to find the device instead of being passed it. Adding the IIO concept of channels means you can then define an abstract sensor that can get its data from a channel in a standard way - then you can effectively 'hot swap' new and better sensor chips into your units as the market develops.

In this model, the current driverlib is actually the bus code - it's not drivers at all!

- Thu Apr 18, 2019 9:51 am #81872 Doing things only half is kind of a trademark of Espressif...

For me the "reinventing of the wheel" for I2C sensors is not a point at all. I enjoy reading the datasheets and making the support. Most of the time that raises all of sorts of surprises (datasheet not complete or not completely correct, devices that don't comply fully to I2C, etc etc) but I don't mind.

Actually I don't think you can create a framework that can expose all features of all sensors, there are some weird ones around! Also it will be hard to workaround all the quirks. I have some sensors that need > 100 ms to do a (proper) measuring cycle and will either return a stale value (good), a non-sense value (bad) or nothing at all, no I2C ack (ugly) when queried withing such an interval. That doesn't sound so bad, but if you have a combined sensor (like air pressure, temperature and humidity), in this case, you must always query them all at once and cache the values for later retrieval within the measuring interval. I am not sure such a framework can facilitate this. Plus "a few" other quirks. The am2320 (and alikes) need to be woken by addressing it and sending no data. It won't ack, but the next addressing within a few milliseconds, it will respond to. Unless you wait too long and you need to wake it again. What a mess. Etc...