One-Win10IoT master vs. Many-TinyCLR clients communication

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)?

Thank you very much! :blush:

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)

That is a real good question. What is the best way to connect, using wires?

1 Like

Thank you for you answer, valon_hoti_gmail_com.

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?). :roll_eyes:

Anyway, I will also try to investigate about MQTT porting from NetDuino.

Any other idea with existing implementations? :anguished:

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… :roll_eyes:

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? :thinking:

RS232 and RS485 both use uart. The difference is in wiring.

2 Likes

If I may ask, why no wifi? That would be the easiest, and making your own messages isn’t too hard, depending on what u wanna do (simple 2-3 commands).

MQTT is definitely a popular tool for wifi/networked systems, that have a lib already written.

To the community: Is there a MQTT for tinyclr? Been wondering this myself.

Also, are there any wired ethernet modules for tinyclr devices like there were for the gadgeteer stuff?

If what you are doing is a project and not a product, i.e. where cost is a big deal…Just get rs232-rs485 adapters.
Google it…many, many choices.

1 Like

Also, if you don’t yet have rs232 levels you can buy adapters that convert the 3.3v to rs232 standard.
I think GHI sells one?..or again google.

1 Like

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” :wink: (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…

If you are up for a challenge, create your own native code interop to handle slave SPI or I2C.

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.

1 Like

https://old.ghielectronics.com/community/codeshare/entry/865
https://old.ghielectronics.com/community/codeshare/entry/880
https://old.ghielectronics.com/community/codeshare/entry/1102

1 Like

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.

An old mqtt library for NetDuino version 3.0

HOW to use click here …

but need a little modification to use with 3.1 or 3.1.1 and is missing SSL too

1 Like

I just want to say I love this community! Look at all these great minds coming together :smile:

1 Like

Thank you all!

Gus, I had thought about creating an I2C client class from scratch, but I’m afraid I do not have enough skills. :anguished: But an attempt can always be made… (snooping into GHIElectronics.TinyCLR.Devices.I2c :smile:).

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. :roll_eyes:
BTW, thank you RoSchmi and valon for your links!

Dave, fortunately there are only my devices. :sweat_smile: No risk of conflict with other systems. :wink: