Problem: We needed to point a pair of narrow beam directional antennas at each other, one on the ground and one in an aircraft, to maintain a 10Gb radio link.

Solution: Use a pair of NetBurner MOD54415 core modules to track and control the antenna steering platforms.

With the ground station at a fixed known location, the airborne and ground NetBurners are able to roughly figure out how to point to the other using the reported aircraft GPS location which is broadcast over an omni-directional low bandwidth TCP/IP link. The GPS data is used for initial antenna steering and acquisition. Specialized hardware is included in each radio that computes the direction vector of the incoming RF signal. This received RF direction vector is used to optimize the antenna pointing.

The omni-directional low bandwidth TCP/IP link is used only when the ground and aircraft need to get gross positional data about the aircraft to establish or reestablish the high bandwidth directional link. Once the directional antennas are pointing at each other they will track and maintain a link and the omni-directional low bandwidth link is disabled.

When presented with updated tracking information, each NetBurner computes a new antenna pointing vector. Any difference or error between the current pointing vector and the newly desired one is fed into a P-I-D control loop. The PID (or proportional-integral-derivative) loop filter performs 3 operations on the error. The P-term scales it, the I-term integrates or smooths it and the D-term determines the sensitivity to changes or derivative. The 3 constants are applied to the error data, E, for each steering axis:

In our case, a pointing vector consists of two axes (roll/pitch in the air and pan/tilt on the ground). The resulting commanded vector is then sent to the motor controller. In our implementation, the motor controller consists of some math in the main task and two timer-based interrupts in the NetBurner.

We have two stepper motors to steer our platform, one per axis. These motors are instrumented with shaft encoders to provide position feedback of their current pointing vector. Each motor is powered by an external motor driver that is controlled by the MOD54415 via 2 GPIO (General Purpose Input Output) pins; one a level for direction and the other a pulse to move one step.

Three system timers are created. The first operating at 25 Hz (40 ms) is the system synchronization tick. The other two control the motion axes via interrupts as mentioned above. On each 40 ms sync tick the NetBurner computes the desired pointing vector from the most recent tracking data. After computing the pointing error and applying the PID filter, the required number of motor steps to move per axis is determined. The number of motor steps to move equals the number of GPIO pulses to be sent to the motors during the next 40 ms interval. The NetBurner then configures the two motion axes timers to evenly spread interrupts (and their resulting pulses) out over the following 40 ms interval. This creates a pipeline where the next set of pulses is computed while the previous is sent to the motors.

In addition to performing all of these tasks, the NetBurner is also burdened with serving up status and control panel web pages, data logging and periodic UDP reporting. Take a look at the high level diagram below to see how things came together.

Outcome: We were impressed with how well the MOD54415 performed all of these real time tasks.

For many networked consumer products, a Raspberry Pi is a popular option. However for timing critical or harsh environments such as ours the NetBurner module is a better choice. NetBurner supports all standard Internet protocols and features running on top of a real-time preemptive operating system - unlike the non-deterministic Pi. Add to this an industrial temperature rating which was important in this airborne application.

Our NetBurner-based aircraft platform control system soared through chilling temperatures while performing motion and tracking control high over the rain soaked forests of northern Washington State. Testing was done with a twin engine Cessna. This project integrated several 3rd party modules and featured the NetBurner MOD54415 embedded ethernet core module.

About OBE:OBE Systems, Inc. is a small engineering design firm that has been around since 1991. Our emphasis is Embedded Systems design and we have developed products for the medical, consumer, industrial, telecom, and aerospace marketplaces. As NetBurner Approved Consultants and experienced Raspberry Pi developers, we can help architect the right solution for your IoT or networked device.

Having your network die is like a warhorse laying down just as you prepare to storm into battle -- sword drawn. Let’s sort this dire situation out like a warrior. The very first step is to figure out what died. Here’s a handy block flow diagram to get you through this. The subsequent sections will address some of the less obvious blocks in the diagram.

Out of Buffers

