It’s really not necessary imho to use assembly for driving an I2C bus, see my code. Maybe if you want to run it at speeds well over 400 KHz, but even then I think the gain will be minimal. It’s not that difficult for a C compiler to generate smart code for writing bit masks to a memory address (gpio output port bitmask).
I couldn’t find sensible information about the 8514, appears I was wrong, it’s the 8574. Are you using that? It’s a device that has been around some time now (I remember using it in 1990…) so it definitely isn’t a “fast mode” device. The datasheet confirms it. If you need speed I’d recommend the MCP23008, or the MCP23016, which has 16 I/O’s, which work in “fast mode”. They have a few other advantages, like real input or output modes (as opposed to the “quasi bidirectional mode” from the 8574) and real programmable pull-ups and an pin change flag for every (input) pin.
says here PCF85741
I don’t get a match on that type. Can’t it be PCF8574-1, like a sub type?
Sorry it is really small - it’s a - PCF8574T on the board and the chip has the same name.
And yes, I found it - 100Khz only. I guess that might be why it isn’t working.
the pcf is 100khz max
Hmm, well if I put checks for slow devices, I slow my code down (around 1 meg) in which absolutely everything else works. decisions, decisions…
you could slow the bus temporally to address the pcf then go back up high speed, a global variable should suffice
Yes I can see I’m going to need a speed parameter - maybe use it to choose one of two write commands rather than slow down my fast write command… I’m WAY beyond what that PCF is supposed to handle.
The letter after a series of number in an IC designation is always a sub-designation. Packaging, version, etc. So it really it a PCF8574. And yes there is always the exception to the rule, the PCF8574A(T) is a version with a different set of bus addresses.
I am not sure the PCF8574, but I have a similar IC, about equal in age, a LED segment driver, that absolutely refuses to work at any single Hz above 100 kHz. So I could imagine that also counts for the PCF.
Well, I’m waiting for a PCM32 board turning up from China - it costs £1.32 and has everything but the kitchen sink. If I can get the I2c slave code running I reckon it kind of defeats the object of buying A/D convertors and port expanders, A/D etc as it can be made to do the lot. Will make a great general purpose peripheral - also has 2 I2c buses!
does it have native i2c?
About speed on the bus. I can imagine it is very tempting to address differently rated devices (on the same bus) using different speeds, but it won’t work. It just might… work if you address all fast mode devices using the special fast mode prefix, the normal mode devices may then recognise the following “fast mode” sequence as being not for them. The sequence needs to be sent in “normal mode”, so if you’re going that path, the drive code needs to be able switch clock speeds dynamically.
If you’re not going that path, the “normal mode” devices will sooner or later interpret the “gibberish” they’re seeing as a start condition and their own address, they will engage and fiddle with the SDA or even SCL lines and mess up communication with your other devices. Keep in mind that after an start condition, all slaves will start their state machine and shift registers. At some point in their state they will start pulling the SDA because they think it’s time to send data or an ACK. If they miss clock pulses because the clock is too fast, it’s even worse, they may get stuck in a certain state and hog the SDA or even SCL lines. And yes it happens, i’ve had this exact problem only last week.
The only way to reliably combine normal and fast mode devices on a bus, is to use a bus muliplexer. Or use normal mode only.
Erik, despite my need for speed, your comments do of course make absolute sense - I’d not thought about slow devices screwing things up. I will go back to the original ESP code, merely adding in the bus-stretching that they chose for some inexplicable reason - to miss out. Thanks for the insight.
The original code is afaik way slower than the 100 kHz that’s always allowed. But my main problem with it, is that it never checks for unexpected situations, which may screw up things badly and make finding the actual problem very difficult. So I am really not enthousiastic about it.
as long as you do the proper ack - start/stop handling, you should be okay. I’ve been debugging the i2c bus last night using the i2c_master.c from the esp nonos sdk. I can try addressing different devices of different speeds this night, as it sounds like an interesting challenge.
@Erik_Slagter In the main Erik it is just missing clock stretching and could do with better return of error messages - but that’s easy to add - if you guys are telling me that the total time of the square wave clock has to be 100Khz I could easily add those checks in while keeping that speed.
Ignacio: if it “works” it doesn’t mean it’s “good” 
You’ll know when you add the twentieth device and it just won’t work. The code from ESP is just plain bad. It seems to be written q&d in about half an hour in between two other tasks. Also you seem to have missed the point in my story about different speeds on one bus.