esp32 i2c is not implemented yet

[mnfisher]

I 'm using a heltec Wi-Fi board with built in oled display (ssd1306) on a15 and a4.

Martin

[p.erasmus]

Hi All.

This topic is pointing out to me that Flowcode is loosing it primary objective and that is that Source code is easily transported between the various Architecture ,now with I2C it is no longer the case what works on a PIC/PIC32 does not work on a STM32 .
Sorry if I miss something here ,

@Leigh
Thanks for you previous answer however to be honest I am lost, If I use the Cal component in an component I make and this cal component is for a PIC or what ever how do I handle this transaction and other macros in my component that it works now on a PIC and STM ? can you people give us a small video or example how to this .

Is't it the job of the i2c_cal component to decide which way to handle the byte and multiple bytes as per argitcture used or called by the user,again my knowledge is limited sorry if I am wrong but necessary to understand how to handle components we make

because all my I2C components will now for this reason only work on Microchip and some AVR's it seems and I have the same problem as Matrix I do not have all chip or tools (STM etc ) to test all of this ,this is an concerning issue

[LeighM]

Thanks, you have some valid points. We try our best to maintain compatibility and a generic approach. But this is not necessarily achievable when the peripheral interfaces are substantially different.
The ideas posted are probably doable, but it would be less predictable as to how that kind of back compatibility compromise coding would affect the user code. We thought it best to move the interface forward and let the user decide how best to take advantage of it.
Target devices and their peripherals are getting more complex and feature rich. We also now have RTOS in the mix, such as Raspberry Pi and ESP which can do much more than a basic microcontroller. However, these are not so ideal for low level time conscious activities. “Horses for courses” as they say.

[p.erasmus]

Hi leigh.

I understand all point and they are sure valid,I am only tying to understand how I should market my componets because now with this topic
it clear that I should state that it only works on PIC /AVR /Arduino and SW mode in ESP32.
I am trying to avoid my customers jumping on me because my component does not work on a STM for example .I am still not sure to handle this
at the moment,

Thanks for the clarification and yes the micor's are getting so complex

[BenR]

Hello,

For v9 I've moved all of the Matrix i2c components over to the transaction system to allow ARM and ESP hardware to work. Even some of the newer 8-bit PIC devices are moving to a transaction only system e.g. the 18FxxK42 devices. We could maybe fudge it in the CAL but this gets rather messy fast and it's maybe best to just move to a new approach. The newer approach should also be a lot faster so things like displays should run more smoothly then they would with a botched halfway house approach.

Here is how I've been doing things.

When initialising the I2C you pass in the 7-bit device address. This is now consistent with the way Arduino does I2C addresses and so porting code into Flowcode is hopefully more seamless.

I2C_Init.jpg (37.38 KiB) Viewed 8349 times

To write data you simply put the data bytes after the device address into an array and call the write function.

I2C_Write.jpg (11.96 KiB) Viewed 8349 times

To read you do a similar thing only this time you pass in a array and then read from the array. Here is an example of a write then read, this device cannot handle a stop between the write and read and so we add the bit 0x8000 to the byte count and this tells the CAL code not to transmit the stop at the end of the write.

I2C_Read.jpg (24.01 KiB) Viewed 8349 times

I hope this helps to show the way we have gone with supporting I2C on these newer devices. I think I converted all the Flowcode components over in a couple of hours and so hopefully it's not a big job for you to do the same to your components.

We have a similar transaction system for SPI but in this case it is much easier and cleaner to allow the byte by byte method to work as well as so we have maintained this functionality to keep compatibility.

[p.erasmus]

Hi Ben,

Thank you for showing the direction,
Is it possible for you to give me a sample FC chart (example) I was born BC (before computers)

I will try it first on the ESP which I have now up and running.

Thanks a again

[BenR]

Hi Peter,

Yes no problem here you go.

MPU-6050.fcfx

(62.53 KiB) Downloaded 784 times

[p.erasmus]

Hi Ben.

Thank you so much I will work on this that would be nice if I can get it going

[p.erasmus]

Hi Ben

Please help me to understand the below Addressing ,I only pass the 7 bit address like my device is 0x48 the write function will automatically shift the address to make the LSB = 0 for a write ,Correct in the example the transaction will write 2 bytes Correct? Te same for a Read I only pass the 7 bit address the read transaction will do the Read bit auto .

P1.jpg (27.2 KiB) Viewed 8326 times

In the Transcation_write below the 0x8001 does this imply the MSB set = 8000 + write 1 byte = 0x8001 Correct? so for example if I need to write 3 bytes the it will be 0x8003 ? correct (No stop write 3 bytes)

P2.jpg (24.17 KiB) Viewed 8326 times

I am lost as to why you are having this switch on 2 addresses(in the initialize macro) I have only 1 that is 0x48 the 0x68 and 0x69 look like a Write and read addresses and that would make my assumption that the macros auto add the R/W bits Sorry for my misunderstanding


Appreciate your help

[LeighM]

Hi Peter,
In that last image, Ben is choosing between two device addresses (for a case where the device has selectable address based on a pin)
You don't need to do that.
Just call Transaction_Initialise(0x48)
The component then remembers this address and uses it for every Read or Write transaction.
So you do not need the device address in the data buffer for the Transaction_Write
The example of Ben could be say an EEPROM, as my example, where the data buffer might contain:
.data[0] = Address in the EEPROM
.data[1] = Data byte to write to the EEPROM

And yes, you are correct about the 0x8003 for 3 bytes.
You only need the 0x8000 part if you don't want a Stop at the end of the transaction.
This is for cases where a write-restart-read is required by the device.