The entire network stack works by passing around pre-allocated buffers. This is a limited resource and misbehaving code can use them up. To test the buffer, add the following debugging code which will repost the buffer free count. This can be added in a number of different areas of code, depending on the structure of the application. One possible solution is to put it inside the infinite loop in UserMain(), and use a timer to have it called every so often.

Now run this and carefully watch the messages. If this number is decreasing every time the module reports it and the system stops responding when it goes to zero…. DING! This is your issue.

Why buffers might go to zero

The primary cause of buffer loss (filling buffers from the available pool and failing to release them) is mishandled UDP sockets or UDP registered FIFO’s. If you set up a UDP socket to receive, or if you use the UDP object class and register a FIFO to receive UDP packets, then you must read them. If you’re not reading them, then unread UDP packets will accumulate in the UDP receive queue until you have run out of buffers. Alternately, you can also exhaust all buffers by creating a UDP transmit loop that does not wait until the packet has completely gone out on the wire before creating another packet.

A secondary, less common buffer loss is due to trying to do I/O within a user written interrupt routine. There are several things that you may not do from within an interrupt routine. Calling any of the functions listed below inside of an interrupt routine can get you into some misery:

As you can see from the list above, trying to use any sort of I/O functions can cause a lot of headaches. One of the possible failures from doing this is to interfere with the buffer handling queues, which will prevent used buffers from getting released.

From time to time, we have also found internal NetBurner bugs that lost packets on strange corner-cases. And because of our upcoming beta releases of the new WiFi and SSL drivers, it’s possible you found a path to lose buffers we did not find. If this is the case, thank you! Also, please report it to support@netburner.com.

Is the Network Address and mask correct?

The system can get network addresses with DHCP or it can use static settings. A full network address consists of four things:

IP Address

Network Mask

Gateway address (only needed if you are routing to addresses off the local network)

DNS address (only needed if you are addressing things with names, i.e. www.NetBurner.com instead of 34.199.141.96)

Here’s an abridged version: The bit operation “AND” of the IP Address and the Network Mask must equal the bit operation “AND” of the Gateway address and the Network Mask. In other words:

(ip & mask) == (gateway & mask) // This must be true

Otherwise, the gateway is not on the local network. DNS must have a valid value.

Look at Tasks

The previous article in this series gave you a way to look at what tasks are doing using the TaskScan utility. Unfortunately, if you have a user created high-priority task that never yields or blocks the network, that method is not going to work. If you end up in this block of the flow diagram, you’ll want to create a dump of the TaskScan or textual task dump results , open a NetBurner support ticket with the details of what’s happening, and we will be happy to help you figure out what’s going on.

The Webserver Dies

Occasionally, the webserver running on your NetBurner may hit a bump in the road and get locked up. While it’s not quite as troubling as having your warhorse laying down on your right before a fight, it is a lot like showing up to the battlefield and realizing you left your sword with your other suit of armor. The chart below walks you through debugging the most common pitfalls encountered when this beast rears its ugly head.

Web server dies

Web server dies

No

No

Yes

Yes

Has HTTP task died in a user function?

Has HTTP task died in a user function?

Run TaskScan

Run TaskScan

No

No

Yes

Yes

Has HTTP task died in a user function?

Has HTTP task died in a user function?

Yes

Yes

No

No

Has HTTP task died in a user function?

Has HTTP task died in a user function?

If your user function clocks it stops all HTTP processing until complete.

[Not supported by viewer]

Figure out where it's stuck and why. Ask for help on NetBurner Support

Figure out where it's stuck and why. Ask for help on NetBurner Support

The most interesting value is the “State”. The NetBurner system by default has 32 sockets. If all 32 sockets have been listed in this report, you are out of TCP sockets and need to figure out why the system is out of sockets. Again, if you get to this point and nothing is obvious, include this data and contact NetBurner support and we will help you dig deeper.

Your outbound TCP connection dies

Ok, we’re running out of medieval warfare metaphors here! Needless to say, having your TCP connection fail on you can be extremely frustrating. Not only will it impact your application, but several of the NetBurner tools rely on TCP network communication, and being stripped of those can often make you feel vulnerable and alone… kind of like showing up to battle with no horse, armor or sword (looks like we found one after all). The chart below takes you through the steps needed to address the most common causes for TCP connection failure to help you pinpoint exactly what’s going on.

