I2C Woes

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 7.

Moderator: Benj

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

I2C Woes

Postby mnf » Thu Jun 01, 2017 7:26 pm

Hi,

I'm very new to FlowCode (2 days in) - so this is hopefully a simple problem?

After trying the usual blinkies and a DS18B20 and then a DS3231 RTC with success (I'm liking this even though I had to download a new component for the RTC to get it to work) I then tried to get some more generic i2c comms to work.
Actually I tried an i2c LCD display but as the ones to hand had a PCF8574 port expander and I couldn't easily find a component to handle this I thought I would try something simpler.

So I tried a BlinkM - and failed completely. It is surely something obvious I am missing but after several hours of head scratching I am none the wiser.
Running on an Arduino nano
[img]
flowcode.png
flowcode.png (56.27 KiB) Viewed 6881 times

[/img]

The BlinkM is on address 0x9 (and this is set into blinkm as initial value)

This mimics the Arduino code

Code: Select all

  Wire.begin();
  Wire.beginTransmission(0x9);
  Wire.write(0x6f);
  Wire.endTransmission();


Which stops the BlinkM running it's startup demo (same hardware) as expected.

Adding a blink (loop and toggle pin 13) after the i2c comms reveals that the code is crashing - it never reaches the blinky) - I have tried using channel 1 / software at all speeds (including the optimistic ones)

Code is running on Arduino Nano with i2c connected to A4/A5 and the BlinkM gives no reply to the command ('o') which should stop current script. FlowCode is v7.

Thanks for any pointers.

Martin

blinkm.fcfx
Source code with goto colour blinkm command - i2c start never returns?
(8.48 KiB) Downloaded 120 times
Last edited by mnf on Sat Jun 03, 2017 9:44 pm, edited 1 time in total.

User avatar
LeighM
Matrix Staff
Posts: 1962
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 474 times
Been thanked: 674 times
Contact:

Re: I2C Woes

Postby LeighM » Fri Jun 02, 2017 10:22 am

If this is a macro (sub-routine) then I would suggest removing this ...

Code: Select all

blinkm = (blinkm << 1)

as it will shift blinkm every time it is called, hence the value will only be correct on the first call
Try this instead ...

Code: Select all

i2c::TransmitByte(blinkm << 1)

Also the datasheet seems to indicate that you can also use the broadcast address of 0
Might be worth a try.

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Fri Jun 02, 2017 2:57 pm

Thanks for the ideas. It hasn't reached macro status yet - I was trying to get communication up and running in the first instance. I will try a general broadcast this evening and see if that effects an improvement.

As an aside I have found that including some components (dht22 for example) causes compilation to fail, usually with one or more undefined macros, I'm not sure how to proceed in that case. Is this a bug or a configuration error?

Martin

User avatar
LeighM
Matrix Staff
Posts: 1962
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 474 times
Been thanked: 674 times
Contact:

Re: I2C Woes

Postby LeighM » Fri Jun 02, 2017 3:37 pm

You would need to attach your Flowcode project file (.fcfx) so that we can see the whole picture

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Fri Jun 02, 2017 4:37 pm

I can post he code this evening if it will help, but the image above is all of it! Just wanted to see if comms working with a minimal example before committing too much time.

Added:

Tried a general broadcast (address 0) followed by 0x6f which worked (ie the BlinkM stopped it's routine) when run from Arduino libraries but not from FlowCode.

As an example of compilation errors I added the DHT22 component to a new project and a single macro call to the flowcode diagram. (I used SampleSensor) then the compilation generated the following:
[img]
error.png
error.png (45.39 KiB) Viewed 6844 times
[/img]

Which step am I missing?

Just solved the compilation problem - altering the DHT 22 data pin to one that actually exists :) (the default is PortA0) allows the compilation to complete successfully (I've left the above in the slight chance that someone else will encounter the same problem and it will maybe solve them a few minutes head scratching). I'll try and get temp and humidity up and running and then come back to the i2c problem (hopefully some kind person will have give a pointer by then!)

DHT22 (actually a AM2320) works very nicely in one wire mode!

Martin
These users thanked the author mnf for the post:
LeighM (Mon Jun 05, 2017 11:03 am)
Rating: 5.26%
 

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Sat Jun 03, 2017 9:52 pm

Have appended source to first message - tried with i2c in software and hardware mode (and running on an Uno instead of a Nano)

No joy. As mentioned same hardware works fine from Arduino IDE with similarly basic command to the BlinkM works jut fine. Adding an output to turn on the led on Digital 13 seems to show that the call to i2c:start never returns.

I've had a similar problem trying the nrf24l01 - the call to nrf24l01::initialise never returns in hardware mode and always returns 0 in software mode.

A frustrating day!

User avatar
LeighM
Matrix Staff
Posts: 1962
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 474 times
Been thanked: 674 times
Contact:

Re: I2C Woes

Postby LeighM » Mon Jun 05, 2017 11:06 am

Adding an output to turn on the led on Digital 13 seems to show that the call to i2c:start never returns

Was that with hardware mode? I don't see anything in software mode that could cause i2c:start to never return

Also, do you have any pull-up resistors on SDA and SCL?
If not, this might be causing issues with clock stretching
These users thanked the author LeighM for the post:
mnf (Mon Jun 05, 2017 6:06 pm)
Rating: 5.26%
 

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Mon Jun 05, 2017 5:49 pm

Hi Leigh,

Was that with hardware mode? I don't see anything in software mode that could cause i2c:start to never return


Yes - hardware only - software mode returns and LED on 13 comes on. No effect on blinkm however.

Also, do you have any pull-up resistors on SDA and SCL?


No - though in my defence the Arduino has inbuilt pull-ups and the blinkm is designed to fit onto the board (using a2/a3 as power and ground - although I'm not using them here)

I'll try adding a couple and report.

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Mon Jun 05, 2017 6:06 pm

Added a couple of 4k7 pull-ups and suddenly all is good.....

Hurray.

I knew I was missing something basic!

How do we turn on those internal pull-ups in FlowCode?

Then I just need to get the NRF24l01+ unit working and we're cooking with gas!

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Sat Jun 10, 2017 1:23 pm

This should probably be a new topic:

Spent several hours trying to get the nrf24l01+ unit working - first with a Arduino nano and then thinking that a power supply issue may be occurring with an FTDI Nero (a clone with a higher spec)

So - with the nano initialise wasn't returning. With the Nero - 0 was always returned.

Taking a peek into the C code generated:

Code: Select all

MX_UINT16 FCD_0e0f1_nRF24L01__Initialise()
{
    //Local variable definitions
    MX_UINT16 FCL_TEMP;
    MX_UINT16 FCR_RETVAL;

    FCP_SET(B, B, 0x1, 0x0, 0);
    FCP_SET(B, B, 0x4, 0x2, 1);
    FCI_DELAYBYTE_US(40);
    FC_CAL_SPI_Master_Init_1();
    FCI_DELAYBYTE_US(40);
    FCD_0e0f1_nRF24L01__WriteRegister(0x24, 0x4F);
    FCD_0e0f1_nRF24L01__WriteRegister(0x26, 0x07);
    FCD_0e0f1_nRF24L01__WriteRegister(0x3C, 0x00);
    FCD_0e0f1_nRF24L01__WriteRegister(0x27, 0x70);
    FCD_0e0f1_nRF24L01__WriteRegister(0x40, 64);
    FCD_0e0f1_nRF24L01__FlushRx();
    FCD_0e0f1_nRF24L01__FlushTx();

    return (FCR_RETVAL);
}


The return value FCR_RETVAL is declared but never actually set - so theoretically any value may be returned but seems to be 0 in practice!

So the 0 return for failure seems to be guaranteed and the success value (non zero) for a correct startup isn't happening....

Anyone else encountered this / has a workaround?

Martin

kersing
Valued Contributor
Valued Contributor
Posts: 1894
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 541 times
Been thanked: 1058 times
Contact:

Re: I2C Woes

Postby kersing » Sat Jun 10, 2017 1:46 pm

The nRF24N01 uses SPI not I2C. Why post this in an I2C thread?
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Sat Jun 10, 2017 4:25 pm

The nRF24N01 uses SPI not I2C. Why post this in an I2C thread?


I was continuing my train of thought.....

Then I just need to get the NRF24l01+ unit working and we're cooking with gas!


But I did say:

This should probably be a new topic:


And I guess you are right - I've made a new topic!

mnf
Valued Contributor
Valued Contributor
Posts: 621
Joined: Wed May 31, 2017 11:57 am
Has thanked: 56 times
Been thanked: 340 times
Contact:

Re: I2C Woes

Postby mnf » Sat Jun 17, 2017 9:16 am

Turning on the inbuilt pullup resistors also works. Simply writing high to SDA and SCL pins (PC3 and PC4) after initialising the i2c works.

I've attached my Flowcode - note that this is also using analog pins A2 and A3 to power the blinkm module as this was a very quick test and it was easier to plug the board onto the Arduino than wire it up....

A simple fade in (not a very edifying effect) on a blinkm - i2c working!

blinkm.fcfx
(10.21 KiB) Downloaded 85 times
These users thanked the author mnf for the post:
Benj (Mon Jun 19, 2017 10:11 am)
Rating: 5.26%