Raspberry Pi3 and I2C not working

[wardelder]

I am trying to use the I2C on a Raspberry Pi3. I have a scope on the SDA and SCL lines and do not see any I2C traffic being caused by my application. I do see I2C traffic on the I2C buss, but it is not created by my Flowcode app. When I run "i2cdetect -y 1" on the Pi3 I see my device at address 0x60 is active and I see the decoded address on my scope.

Does anyone have a working I2C app built for the Pi3?

Note: The scope I am using has a logic analyzer so I also see the I2C decodes and can trap on I2C addresses

[LeighM]

Hi
For Raspberry Pi you either need to use the Software channel of the I2C components.
Or to use the hardware channel, use the I2C CAL component from the Tools menu.
In this case then use the Transaction macros. Initialise, Read and Write
Check the return value of the Transaction_Initialise, it will return the value of 1 if the hardware channel was opened successfully.
Hope that helps
Leigh

[wardelder]

Thanks for the info. The Software I2C is working fine now. Not sure why but a fix showed up yesterday and seemed to solve the Software I2C. The Hardware I2C is still not working.

When I use the Transaction_Initialise routine it returns a zero for both the Hardware I2C and the Software I2C. If I ignore the return code and let the code continue, the Software I2C works fine. The Hardware I2C fails.

Any ideas? I am trying a different Pi with a newly built Os.

[wardelder]

Setup a new Pi2 and still have the same issue. Hardware I2C does not work but Software I2C does.

[wardelder]

WAIT!!! I got it working. I was misusing the Transation_ commands. My bad. Sorry to be a bother.

[LeighM]

No problem, glad you have it working now, thanks for letting us know

[jhill]

Hi,

I have been trying to get a MCP23017 working on the raspberry Pi, as a part of the expander PI hat.
https://www.abelectronics.co.uk/p/50/expander-pi
The Python scripts work fine, so the device is being seen at the correct address.
I started by trying the flowcode MCP23017 components, but after reading this thread it became clear this is not going to work.
I tried using the I2C CAL components for a standard I2c exchange, the these do not generate any traffic on the hardware i2c port.
I see from the posts above I need to use the Transaction macros. Initialise, Read and Write.
Initialise returns a 1, so all good there. I just cannot figure out how to use the Read and Write transaction components, I assume with the standard CAL i2c transaction components?
I cannot find an example on this, can anybody point me in the right direction please?
Thanks,
James.

[LeighM]

Hi James,
You need to allocate a byte buffer for the data that is being transfered in or out.
To write a single byte of data to an address in the MCP23017, set the first byte in the buffer to the address and the second to the data to be written.
Buffer[0] = address
Buffer[1] = data
Then call TransactionWrite(Buffer,2)
Similarly if you want to write to more consecutive locations you can add Buffer[2], [3] etc, then call TransactionWrite(Buffer,4)

To read a location from the MCP23017, first do a write of 1 byte containing the start address as above, e.g. TransactionWrite(Buffer,1)
Then call TransactionRead(Buffer, 1) to read just one location data into the Buffer,
or TransactionRead(Buffer, 8 ) to read 8 consecutive locations from the MCP23017 into the Buffer.
The Buffer[0] location will now contain the first byte requested (overwriting the address).
Just ensure that Buffer size is big enough for your largest transaction.

Hope that helps,
Leigh

[jhill]

Hi Leigh,

Thats great, thank you, ill give that a try!

Best Regads

James

[jhill]

Hi!

The i2c CALL component is now working perfectly on the pi, thank you!

I am now trying to get SPI running on the pi. I have assumed again i need to use the CAL SPI component.

As with i2c, I have created and configured a buffer, then call the cal spi transaction macro. Unfortunately, it always returns a zero and generates no traffic on the spi port. I have tested the hardware with a python script and everything works fine.

I don’t seem to be able to track down a CAL SPI example, is there something else i need to do?
I have tried both manual and auto chip select, and also using the unit and uninit macros either side of the transaction, but it always returns 0 and generates no traffic.

Best regards,

James.

[LeighM]

Hi James,
Good to hear that you have I2C running OK.

For SPI, first check that you have the device /dev/spidev0.0
(Although your Python test implies that you have)
You will need to call the CAL SPI Master Init at the start of your program.
Does that return 0 (fail) or 1 (success)?
We do not use the auto CS, so you will then need to assert CS on a custom pin, then call Master Transaction.

EDIT: I’ve just noticed that our CAL SPI Master Init macro does not have a return value, which is needed in this scenario. I will get that fixed

[jhill]

Thanks Leigh

Yep, the device is in /dev/spidev0.0

Cool, I will add the init back in and check the return once you have updated the component.

For the chip select can I use the cs macro in the cas spi component or do I need to drive the ca pin directly?

Just for interest, the python code works, but it’s then broken when I try and run the flowcode compilation (not at the same time!) , and stays that way until a reboot of the pi.

Thanks again for your help.

Best regards

James.

[LeighM]

Hi James
Yes, you can use the component Master CS Enable etc
Attached are the updated component and CAL C files, to go into:
C:\ProgramData\MatrixTSL\FlowcodeV8\Components
C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\RPI

nb. This component will cause build errors on other targets until we get all device SPI CAL C files pushed out on the update system.

Just for interest, the python code works, but it’s then broken when I try and run the flowcode compilation (not at the same time!) , and stays that way until a reboot of the pi.

Try a Master Uninit before program exit

[jhill]

Hi Leigh

It looks like the init is returning a zero. Please see attached test code in case I am doing something daft.

Best Regards

James.

[LeighM]

You just need to return the value into the OK variable

OK.jpg (7.74 KiB) Viewed 8440 times

return.jpg (51.69 KiB) Viewed 8440 times

If Flowcode won't let you do that, then it is still using the old component

[jhill]

Hi Leigh

Sorry I was actually doing that, I just managed to loose it in the cut/paste and trim down to post here

The init is returning a zero, (OK=0)

Interestingly even trying to init the spi is enought to break further access to SPI, i.e from python script. i.e.

Clean boot of PI> Python script returns data > stop python script > run flowcode SPI-TEST > Init fails > Cntrl C to stop > re run python script > script fails to return data.


Best Regards

James

[LeighM]

Presumably you have tried? ...
Clean boot of PI > run flowcode SPI-TEST

[jhill]

Good Morning Leigh,

Yep, I wanted to remove any possibility that python, or anything else was holding on to the port. running lsmod shows 0 against anything "SPI" which (I think) means its not in use?

Best Regards,

James.

[LeighM]

lsmod is for listing modules, try lsof

edit: meanwhile I will try and dig out some hardware to test

[LeighM]

Hi James,
I've just done some testing using Raspberry Pi on our EB0036 and it seems to work OK.
I've got a loop back on MISO/MOSI.
lsof (sudo apt install lsof) shows the device open whilst the program runs, closed after.
Test program attached.
I've not tried Python, I'm a bit rusty on that
Leigh

[jhill]

Hi Leigh,

**************Edit, having played some more, this is now working fine, the CS macro's are good. I think there is something flaky with my PI build , but thankyou very much for you patience and great support!*****************************

Thank you for the example! I am not sure where my SPI test has gone wrong, but modifying your example I can get both init and transaction macros to complete successfully, and can see traffic being generated on the SPI port.

What I am struggling with now (sorry) the chip select. The SPI CAL CS makros do not pull the CS line low, I do not seem to be able to write directly to the CS0 (port G.8 ) line using the port output macro, I assume as its reserved for SPI.

How can I get the CS line pulled low for the read?

Best Regards

James