Outbound TCP connection/web client diagnosis

Outbound TCP connection/web client diagnosis

Name

Name

IP

IP

Are you using a name (DNS) or IP address?

Are you using a name (DNS) or IP address?

No

No

Yes

Yes

Did it work then die?

Did it work then die?

Yes

Yes

No

No

Is IP on the local network?

Is IP on the local network?

No

No

Yes

Yes

Is DNS resolving to an address?

Is DNS resolving to an address?

Try rerunning DNS resolution as dynamic servers can move.

Try rerunning DNS resolution as dynamic servers can move.

Yes

Yes

No

No

Is the connect call returning an error?

Is the connect call returning an error?

Yes

Yes

No

No

Does NB have a DNS address & Gateway?

Does NB have a DNS address & Gateway?

Yes

Yes

No

No

Does the NB have a Gateway on the local network?

Does the NB have a Gateway on the local network?

No

No

Yes

Yes

Is it TCP_ERR_NONE_AVIAL (-5)?

Is it TCP_ERR_NONE_AVIAL (-5)?

No

No

Yes

Yes

Is this a TCP connection that remains open?

Is this a TCP connection that remains open?

Contact NB support and get a wireshark capture of the error.

[Not supported by viewer]

Read notes on TCP keep alive and continuously connected sockets

Read notes on TCP keep alive and continuously connected sockets

Yes

Yes

No

No

Can you PC resolve the NAME?

Can you PC resolve the NAME?

Try a different DNS server or capture a wireshark of the failure and contact NB support

[Not supported by viewer]

Name is bad.

Name is bad.

Fix DHCP server or network config

Fix DHCP server or network config

Yes

Yes

No

No

Is it TCP_ERR_CON_RESET (-6)?

Is it TCP_ERR_CON_RESET (-6)?

Look at the TCP socket loss reports.

Look at the TCP socket loss reports.

No

No

Yes

Yes<br>

Did you specify the local port in your connection call?

[Not supported by viewer]

If your sure the server you are trying to connect to is ip, contact NB support with the error code.

Notes about TCP keep alive.

By design a TCP connection does not send anything over the wire if there is nothing to be sent. What this means is if you have a TCP connection to a remote device and the power goes off, the cable gets unplugged or the building is overrun by the Night King and the army of the dead, the TCP connection will have no way of knowing the other side of the connection is dead, unless it tries to send data.

There are two ways to see if a socket is dead:

Send it some data.

Send it a keepalive request: The details of the keepalive are spelled out and working code is given as an example in nburn/examples/standardstack/tcp/TCP_simple_keepalive. Here’s a quick code snippet...

#include
//Find out the last time we received any kind of packet from the other side of the connection.
DWORD TcpGetLastRxTime( int fd );//Returns the number of TimeTicks since the last RX
//Send a keep alive the other side should respond.
void TcpSendKeepAlive ( int fd );

One could write many volumes on how to debug Network issues. This article is necessarily brief.

Further Support

If you are having network issues the best path forward is to go down these flow charts until you get confused or the results are unclear. Then open a support request with as much information as possible about what is wrong, including the steps of what you have done to debug this yourself. As part of your support request please include as a minimum:

What is connected to what.

Did it ever work?

How long it ran before it died.

And as much of the diagnostic flow as you have accomplished.

As always if there is something you’d like us to expand upon or have questions about please feel free to comment below or contact us directly. We hope this has hardened your skills as you fight the good fight. From one embedded warrior to another -- Tallyho! And remember:

“Warriors do not win victories by beating their heads against walls, but by overtaking the walls. Warriors jump over walls; they don't demolish .hem” --- The Teachings of Don Juan, Carlos Castaneda

In my previous articles, I described how every character on the planet is being assigned a code point by the Unicode Consortium. Yes, that’s right, every symbol for every letter on the planet is getting a code point that looks like U+0639 where U means Unicode and 0639 is a hexadecimal identifier for the letter. Don’t make the assumption that the code points are limited to 16 bits or 65,536 code points. That code point value is unlimited.

