4

I'm converting some code over from .NET Micro Framework which I was running on a Netduino. The code measures the frequency of a square-wave oscillator that has a maximum frequency of about 1000 Hz, or a period of about 1 millisecond. The application is a rain detector that varies its capacitance depending on how wet it is. Capacitance increases with wetness, which reduces the oscillator frequency.

On the Netduino, I used an InterruptPin. It's not a genuine interrupt but schedules a .NET event, and in the EventArgs is contained a timestamp of when the pin value changed. On the Netduino, I could also configure whether it would be the rising or falling edge that would trigger the event. I managed to get this working fairly well and 1 KHz was approaching the maximum throughput that the Netduino could reliably measure.

On the Raspberry Pi, things don't go as well. It's running Windows 10 IoT Core, which to be sure is quite a different environment to the Netduino. I have a ValueChanged event that I can tap into but there is no timestamp and it occurs twice as fast because it gets triggered by both halves of the waveform. I hoped that, with its faster quad-core CPU, the Raspberry Pi might be able to cope with this, but in fact the best throughput I can get appears to be in the order of 1 event every 30 milliseconds - an order of magnitude worse that what I got on the Netduino, at least, which means I'm falling a long way short of timing a 1 KHz square wave.

So I'm looking for ideas. I've thought about slowing the oscillator down. The original circuit was running at around 1 MHz and I've added a lot of resistors to increase the time constant, bringing it down to around 1 KHz. I could go on adding resistors but there comes a point where it starts to get silly and I'm worried about component tolerances making the thing hard to calibrate.

It would be handy of the Raspberry Pi exposed some counter/timer functionality, but none of these 'maker' boards seem to do that, for some unfathomable reason.

One approach could be to use an A-to-D converter to somehow get a direct reading, but the electronics is a bit beyond me (hey, I'm a software guy!).

There is enough grunt in the Raspberry Pi that I ought to be able to get this to work! Has anyone found a way of getting faster throughput to the GPIO pins?

Tim Long
  • 13,508
  • 19
  • 79
  • 147
  • Unfortunately this appears to be an issue with your environment lacking primitive support for embedded development necessities :( – apscience Nov 15 '15 at 23:42
  • @glasdocc I tend to agree - it could be better thought out but I think the Pi developers never really aimed it at people running Windows and doing embedded development. But even boards aimed at that level don't seem to expose counter/timer features, I know not why! I found a setting that lets me select a DMA based GPIO controller instead of the standard one which doesn't use DMA. It's supposed to increase the performance by two orders of magnitude, but when I select that driver any attempt to open an IO pin produces an exception and my code ends up in the top level unhandled exception handler. – Tim Long Nov 15 '15 at 23:54
  • I'm investigating use of the 'Lightning GPIO Provider' which is supposed to increase performance by two orders of magnitude. It might just be enough... if only I could get it working! – Tim Long Nov 22 '15 at 06:43

0 Answers0