ARM TWI or I2C

[Mantas]

Hello MM,

I was analyzing ARM I2C CAL file and I found this line:

Code: Select all

#if (MX_I2C_CHANNEL_X == 1)															//Use Master I2C Hardware 1
		#error "ARM does not support I2C in this mode - SW implementation only"
	#endif

What does this mean? I know that ARM supports hardware I2C or as it refers to it as TWI (twin wire interface), to be exact pins PA3 - TWD and PA4 TWCK. So why does it write that the ARM supports software implementation only??? This got me really confused...

Best regards,
Mantas

[Enamul]

Hi

I have had a look at the ARM_CAL_I2C file. I have noticed this code but I think that is meant for the more than one channel of I2C. If you want to use more than one hardware I2C channel you will get that error msg. 2nd one has to be software I2C not hardware. MM guys might correct me if I am wrong.

[Mantas]

Good morning,

So after all I was right again. This morning I was trying to do some I2C communications with some I2C sensors, and when I was compiling I got a message:

File name: F:\Flowcode Projects\SPA\I2C_communications_20121113.c
Title:
Description:
Generated by: Flowcode v5.3.0.0
Date: Wednesday, November 14, 2012 10:53:14
Licence: Professional

http://www.matrixmultimedia.com
Launching the compiler...
C:\Program Files (x86)\Matrix Multimedia\Flowcode ARM V5\Tools\MX_bats\arm7comp.bat "I2C_communications_20121113" "F:\FLOWCO~1\SPA"
In file included from C:\Program Files (x86)\Matrix Multimedia\Flowcode ARM V5\CAL\includes.c:159,
from I2C_communications_20121113.c:725:
C:\Program Files (x86)\Matrix Multimedia\Flowcode ARM V5\CAL\/ARM\ARM_CAL_I2C.c:252:4: error: #error "ARM does not support I2C in this mode - SW implementation only"
I2C_communications_20121113.c: In function 'main':
I2C_communications_20121113.c:961: warning: pointer targets in passing argument 1 of 'FCD_LCDDisplay0_PrintString' differ in signedness
I2C_communications_20121113.c:974: warning: pointer targets in passing argument 1 of 'FCD_LCDDisplay0_PrintString' differ in signedness

Error returned from [arm-elf-gcc.exe]
Return code = 1
Flowcode was unable to compile the flowchart's C code due to the following errors:


If your flowchart contains C code, please review this carefully. If your flowchart contains no C-code or you have thoroughly reviewed the code, contact Technical Support.


FINISHED

To be clear I am not using any C code.

MM, I am seriously disappointed. I am waiting for ARM update, with the necessary fixes, because I need to continue my work.

Regards,
Mantas

[Mantas]

By the way, I have tried software mode, and it's useless, as I am not getting any acknowledgment from the sensor...and i don't think that clock stretching is possible in software mode...

[Benj]

Hello,

The ARM hardware does support I2C otherwise known as the two wire interface.

However the way it works is drastically different to the way other devices work.

Flowcode allows access to the different sections of the I2C such as start, restart stop etc. However the I2C hardware on the ARM requires that you load all the data for a single complete transaction and then it goes off and does it.

Therefore to maintain the Flowcode way of allowing full access across all versions we decided to not support the hardware I2C on the ARM devices. The software implementation works a treat so you shouldn't have any issues with it.

Neither software or hardware modes currently support clock stretching.

[Mantas]

Hello Ben,

You were right. The software I2C/TWI implementation does work. I just got one of my I2C sensors working. Lets hope the others will do the same. But as I understand by using software I2C I have some limitations, like I can't choose bus speed, or SMBus option. Are there any other drawbacks of software mode? And are you planning to implement the hardware option on the ARM in the future?

Best regards,
Mantas

[Benj]

Hello Mantas,

Great glad you managed to get it up and running using the software implementation.

Apart from the speed and SMbus limitations there shouldn't be anything else that you cannot do using the macros.

As for the hardware implementation, I believe this is the first request we have had to do it but it's certainly something we can do if we are being asked for it. Basically our user base tends to decide what we do next and what gets improved or modified.