That’s the next point. This has nothing to do with any kind of computer memory storage. It’s just a value. A Unicode value says nothing about how to store this in memory or how to send it in an email. Encodings do that.

There are many different encodings that specify how to store a code point in memory. UTF-8 (Unicode Transformation Format 8) is the most popular in North America. UTF-8 resembles the standard way of storing ASCII data that we’ve used forever with the nice property that zero is a string terminator. If your strings are all standard ASCII data, you don’t have to change a thing – you are using UTF-8 by default.

But there are other encodings: UTF-16, which uses 16-bits, or the UCS-2 standard, which uses 2 bytes (yes, it’s still different than the 16-bit UTF-16). There’s something called UTF-7 where the high bit is always zero for those systems that use the high bit for some other purpose. And there are probably others that I haven’t run across. The point here is that you can’t transmit a string or process an incoming string unless you know its encoding. That’s why you will occasionally see an email message or some other string that contains a long series of question marks. That usually means that the programmer didn’t bother to detect the encoding designation and interpret the string properly.

In an email there is an indicator of the form: Content-Type: text/plain; charset= “UTF-8″ in the header of the email that explains to the receiver how to decode it. When a programmer ignores that kind of information, “???????????????” is what you’ll see.

For websites, it gets a little trickier. One method is for each web page to specify an HTML tag that identifies the encoding, but that’s not often used. What actually happens is the browser makes its best guess. It has some heuristics about how often certain letters appear in a certain language and it makes its best guess as to what symbols to display for each code point. It works more often than not.

And that, my friends, concludes my three-part series on ASCII encoding. I hope the next time you are working with ASCII strings, you’ll make sure to communicate what encoding you’re using and use the proper encodings to decode strings you receive. If you are looking for a device to move ASCII data in and out of a PLC, please visit our website – you’ll find out why we at RTA are known as the ASCII guys.

ABOUT THE AUTHOR

John Rinaldi is owner and CEO of Real Time Automation (RTA) in Pewaukee, WI. Rinaldi founded Real Time Automation in 1989, a company dedicated to making industrial networking simple. With a focus on simplicity, US support, fast service, expert consulting and tailoring for specific customer applications, RTA has become a leading supplier of networking technology worldwide.

RTA is focused on moving your data. Rinaldi is not only a recognized expert in industrial networks and an automation strategist, but a speaker, blogger, author of more than 30 articles on industrial networking and author of four books.

Control Engineers, system integrators and distributors use Real Time Automation products to move data around the factory floor. ASCII products are used for moving barcode, while scale and RF data are only one segment of a large product portfolio. Learn more about RTA by signing up for our unique industry newsletter and follow RTA on LinkedIn. Contact Rinaldi on LinkedIn here.

Search Google and you’ll find gobs of articles comparing Arduino vs Raspberry Pi. These platforms have experienced fantastic growth since their beginnings as low-cost learning platforms for students, makers, aspiring hackers and entrepreneurs. Due to their general utility and popularity they have started to show up outside the education and hobby settings and have become more common in laboratory, commercial and industrial applications.

Today we’re going to lay these two IoT development platforms on roughly opposite sides of the proverbial IoT Spectrum, and show how our NetBurner Embedded Core Module Dev Kits fit neatly in between. Please understand that we need to generalize, there are many other platforms out there, there is no one-size-fits-all solution, and an appropriate selection really depends on your goals and constraints. We hope you will find that NetBurner has a powerful yet balanced fusion of capabilities across the spectrum, but with advantages in terms of support, optimization for IoT, reliability, tools, product scalability and, yes, it’s also great for prototyping.

NetBurner Background

NetBurner was founded in 1998 to make network enabling hardware easy and reliable. Our mission has been to support and accelerate our customers’ product development by providing superior-quality embedded TCP/IP stack hardware and software tools to network or web enable almost any sensor or device. Our dev kits and core modules are specifically designed to speed up the entire development process and rapidly integrate into your application or product design. We strive to provide reliable products, support and tools that derisk and accelerate our customers’ development path.

