Page 1 of 1
I2C Woes
Posted: Thu Jun 01, 2017 7:26 pm
by mnf
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]
[/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 401 times
Re: I2C Woes
Posted: Fri Jun 02, 2017 10:22 am
by LeighM
If this is a macro (sub-routine) then I would suggest removing this ...
as it will shift blinkm every time it is called, hence the value will only be correct on the first call
Try this instead ...
Also the datasheet seems to indicate that you can also use the broadcast address of 0
Might be worth a try.
Re: I2C Woes
Posted: Fri Jun 02, 2017 2:57 pm
by mnf
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
Re: I2C Woes
Posted: Fri Jun 02, 2017 3:37 pm
by LeighM
You would need to attach your Flowcode project file (.fcfx) so that we can see the whole picture
Re: I2C Woes
Posted: Fri Jun 02, 2017 4:37 pm
by mnf
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]
[/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
Re: I2C Woes
Posted: Sat Jun 03, 2017 9:52 pm
by mnf
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!
Re: I2C Woes
Posted: Mon Jun 05, 2017 11:06 am
by LeighM
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
Re: I2C Woes
Posted: Mon Jun 05, 2017 5:49 pm
by mnf
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.
Re: I2C Woes
Posted: Mon Jun 05, 2017 6:06 pm
by mnf
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!
Re: I2C Woes
Posted: Sat Jun 10, 2017 1:23 pm
by mnf
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
Re: I2C Woes
Posted: Sat Jun 10, 2017 1:46 pm
by kersing
The nRF24N01 uses SPI not I2C. Why post this in an I2C thread?
Re: I2C Woes
Posted: Sat Jun 10, 2017 4:25 pm
by mnf
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!
Re: I2C Woes
Posted: Sat Jun 17, 2017 9:16 am
by mnf
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!