1
\$\begingroup\$

I do not want to start a religious war, and believe that neither of them can be better in all circumstances. So, let' consider my circumstances.

My problem is that I am a software guy with no knowledge of hardware and Google is not my friend today, so I hope that I can get some advice here. In order not to start a religious war, let's confine it to which is more suited for my personal requirements, which is hopefully a question which can be answered (as opposed to a general "which is better?" which obviously cannot be answered).

It is, now that I come to try it, difficult to formulate exact requirements as I initially want to "play around and see what I can do", but here is as much info as I can give to help you to help me.

I do not want to take the effort to learn both systems as I have little free time. SO I seek advice which will help me to make a decision and stick with it.

  • I have 30+ years coding experience, am happy with both Windows (for Netduino's C# and .Net, although I have little experience either), and with Linux. I have no fear of new new concepts (in s/w) or programming languages.
  • But I am not very good with h/w, although I can handle serial port comms and an Atmel up board with no o/s (interrupt driven programming)
  • I am well versed in telemetry and SCADA, and am now becoming interested in "the internet of things", and aim to implement sensors/controllers for those.
  • After a few hobby projects, I might attempt a commercial project (so, think of licensing)
  • I need something that can be ruggedized to IP67, but guess that they both can.
  • I am not too concerned about price, probably more about flexibility. I would hate to build up knowledge of one system after 5 to 6 projects and then find that there is something that it cannot do, which the other can.
  • Since I know nothing about h/w, I am concerned about connecting peripherals. Does each peripheral have standard connections, or does it vary. Does one or the other system have more off the shelf" peripherals available?
  • Which can support the most peripherals simultaneously (or does that not make sense, with break out boards, USB, serial bus (MODbus), etc?) Also, CANbus support would be nice, but is not a hard requirement.
  • I do not require the display capabilities of the Raspberry Pi, not will I attach a keyboard. Strictly monitoring and controlling and communicating with a remote PC.
  • which has the wider support base (especially on the s/w side)?
  • while I am happy with Ethernet, I would not like to rule out WiFi or even Zigbee communications
  • Running on very long life battery/solar power might be interesting, but is not a requirement.

I hope that you can see that this is a question that can be answered, and invite counter questions asking me to further explain what I hope to achieve.

\$\endgroup\$
  • 2
    \$\begingroup\$ Unfortunately the application largely dictates what to use, so it is still a guess. Could you update your question with a specific project idea? \$\endgroup\$ – geometrikal Jun 11 '13 at 5:54
  • 1
    \$\begingroup\$ Specifically addressing "which has the wider support base (especially on the s/w side)?" and "Does one or the other system have more off the shelf" peripherals available?": Neither. You will find considerably wider choice in compatible modules for the Arduino than either the RPi or the NetDuino. Also, do not get taken in by the NetDuino's name, the only thing it has in common with the Arduino family is the blatant attempt at leveraging a popular brand name. \$\endgroup\$ – Anindo Ghosh Jun 11 '13 at 8:09
  • 1
    \$\begingroup\$ I would guess the Raspberry Pi, used as a headless server, has slightly better built-in support for WiFi and other "PC" style peripherals. I'm unfamiliar with the Netduino, but if it is comparable to the Arduino, it will be available in a greater variety of physical forms, many of which have larger number of GPIO pins and typical microprocessor data buses (I2C, SPI, etc). The Netduino might be a better starting point if you expect to end up developing custom circuit boards for microprocessor projects. \$\endgroup\$ – RedGrittyBrick Jun 11 '13 at 10:05
  • 1
    \$\begingroup\$ P.S. I wouldn't rule out the Beaglebone Black with a CANBus Cape \$\endgroup\$ – RedGrittyBrick Jun 12 '13 at 9:58
1
\$\begingroup\$

Based on some of your comments (CAN bus, MODBus), I would have to say the best choice between a rPi and a Netduino would have to be neither.

Basically, neither the Raspberry Pi nor the Netduino (I think - it uses a CLR. I don't think they can make that deterministic) can offer deterministic timing. If you're going to talk interesting protocols, you have to be able to offer deterministic timing in order to generate the proper bit-times.

Your other option would be to hang a specialty interface chip off an SPI port (something like a MCP2515 for CAN, I don't know if there are similar devices for modbus), but that would be a lot of work, and unless you already have a in-depth knowledge of how CAN/whatever bus works, would probably be more challenging to debug.

However, as it is, the rPi offers Serial, SPI, and GPIO (and not much of any of them). I'm not immediately familliar with the Netduino, but I would imagine it's similar.
It's also worth noting that there is no kernel GPIO driver for the rPi available as far as I know. As such, talking to the GPIO requires running as root, and twiddling bits at a specific absolute memory address (I think you can do some stuff with /sys/class/gpio, but I haven't experimented with that).


Really, what I think you should do is buy some Atmel or PIC24/dsPIC devices, and play with those. Almost all low-level hardware stuff is pretty much universally done in plain-old C, so that's what you should focus on.

Realistically, while all various microprocessors do have their quirks, they are more similar then they are different, and skills like knowing how to read and understand MCU datasheets are very generalizable.

Things like running on top of Linux (rPi) or the CLR (netduino) are just additional abstraction layers that make it harder to actually understand exactly what the hardware is doing, and being able to tell precisely what the MCU is doing is often essential in understanding how the MCU works/what is going wrong, as well as interfacing with other pieces of hardware.

\$\endgroup\$
5
\$\begingroup\$

You list contains many might/could clauses, so I don't think it can lead you to the one and only board. Maybe for a specific project, but not in general.

In your shoes I would strive to become a master in the configuration (including kernel configuration, startup process etc) of Linuxes. That seems to be what you'll be using. On which board is step two, probably to be decided on a per-project basis, and likely to shift over the years.

It is a bit like asking a really seasoned programmer what he thinks is the best programing language. The less gods will come with their choice of C, Python, Perl, C++, PHP, Lua, C#, Haskell, Ada, Pascal, and a few dozen others. The real master will say:" for this job, give me any imperative language that compiles to native code, because it must be really fast. For this other job, give me any language with decent graphics support and run-time memory management, because speed does not matter that much but my time does". In other words: the language does not matter, at a certain level some are only a few groups, and the languages in each group are almost in interchangeable.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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