All of our NetBurner Embedded Core Modules and Serial to Ethernet Modules can be purchased as Development Kits (dev kits) and used for prototyping, tinkering, or education just like the Arduino and Pi. However, our true value shines as a scalable, optimized, industrial-quality control and processing module that provides embedded product engineers, industrial designers and web app developers not just peace of mind for serious IoT or M2M (machine to machine) applications, but the software, tools and support that is essential for any project’s success. Our dev kits include an industrial grade NetBurner Core Module which is literally snapped into a super-handy dev board. Once you’re done with your prototyping you can literally pull the core module right off the dev kit headers and use it for your first production quality product if you please. No abstractions there!

Platform Overview

If you’re short on time here’s a high-level platform comparison. The rest of the article will go into more detail on capabilities, trade-offs, and applications.

NetBurner offers an IoT optimized hybrid of capabilities between Arduino and Raspberry Pi that scales well to production. Like Arduino, it is highly effective at reading and responding to I/O including serial, analog, and digital data. It also provides a substantial CPU capable of multitasking and processing much larger datasets, algorithms, and applications than the Arduino, but is not as hefty as the Pi with its faster CPU and larger memory. One noteworthy difference that should be acknowledged right off the bat is NetBurner’s Real Time Operating System (RTOS) which has been highly optimized over the course of the past 20 years. In addition to its benefits regarding timing critical control of hardware, comparable operations (such as running a web server) are often faster using NetBurner products than a Raspberry Pi counterpart, despite their beefier processor.

TL;DR

In order to do a deeper comparison, it’s useful to first cover the baseline platforms a bit more -- the Arduino (a microcontroller board) and Raspberry Pi (which is a System On a Chip or a Single Board Computer). We’ll then maneuver the NetBurner into the airspace. What you will find is that NetBurner captures many of the most useful capabilities from both sides of the spectrum with some strong differentiators as well.

Figure: Arduino ↔ NetBurner ↔ RaspberryPi

Arduino

We’re going to focus on the classic Arduino like the Uno, Mega, and Nano for this article. Arduino is a lean and mean development board that can get a lot done. It packages an Atmel 8-bit ATmega328 microcontroller with a 5V regulator, a timer, a serial communication interface, LEDs, a barrel jack, analog and digital I/O, and some headers. It has a scant amount of memory and has a handy USB port to easily load small programs from your PC, though it should be noted USB doesn’t work bidirectionally. The Arduino allows you to quickly breadboard a working prototype and in general, they are fantastically simple and robust devices.

Arduino comes with a nofrills IDE compiler that runs a stripped down C++ type syntax to provide logic and sequencing as needed. Don’t look for an operating system or multitasking here…it runs firmware which usually supports just a single program loop and has very limited processing and memory.

Figure: Arduino Uno

Best Use: These puppies are best applied to simple hardware interface applications. They usually run in a “headless” configuration - meaning they don’t use standard human-computer interfaces during normal operation such as a monitor, keyboard, or mouse. They run near-instantly upon power-up and handle a hard shutdown without any detriment or memory corruption issues making them great for situations with intermittent power. They are ideal for reading sensor data, switch and encoder inputs and responding to signals by controlling and actuating servos, motors, pumps, solenoids, cueing devices, and outputting to simple displays and indicators. Low power requirements make use with alkaline battery packs feasible too. They are a great fit for hobby gizmos, basic process controls and automations! You can even interface them with other computers like a NetBurner Core Module or Raspberry Pi.

Food for Thought: A large drawback is that they don’t come with any native networking capabilities. You can buy addon ethernet shields or purchase the newer Arduino Yun Linux OS boards, but they can be costly and frustrating to implement and achieve reliable, secure network connections. Sometimes makers find this process of connecting Arduinos quite irritating and time consuming. They can be connected to a NetBurner or Raspberry Pi to get networking as well. Also be advised that adding networking will increase power consumption considerably.

