Flowcode Support Board

Hi

Ages ago I was trying to get a PIC talking to (I believe) a 328P and could send from PIC (Master) without issue but if I remember correctly I was getting similar in that the slave wasn't returning the correct info. Can't recall exactly the issue, but I had to move on to something else before I could figure it out.

Regards

I activated the LED on port B7 at the end of reception and the LED turns on and off quickly, but I only get one sequence, maybe a bug?

It is very odd = what hardware are you testing on? As you can see from my screenshot it had counted up quite a few iterations when I took it?

Can you 'disable' the 'Read' in the sender (master - will perhaps have to think again about the naming!)

Iain - can you remember what you got returned by the 'read' - I just get the first byte (which is correct) repeated however many times

I had a little peek at the CAL code and it all looked okay - and it seems to work receiving from sensors etc - maybe have some time for a better look at the weekend.

Martin

Looking at your screenshot - after the 'receive' SDA stays low which holds the i2c bus as 'busy' - and prevents further transmission.

If you look at the trace I posted - you can see that SDA goes high again after the 'read'
It might be a slightly different board - could you try a pull-up resistor on the SDA and SCL lines (4k7 or 10k) and see if that does anything beneficial?

Martin

Another 'oddity' - when writing m->s there is an ~18us delay between bytes. On receiving s->m there is a much shorter 'gap' (~8us) and adding a delay after each byte is transmitted doesn't affect this as expected - adding a 1ms delay gives 2 bytes with first value (and a 8us delay between them) then after ~1ms 2 bytes reflecting the 2nd byte of the reply (again with a short delay between them)
A 100us delay gives a similar result but with a 27us delay between the pairs.
As though the receiver isn't waiting for the data to become available correctly?
Adding a delay before the reply does result in a delay however - with the data received as above

Martin

you were right, the pull-up resistors were missing, I put them at 5.6k and now the data arrives every 100ms.
if it helps I already used a DS3231 which communicated with the Arduino in I2C and I could read and write on it, maybe the solution is there

for chipfryer27 if you remember what you did to solve it would be great

thank you all

Another step forward

The RTC is acting as a slave device. Could maybe look at the output for this and see what/how it varies?

ok I'll try to do something tomorrow

Hi

It was last year (or before) so my memory of it isn't great and I thought it was something I'd done wrong. Reading this post did sound familiar though and I think it was not refreshing the data to be returned. I'd need to go dig out the project file though.

Sorry I can't be much help,

Regards

A bit more playing and I almost got it to work by tweaking the CAL_I2C file - but it would work for one time and then stop. After a bit more fiddling - no joy.

So - I rewrote the slave side using the TWI interrupt to handle receipt and sending of data. This worked remarkably easily - so here is a very simple 'proof of concept' - it receives data (and stuffs it into a circular buffer) and serves up data (an incrementing counter) when requested.

Needs some work to make it truly useful - but should be easy to modify. The 'main' just initialises the i2c and enables the interrupt handler - there is nothing for it to do after that
Used with previous 'master' - receives and then sends 4 bytes... (and works with any number as requested or transmitted by the master)

Martin