2 Arduino I2C communication

[mnfisher]

Note - the slave can read / store the flowrate data every 1s or when requested (the same applies for either i2c or SPI).

However - the master must request the data from the slave (the slave does not (can not) initiate the data transfer). It would be possible to have this the other way round if required - so the sensor is connected to the master which passes the data to the slave to output on a display to UART etc.

To muddy the waters slightly - it is possible to have multiple masters on a bus - they must check that the bus is not in use before attempting to use it by issuing a start condition.
It is probably more useful to have multiple sensors (slaves, each with a different i2c address) - where the master requests data from sensor 1, 2, 3 ... 1, 2, 3 at specific intervals or when specific conditions are met (user presses a button?)

Martin

[max.tisc]

the sensor is SPI only
in the examples you proposed, the second one seems to me to be the most suitable one, I did some tests but I don't get the desired results, even in simulation it doesn't seem to work correctly, returning single digits and not the complete number and when reading uarts, bad numbers.
I attach the file, surely there is something wrong

[mnfisher]

Sorry - the slave certainly won't work in simulation. The master 'would' work - but unless you connect to a slave , what is being displayed.

I'm not quite sure I follow what are you trying to achieve. The slave is to send a sensor reading (what is this - a byte, word, long or string? or multiple thereof). At present the master is requesting 4 bytes (saved into .reply[0..3])

I modified the example - here it sends a 'simulated' sensor reading as a long word - in this case count - which increments each second. The master receives the long word (which is saved MSB .. LSB) and prints it to UART.

On the oscilloscope it shows as:

LabNation_Screenshot31.png (230.82 KiB) Viewed 1775 times

Note that I disable / enable the interrupts around the code that writes the data to 'reply' ready to be written (to prevent a partial result being transmitted)

mst.fcfx

(15.03 KiB) Downloaded 75 times

slv.fcfx

(18.44 KiB) Downloaded 76 times

Note that here the master is requesting data from the slave every 200ms (so in this artificial demo - the reading should change every 5 readings (approx as UART takes a little time too))

[max.tisc]

I'm sorry I wasn't clear enough. the data that will be transmitted from the slave to the master will be of the byte type and will be 20, (in the meantime, to do tests and understand how it works, even 4 is fine) then the master will have to take some of these bytes for example byte1 and 2 for the speed of the flow, byte3 and 4 for signal strength etc etc, the slave code you gave me previously works well on the uart output I see the letters A B C D alternating, it is the receiving part of the master which on the uart gives incorrect results as you can see from the screenshot I sent you before, I don't see 1 2 3 4
the new slv file being compiled gives an interrupt handling error and I couldn't test it.
thank you

[mnfisher]

Okay - yes dei() isn't right to disable interrupts. Just delete this and the sei() for now (in ReadSensor()!).. 20 bytes would be okay - extend reply in slave (and in master) - and request 20bytes

Will have to investigate further on how to disable interrupts - not sure where I got dei from - but googling it didn't reveal anything so I guess I made it up...
The issue arises - if the sensor is writing 20 bytes to be sent and the master requests during the write - some bytes might contain the previous value. However, that shouldn't be too hard to fix (famous last words) - an alternate method would be for the master to send a 'write' command with a known delay after it - allowing the slave chance to read the sensor etc before the read request. This approach might also work well for battery powered slaves that 'sleep' between reads?

Martin

[max.tisc]

Hi Martin, the sensor that sends data to the slave has an output pin that indicates when the raw data is available for reading so it should be easily manageable, what I see in the master's uart output are only 0 and not the entire sequence of bytes received

[mnfisher]

Can you post your code - and I'll swap my test rig around and try the UART on the master this afternoon.
Looks as though the slave is sending okay - so hopefully nothing too much awry...

Martin

[max.tisc]

the code is the last one you posted.

[max.tisc]

the code is the last one you published, I haven't changed anything
Couldn't you save the data arriving at the master in a circular buffer and then take only the ones you need?

[mnfisher]

It is indeed an easy fix...

the line .sensor = .sensor << 8 + .reply[.i] needs parentheses to give the right result...

So should read
.sensor = (.sensor << 8) + .reply[.i]

Now - I have a happily increasing result - although I could get nothing from the UART on the Arduino Mega (at all) - so I swapped to a Uno.
Then I needed pull-up resistors. If it wasn't tricky it wouldn't be fun?

No - I don't think you can receive the data straight into a circular buffer on the master (it was possible on the slave because we used out own interrupt handler)

Martin