Scalability: Scalability issues with Arduino may primarily arise with being locked into Arduino’s constrained programming language and core firmware. This limits the design space and makes it a bit more difficult to transition and integrate this microcontroller to some systems. If you want to strip out and work with the Atmel microcontroller chips alone you can do this. Arduino even let’s you use the firmware, source code, and libraries as long as one abides by their licence terms and conditions. Things get messier if you need secure networking capabilities. Transitioning Arduino to use this feature for your products will increase the challenge.

Support: Arduino doesn’t provide direct application support or troubleshooting. Your best place to go is to the official Arduino forum or one of the myriad blogs and websites that host articles, tutorials and large communities of users. While sufficient for hobbyists and makers, Arduino’s indirect, community-based support can be risky when on a product development program.

Raspberry Pi

On the opposite end of the IoT Spectrum lies the hugely popular Raspberry Pi. Not a simple microcontroller, the Pi in all of its variants is an honest to goodness full-featured single-board computer. It uses a System on a Chip (SOC) architecture with a fast microprocessor capable of multitasking complex software applications. Raspberry Pis have powerful integrated microcontrollers, but they are just a piece of the “pi” so to speak! The latest Pi Model 3 B+ has a 64-bit Broadcom Cortex-A53 quad-core 1.4GHz CPU SOC. They also have substantial allocations of RAM, removable MicroSD, EEPROM, flash memory, interface hardware like HDMI, USB, WiFi, bluetooth, graphics processing units (GPU), math coprocessors, and other peripherals all printed in a single integrated circuit! There is even some General Purpose I/O (GPIO) and counter-timers that can be used with external hardware.

Figure: Raspberry Pi 3

The Pi comes out of the box with a distribution of the Linux OS and for a fraction of the price of some people’s weekly coffee budget you’re computing! Except, you’ll still need a monitor, keyboard, and mouse as this is typically not used as a headless platform. A noob can quickly get setup with an internet connection and download a selection of familiar apps to watch movies in HD, surf the internet, serve files or websites, play music and games, and record and edit video. It can also support most advanced programming languages. You name it and there are the same capabilities as any basic PC but at a low cost. The Pi is a nice general purpose computer for tech enthusiasts, gamers, hackers, scientists, students, bloggers, and just about anyone with the desire to geekify their lives some more. The community of users is massive which bodes well for DIY tutorials and peer support.

Best Use: In a purely IoT context, Pi with it’s low size, weight, cost and computing power has value as a Linux host that is very capable of multitasking, serving files, and communicating with other networked computers and cloud platforms. It’s great for running software apps rather than reading, responding and controlling hardware and distributed IoT. There are loads of maker projects like 3D printers, blockchain networks, and more sophisticated robotics and AI that can be done with Pis as well but, typically they are best suited for low volume and small scale projects.

Food for Thought: In hardware oriented IoT, IIoT (Industrial IoT) and automation applications, a considerable downside is that Pi is not as capable for real-time measurement and control of distributed IoT nodes and devices. It uses round-robin scheduling, which means you can’t guarantee how and when tasks are run. Furthermore, there is no real-time clock which is essential for real-time applications. Lacking a real-time clock and an RTOS can mean less reliability and accuracy for metrology, process automation, manufacturing automation, high speed sensing, and other timing-critical feedback applications. This makes timing and correlating events and data very dodgy. Both Arduino and NetBurner perform better in these situations.

Another Pi drawback is that startup can be lengthy and power interrupts can actually corrupt system memory. Safe and rapid handling of power interrupts and startups provides a more stable, maintainable, and predictable network -- this is often a required capability in the IoT and IIoT industry. For industrial applications, the Pi also lacks the industrial operating temperature range.

Accessing I/O on a Pi is a bit trickier than Arduino or NetBurner as well. It uses GPIO as it’s form of I/O and does not have Analog to Digital Converters (ADCs). This means that many analog devices like sensors won’t work without additional circuit design or 3rd party ADC products. The Arduino and NetBurner really make reading analog and digital data and controlling hardware pretty simple out of the box. Additionally, with Pi it can be trickier to write I/O read and respond software that also works within the constraints of the OS due to the timing issues referenced earlier. These weaknesses make it less desirable for service as an IoT node or controller performing simple tasks like reading and responding to sensor data.

