Oh, well, it turns out that it was in fact my fault, I have a character intepreter for the Hitachi so that I can send both text and control in a string i.e. hitachi:"$sHello there how are you" - and I’d clearly had some finger issues with my serial terminal as the “s” was missing. All of the devices I have - a NANO, a BCM280, a BCE280, the supposedly slow PCF8574T, a SEED studio display and a 4-channel A/D convertor are all running (maybe 250mm leads) perfectly at high speed. Thank heavens for that. Yes, I’ve made some changes to the original and added the clock stretching in but I would like to clarify as I was a bit hap-hazard with the clock stretching - can someone confirm it should be sent AFTER a master send and just before it checks incoming ACK from the slave? Is that right?? Is there anywhere else it should check?
well, I doubt it would be wise to add 20 devices on a blocking serial bus. Anyway I consider it worth trying on 3 or 4, and reliability is the less I expect from a $3 SoC. Even so, I’d bet on that 20 device statement, but I don’t have enough I2C stuff.
I am HOPING that the STM board I have coming from China will be usable as that can replace all of these various boards… and at £1.30 or so from China.
For now my next project is to change my NANO peripheral to bring the full 10 bits A/D back from the Nano. I’m only pulling back 8 bits 
Oh and for my purposes - yes, the ESP8266 master board has it’s own IO and the idea of the I2c is just to add 2 or 3 extra devices max
Ignacio, there is from hardware viewpoint no reason why a GPIO like on the ESP8266 can’t make a perfectly good SDA or SCL line. The only requirement is that the GPIO can pull the lines “hard enough” to overcome the capacitance of the lines and devices (including the pull up resistors etc.). The ESP8266 can sink up to, I believe, 16 mA on it’s GPIO’s, that’s well enough. For the rest it’s down to software. A slave implementation needs to be able dectect start and stop conditions, which may be a bit of a challenge in software, but a master implementation can be, imho, 100% compliant. Also note that various issues are known with I2C master implementations, for instance on ATmel, they’re not perfect as well.
As far as the 20 devices, I didn’t mean connecting them all at the same time. My point is that I2C implementations in hardware are often very minimal (sometimes even non-compliant), so it may be perfectly possible that with a non-perfect master, some devices will work, some not, some every now and then, and some will hog the complete bus. So that’s why it is very important to be 100% compliant as a master.
Having said that, there is nothing keeping you from connecting 20 devices to one bus, other than maximum capacitance requirements. It will just work. If you need constant really high througput, I2C isn’t the best choice anyway.
Peter, if you’re just going to connect PCF8574 slaves, I guess you need not worry that much. The pain comes when you’re going to add various different types of slaves.
I’d say you can buffer the lines externally but we’ve gone far away from peter’s question here hehe (: let’s just help each other when problems show up rather than discussing theoretical stuff that goes nowhere and discourages people from trying
@Erik_Slagter Hi Erik, no the more I think about this - the PCF (which is working at 1mbps I2c speed in front of me 100% reliably) costs as much as an Arduino NANO board from China - which has more IO pins and can do analog and PWM… I now have it returning 10 bit analog) - so I’m really wondering why anyone would use that at all given the availability of a nano-based i2c peripheral - which will soon be in my Bitbucket repository for others to use just as soon as I squeeze as many facilities out of it as I possibly can - I’ll call it the I2c kitchen sink peripheral.
1 Mhz clock speed to a PCF8574? I am not completely convinced 
I don’t like Arduino, it’s keeping me from the real interesting stuff.
If you buy PCF8574’s (and alike) in larger quantities, I bet you can get them for $0.10 a piece or even less, given it’s kind of outdated. But for you that’s academic
how fast can you write the gpios of the pcf?
They act immediately. So they can be driven at about, start condition + header + ack + 1 byte + ack + stop divided by 100 kHz. I’d say ~ 4 kHz, all eight ports at the same time (one byte).
That way one could make a 17 Hz / 8 bit PWM LOL!
In amateur (and I mean that in a nice way) quantities - from China - that PCF is available on a board for only slightly cheaper than an Arduino Nano from the same place. Arduinos used properly operate perfectly - as do ESPs. I have no interest at all in Arduino however, as a peripheral it looks useful especially as the I2c is hardware. The point being it is the same price as some of these peripheral boards. And, whereas the PCF can as you say make a staggering 17hz PWM with a LOT of overhead, the Nano can make several PWM outputs at reasonable speed with no overhead. I think I’m talking myself into this. Actually we’ve been sitting here talking about sticking a 328 on our ESP board… just up in the air thinking at the minute but considering it would share the same regulator and the same reset circuit, all it would need is a crystal and a 0.1" cap to get all that extra IO… what would take a lot MORE thought is which 2 pins to sacrifice on the ESP. Oh, Erik - clock speed… I can’t include an image here (that’s painful) so I’ve done a page for you… you’re right - looking at it I’m no-where near 1 meg - but a hell of a lot faster than 100Khz - see the END of this article. http://tech.scargill.net/i2c-expansion-for-raspberry-pi/
I’m curious because that’s way over the spec. I wonder how the waveform looks flipping those gpios at 1 Mhz i2c clk
If you want PWM, why use an I/O extender The GPIO’s of the ESP8266 can toggle at 5 MHz, which will give you 76 Hz at 16 bits or 152 Hz at 15 bits, not quite bad. The ATMega that’s in the Arduino doesn’t do any better than that, it also has a 16 bit counter that can be used for PWM, although it’s implemented in hardware, which is nice, it can only control two channels, while the ESP8266 can control all usable GPIO’s at the same time without restrictions. ATmega’s usually run at 1 Mhz (default, /8 fuse active) which would give a very low refresh. At 8 Mhz it would get interesting, but the max of 20 Mhz would be the bomb, 300 Hz refresh at 16 bits, that’s something the ESP can’t compete with.
Don’t look at me - I’m already using PWM on the ESP8266 - I use high resolution PWM for lighting on pins 4,5 and 15. You don’t have to worry about any of that as PWM is built into the Espressif SDK - just set up and go and it runs in the background - I think it is 14 bits. My only objection to it is that even if you set the duty cycle to zero, it does not stop the interrupt-driven routine - I’ve asked Espressif without success about this several times as it can interfere with serial LED driving. I’ve never used a 328 at any other than 16mhz - same with the Atmega 1284p which is an under-rated chip as it has more RAM than the bigger cousins - mind you the 2560 boards are so cheap from China it likely isn’t worth using the 1284 now unless you happen to have your own board layout (I do). The ESP PWM in practice is way better than the Arduino as a background task but hey - why not have both. I’m actually more excited about the SAM32 boards if I can get the I2c running I have the code - but the boards are still in Hong Kong customs).
The PWM code of the Espressif SDK is indeed ehrm… worth a few words. If your needs are simple, it will suffice. The actual resolution and refresh are both determined by the PWM period you setup. As the max. timer resolution is 5 Mhz (you can set it to divide by 1 instead of 16, which is mostly use, but the code won’t ever be able to keep up), you can choose 16 bit/76 Hz or 15 bit/152 Hz etc.
The code works but has some disadvantages, like you say and more. The lowest code values aren’t actually used, so a period of 1 is equal to 2 equal to up 8. Which is a real shame. Also you can’t reach a duty cycle of 100%, 95% is max. And the interrupt is never turned off, indeed, and is NMI, so may interfere with other stuff.
I had quite a few unexplained crashes when I used this code, as well.
That’s why I made my own version, have had no crashes ever since. And all code values are used and interrupts are turned off when all channels are at 0% or 100% (and they’re really 0% or 100% then).
I think the guys at Espressif are quite good in designing hardware (even though the core is just bought from Cadence), but software isn’t their strongest feature. It shows in the code and it shows in undefined behaviour and crashes. That’s why I try to use their software as little as possible.
The Atmega328 can, like most Atmega’s, run up to 20 Mhz, but it needs 5V then. At 3.3V it can only go to 12 Mhz. This is where the ESP8266 is really supreme, with its 80 or 160 Mhz at 3.3V, at 32 bits vs. 8 bits. IMHO 8 bit microcontrollers now really start to get outdated. I’ve used the Atmega328p for some years and I was quite content with it, but it’s no match for the ESP8266.
Oh the PWM isn’t perfect, the waveform is far from it and it won’t quite go to 100% - but at 14 bits - it is PERFECTLY adequate for LED lighting - indeed I use it a lot - with a timer I have large strings of light slowly fading in and out or from one colour to another - all done in the background and very smoothly… I’m not having ANY crashes today and the code has been running here for several months - I long since ironed all of that out. HOWEVER - you have my interest… if you have a better background PWM controller than Espressifs I am interested (unless it’s written in C++ for Arduino)… I’m all ears And I agree, software isn’t their best area… but with recent SDKs (1.5 on) I can very confidently say that crashes now are due to people’s software, not the SDK or or the hardware. Well, that is - not doing what I have them do and that is sit there listening for constant MQTT messages and control stuff accordingly (pwm lighting, serial LED lighting, timers, relays…)