Anyway I will add it to my list and try to find some time to look into how easy it would be to create the hardware version for you. I think this will require ARM specific macros so it may be a C file update I release on the forum that never makes it into the release version to avoid confusion in the other Flowcode varients.

[Mantas]

I would be very pleased with that. I hope you can find some time to do this, as I understand you are very busy Anyway, I am waiting for the ARM 5.4 update. 2 weeks ago Jonny told me that the update is ready, but somehow I don't see it, hope it will be released soon

Best regards,
Mantas

[Mantas]

Hello MM,

Continuing this topic I would like to ask at what speed is software I2C working on ARM chipset? The thing is I am working with some I2C sensors, and some data received is a bit noisy so I need to filter the data with some digital filters, but for that I need to know the sampling rate. How can I calculate it or measure it?

Best regards,
Mantas

[Mantas]

So will anyone answer my question or not?

[Benj]

Hello Mantas,

Sorry for the delay,

It looks like the software delay is 20us so for a single bit (two clock edges) your looking at around 40us or a baud just short of 25Kbps.

[Mantas]

Thanks Ben for your reply, I found this info a few hours ago studying the I2C cal file so it is correct 1/(2*0.00002) = 25000Hz, or bits per second, 25kbs

Best regards,
Mantas

[Mantas]

Hello everyone,

So I was waiting and waiting, and decided to do it my self. I managed to write a code and macros for TWI (I2C) hardware. I attached the CAL file

ARM_CAL_I2C.c

CAL_I2C

(17.13 KiB) Downloaded 265 times

and specific macros for I2C component, which you have to import, and also a modified defines function.
The problem is very strange, some of the sensors like BMA180 accelerometer is replying, and in my software when checking for online sensors, it goes well and does not cause any errors, on the other hand ITG-3200 gyro is replying it's ID correctly when looking at the logic analyzer but the program senses that it's not online and gives an error message. I was trying to make a Receive function with the pointers, but had some issues, so instead I used a global array variable rdata[22] to collect the receive register data. My suspicion is that somehow the register values are not assigned to the global array variable. See the logic analyzer screenshots. The ITG-3200 ID is 0x69 and BMA180 ID is 0X03. The clock speed is set to 320kHZ (software clock goes only to 100kHz at best when setting delay in CAL file to 0). In software mode all sensors work fine.

PLEASE HELP TO FIND THE PROBLEM!!!!

BMA180.jpg

BMA180

(160.82 KiB) Downloaded 1069 times

ITG-3200.jpg

ITG-3200

(161.04 KiB) Downloaded 1069 times

[Mantas]

And the component custom functions:

TWI_DEFINES.fcc

Custom defines

(12.27 KiB) Downloaded 303 times

TWI_TX.fcc

TX TWI

(12.27 KiB) Downloaded 281 times

TWI_RX.fcc

RX_TWI

(12.27 KiB) Downloaded 271 times

Best regards,
Mantas

[Mantas]

And the component custom functions:

The attachment TWI_DEFINES.fcc is no longer available

The attachment TWI_TX.fcc is no longer available

The attachment TWI_RX.fcc is no longer available

Best regards,
Mantas

Updated RX and TX macros:

TWI_RX.fcc

RX_TWI

(12.27 KiB) Downloaded 294 times

TWI_RX.fcc

RX_TWI

(12.27 KiB) Downloaded 294 times

But still some issues with the TX macro......should be 0b00000101 but sending 0b10100000...very strange

Regards,
Mantas

[Mantas]

Update:

I changed the Data2Send array variable to Data2send non array type and it fixed the flip endings issue...I have no Idea why it is flipping, but now it is working like a charm, just the issue is that only one byte can be written...maybe MM will find a fix for this, but for me it is enough to have one write byte at a time. Also now time to figure out how to associate clock frequency preset in I2C component with the CAL file init TWI function...

BR,
Mantas

working macros:

TWI_DEFINES.fcc

Defines

(12.29 KiB) Downloaded 205 times

TWI_RX.fcc

Receive

(12.29 KiB) Downloaded 192 times

TWI_TX.fcc

Transmit

(12.29 KiB) Downloaded 200 times