Scalability: Pi can sometimes seem like 10 pounds of tech in a 1 pound bag. As a general purpose processor or server and in small deployed quantities it’s hard to beat the Pi’s cost, versatility and value. However, its Linux OS and processor are often overkill; leading to higher latencies and power requirements than might be necessary.

To further complicate issues, Linux is somewhat prone to security vulnerabilities due to its popularity as a server OS and therefore, it needs continual patches to fix them. However, each patch is not limited to just security, as other elements can be modified as well. For security reasons, the the patches are not optional. The problem here is that the user must now regression test everything each time a patch comes out. This adds considerable risk and maintenance to the use case, not to mention that for large distributed networks of Pis you’d have a non-trivial logistical challenge. Don’t get us wrong, we love Linux, but for scaling up IoT and IIoT, it has some serious challenges.

In volume sales the Raspberry Pi is usually not optimal and doesn’t scale as well as some other options. One scalability issue is more in terms of risk and availability when sourcing components. The Pi is often oversold and underproduced, emphasizing the considerable risk in acquiring these units as needed. This risk stacks on top of many other issues that we described, making the Pi a tricky fit for mass market or commercial and industrial applications.

Support: The Pi uses Linux, so there is definitive authority or support available for when you have issues that might point to the OS. Like Arduino, Pi doesn’t provide direct application support or troubleshooting. Your best places to go, but not always most reliable, are to the Raspberry Pi Help web page or one of many blogs and websites that host articles, tutorials and large communities of users. Like Arduino, Pi’s indirect/passive and community-based support can be risky when on a product development program.

NetBurner products cover a broad swath of the IoT Spectrum and are a formidable hybrid between Arduino and Raspberry Pi. NetBurner is akin to Arduino in terms of ease, reliability, and accurate timing for analog, digital I/O and hardware applications. They are also great for fast startup and robustness during power failures.

Conversely, in terms of design space, processing power, multitasking, networking and server capabilities, it is much closer to the Pi. NetBurner, like Pi, also uses a SOC. Our modules use either a Microchip ARM Cortex processor (releasing this year) or a NPX Freescale Coldfire processor (like the MOD5441X, our current flagship core module). A significant differentiator is that NetBurner has a real-time clock and a highly optimized Real Time Operating System (RTOS) unique to our products. Real time deterministic performance makes NetBurner highly capable of timing, sequencing and coordinating hardware, data, tasks and processes.

While developers are free to choose a C++ compatible IDE of their choice when building apps for their NetBurner modules, to make the development process as smooth and easy as possible NetBurner provides a fully featured Eclipse based IDE. It allows for the creation and configuring of projects, deploying them to a device, and supports a full set of debugging features. In addition, a full suite of tools is supplied with dev kits that provides everything from a serial terminal, to a lightweight FTP server, to virtual com port software, and everything in between.

Best Use: NetBurner’s native networking and real-time embedded CPUs let you process complex algorithms, securely serve websites and files, and respond to server requests (HTTP/S and websockets being two common modalities). This makes it great for applications where a secure and rugged IoT interface and networking solution is desired. NetBurner has native networking, serial I/O, digital I/O, analog I/O, signal converters, embedded processing and readily supports SD cards, USB 2.0 (in beta) and 802.11 b/g/n WiFi (with our easy addon modules). SSL/TLS can also be enabled for all data transfers. Users really love how easy it is to securely network enable serial, digital and analog devices, and handle a variety of M2M, IoT, and industrial protocols.

Food for Thought: NetBurner’s RTOS is specifically designed to minimize overhead for IoT and networking apps, thus reducing latencies and power consumption compared to the Pi. The use of an RTOS has another critical benefit --- startup is really fast and can our devices can undergo a hard shutdown without corrupting memory.

Just like Goldilocks, NetBurner offers a “not too hot, not too cold” solution with most of the capabilities we are sizing up on the IoT Spectrum. If you need super low-power, super simple I/O without secure networking capabilities or almost no processing power, Arduino can be a cheaper, more suitable choice. Or, if what you need is a quad-core multithreaded CPU or loads of video processing power, then the Pi is likely a better fit. However, if you are searching for a performance optimized embedded system that requires secure networking capability as well as easy and direct access to the hardware itself, NetBurner can scratch that itch.

