What are the easiest/better ways to communicate between one Win10IoT device (i.e. RaspPI) and many TinyCLR devices?
Excluding I2C and SPI, that can’t act as a slave in TinyCLR, and ethernet (for some project related reasons), what are, in short, the pros and cons of the other possibilities (first of all for simplicity of implementation, but also for number of wires and speed)?
Try MQTTnet (.net core 2.0) broker on Raspberry Pi as master
and try to port MQTT client from NetDuino to TinyClrOS if not ported from anyone
And use wifi so there’s no limitations and no wire too(and have good speed - i use mosquitto mqtt broker with raspberry pi zero and raspbian and it act so fast in my home)
Sorry, my lack in question: I’m looking for something ready-to-go and wired (no wifi, bee, etc.).
Also it seems to me that MQTT is based on ethernet (or am I wrong?).
Anyway, I will also try to investigate about MQTT porting from NetDuino.
How long distance you need to wire
So rs485 is an solution like uart which you can connect up to 1200 meter and up to 32 - rs485 (include raspberry pi) devices but you need to create an managed communication way since there no master/slave
Thank you again.
The distances are relatively small (3/4 meters).
I feared that, despite the years and new technologies, UART would have been the only way…
I have used RS232 in the past, but never RS485. Having found nothing on RS485 in the TinyCLR forum nor in the documentation, I think I have to start from: UART right?
Thank you Gus, I’ll try to understand how to manage it in TinyCLR.
jasells, no probllem for me to answer, but the exclusion of wifi is simply one of the project’s “requirements” (for environmental reasons).
Thank you mhardy; I was hoping for something simpler (like I2C), but if there are no alternatives I’ll go for that way. Just a few moments ago, I was looking at a RS485 serial TTL UART converter…
Once the 3.3v to rs232 to rs485 hardware is implemented, I would suggest modbus as the protocol.
However without knowing the specs of what you are trying to accomplish…could be overkill?
Many libraries for modbus…seems I remember someone on this forum posted such…for .netMF.
There is a timing issue with the Modbus libraries that are linked. If you have more than 1 device on the bus thatis not based on this code and and it responds very quickly, the driver cannot handle this and loses bytes. If all the devices are your own, you can expect it to work.
I was using a Schneider Altivar VSD and one of my own devices running a G120 with the above code. The master was a Schneider PLC. It worked perfectly when only talking to the G120 based system but once the VSD was added as a second device, the G120 failed to handle the reply from the VSD as the first 1-2 bytes were lost each time.
I tried in vain to get it to work but eventually we ended up adding a second RS485 port on the PLC to talk to my G120 device. Rock solid ever since.
The new design uses an ATMEGA128 instead of the G120 and this works fine with both so I know the issue was the library. Something to do with the timing in the thread that handles the UART bytes.
Gus, I had thought about creating an I2C client class from scratch, but I’m afraid I do not have enough skills. But an attempt can always be made… (snooping into GHIElectronics.TinyCLR.Devices.I2c ).
mhardy, I approached modbus in the past with NETMF. It’s a possibility, even if, as you write, the effort/benefit ratio does not always pay off.
BTW, thank you RoSchmi and valon for your links!
Dave, fortunately there are only my devices. No risk of conflict with other systems.