0

Let me start by being completely honest: I am not an expert in Electronics at all! I am a software developer, familiar with C#, C++, Python, etc. I also understand the difference between preemptive and RT operating systems.

What brings me here:

I am currently playing around with an Arduino (Uno) (which has a few DS18B20s connected to it) and a Raspberry Pi3 which is running Windows IoT.

I've connected the Pi and the Arduino via I2C, but I find it hard to understand how this actually works on lower levels.

As Windows IoT is not a real-time OS, how can it interact with the I2C bus? Lines are pulled low in micro second intervals.

The temperature sensors I use (DS18B20) rely on the OneWire-protocol. Works like a charm in Arduino, but when I google for the combination with RPi / Windows IoT (as it's just one digital input which are available on my Pi as well), I can read about how great Debian would serve that purpose, and how miserable Windows IoT is for a job like that (since, again, Windows IoT is not an RT-OS, I get that much).

But, if that's true, why is I2C not an issue for Windows IoT on an RPI? Or is it? And have I opened a can of worms trying to connect a RPI (Windows IoT) with an Arduino board using I2C?

What I hope to learn here:

  • I would really really appreciate some detail in the answer. Not just some hatred words that Windows sucks and Linux rules.
  • How does Windows 10 IoT deal with "real time" protocols like I2C / OneWire
  • Is I2C a stable solution for Windows IoT (like would it be a stable solution for consumer electronics)?
Improve this question

1 Answer 1

Reset to default
2

The Pi has hardware peripherals which implement

  • serial links
  • I2C
  • SPI

Of those only the serial link actually needs to be "real-time" as the Pi acts as the I2C and SPI bus master. Being bus master means the Pi controls the I2C and SPI clocks and can be as slow as it wants. In fact I2C and SPI were both bit banged on the Pi long before the respective hardware drivers were integrated into the operating system.

Improve this answer
2
  • So what is generating the clock signal for I2C? Is that done by a Windows IoT kernel driver? Or is this "serial link" taking care of that? I'd like to understand what happens "under the hood" when I write a line of code to send a byte to my arduino (slave) and read back the response in my Windows IoT device. Windows IoT / C# cannot be responsible for reading the bytes real-time, so it's buffered somewhere. Right? Where? In hardware? Or is there a part of the Windows IoT kernel which is real time? Or is that a chip set? Where can I read more about how this really works?How it all works together
    – bas
    Commented Sep 20, 2016 at 6:34
  • As @joan says, the Broadcom SoC has hardware implementations onboard for I2C. Part of that hardware implementation is a 16 byte FIFO buffer, so the device driver simply writes the bytes to the buffer and the hardware worries about sending it (no interaction required from the OS). The datasheet is available here : raspberrypi.org/wp-content/uploads/2012/02/…
    – KennetRunner
    Commented Sep 20, 2016 at 8:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.