Scalability: The NetBurner RTOS is also intentionally geared to work well for embedded engineers and web developers who need to make scalable, robust commercial and industrial apps and with ease. Our indistrial temperature range and support for a variety of Industrial Automation Protocols also makes scale up easier.

Our dev boards facilitate rapid prototyping easily by exposing serial ports, I/O pins, providing a power jack and other peripherals. They also make writing software and testing much easier. The fact that you can remove the core module from a dev board and use it just as you would in production is a real benefit to many of our users and can significantly reduce project risk.

For many projects, space is a big constraint and trying to use a plug-in module is just not an option. For those packaging requirements, we also sell individual boot chips, so that customers can build them directly into their own hardware. In the same spirit, for customers who want complete control, NetBurner offers licensing that includes rights to the hardware design (full schematic and layout files are provided), TCP/IP Stack, Web Server, RTOS, Debug Monitor, and end user utilities.

NetBurner’s production hardware are controlled assemblies. This means that our goal is to never have a hardware change so customers have the security of getting the same high quality product every time. Should a hardware change be necessary, our customers are informed ahead of time.

Because our devices are manufactured locally, we are able to give accurate lead times for large orders and more carefully monitor the manufacturing and quality processes. And because we like you so much, orders for our modules are subject to quantity discounts. NetBurner has a warranty that it stands by, and is constantly working with its customer base to improve both the product and its support. Speaking of...

Support: One of the things that NetBurner stands by is the quality of our direct customer and application support. That’s how we’ve rolled for the last 20 years in the biz. Unlike Arduino or Pi, we offer highly responsive direct email support (support@netburner.com) and have a great support portal as well. When you ask for support, you’ll be dealing right off the bat with skilled NetBurner engineers, rather than getting progressively escalated through a corporate call center. We are extremely proud of our community and the things they’ve been able to accomplish, and our support engineers also participate and interact with them through our forums on a daily basis.

As a team that is always striving to promote creativity and development, we take a lot of joy in writing our Learn Blog, and providing free software and tools, documentation (including over 100 code examples demonstrating everything from AES to WiFi), and resources. Your success is our success. It's like you’re Rocky and we’re Micky right behind you in the corner… except we’re not going to die on you!

Recommendations:

As you can see, there is no one size fits all platform, and we had to exclude many other IoT products from the article for the sake of “brevity”.

That said, you should consider the Arduino route for ease of use in simple hardware read and respond applications that are not time or performance sensitive. The boards are usually low cost for non-network applications. Once you start adding the shields for additional functionality such as networking, the cost starts to go up and it is not appropriate for industrial applications. The Arduino can be considered for simple applications that do not require an operating system, can run in a single task, and do not require real time performance. Given the low power requirements and upkeep of Arduino devices, they’re also a good choice if your project will continuously run, be battery powered, and require little to no maintenance or human interaction.

You should run with the NetBurner if you need to securely connect and accurately read and control analog, digital or serial devices to a network or the web and access via a browser-based UI. It’s really great for applications where the main task involves reading sensor data and changing values on motors, actuators or other devices and where operations require little to no maintenance or human interaction. It is also useful if you also need to run complex code and data processing or require real-time deterministic performance and multitasking. NetBurner is especially recommended if you intend to scale up or have an industrial or commercial application. NetBurner is a complete solution for hardware, software, development tools and direct OEM support. If that’s important to you, then NetBurner again has a significant edge.

You should go with a Raspberry Pi board if your project involves a task you would otherwise accomplish on a conventional personal computer or single-board computer. The Pi makes it easy to add interfaces such as a keyboard and display. It has the ability to handle multimedia applications, and by default has a full featured file system. It nicely suited as a file server, database server, VPN host, or for running applications that require multithreaded processing. It is important to keep in mind that it does NOT provide real-time deterministic performance or industrial temperature ratings.