Showing posts with label mipi. Show all posts
Showing posts with label mipi. Show all posts

Monday, May 28, 2018

Of FPGAs and Arduino: The MKR Vidor 4000 Leads Me to Big Questions


There will be a point-form 'tl;dr' summary at the bottom.

Arduino & Gumstix


I recently invested a substantial amount of time working on board support for Arduino-compatible devices. Geppetto now has several microcontrollers that can be found on Arduino-compatible boards, and I extended Geppetto's AutoBSP service to include ArduinoIDE integration. Once you've got a board design and click on the BSP button, you not only get the hardware abstraction layer (HAL) source files, but a link you can add to your IDE that adds your design's BSP to the Boards Manager under "Contributed."

Quite clever if you ask me.

It's time to point out that Geppetto is an electronic hardware design-to-order tool. In one end goes your modular, drag-and-dropped device design and an engineering fee, and your fabricated, tested, ready to rock development board comes out the other. the engineering fee makes Geppetto unideal for one-of maker boards, but for prototypes, proof of concept, and low volume boards, it's a short road to production.

Exciting Arduino News

The Arduino community just announced some new development boards. One of these boards includes a field-programmable gate array (FPGA), which gets my blood pumping.

I worked a lot with FPGAs when I was in university and my Master's thesis involved the development of an interactive logic design training tool. It was in the form of an embedded system incorporating an Altera (Intel) Cyclone V SoC, and targeted pre-university to undergraduate students, helping them learn hardware description languages, such as VHDL and verilog, as well as software languages, like C and Java.

Hardware description languages (HDLs) are used to define the behaviour of the look-up tables and registers to form digital design based on logic gates (AND, OR, eXclusiveOR, NOT, etc…), memory blocks and digital signal processors that make up FPGAs.

Working with FPGAs is an oddly rewarding experience. At first blush writing hardware description language seems insurmountable. But once you've written your first half-adder and seen those 7-segment LEDs spit out the correct answer, you're hooked. Or at least I was.

The potential for FPGAs in the modern computing era is widespread. From fine-grained parallelism to high speed signal processing to software-defined radios. My favorite area of development is adding ASIPs (Application Specific Instruction Processors) to existing SoC architectures.

I wanted to share that feeling with others and worked hard to find ways of presenting the learning material in an interactive, progressive and causal learning environment. An Arduino FPGA board might be a step in that direction. But it depends on how it’s presented and, most importantly, how it’s used.

So what do these FPGAs really have to offer the Arduinosphere?
 

"Getting Started..."

The announcement of the Arduino MKR Vidor 4000 has been met with much fanfare, including my own, but to validate the board's existence, we have to start by going back to the original purpose of Arduino.

Bare wire programming is hard. Real-time operating system RTOS programming is hard. Let's face it: starting out with MCUs is not easy. Back when Arduino started releasing hardware, it was to put these incredibly useful and traditionally complicated marvels in the hands of artists and enthusiasts who would otherwise not have the technological know-how or courage to attempt embedded software development.

The endless jungle of examples, snippets, libraries and forums serve up a steady stream of cut-and-pasteable functions into an IDE designed for simplicity. It is plausible that a user could go a long time without even adding a semicolon and still be able to produce the results they’re looking for.

So the service that Arduino provides access to programming Hardware without actually having to know how to program instead of coaching these creative individuals in the fundamentals of developing embedded systems. It's easy to stop there, using the simplified programming environment, embedded example applications, one-button compilation and uploading, and large and supportive community to design and maintain interactive art, fun robots, and endless maker projects, without digging into embedded software development. These creative individuals have a gateway into field which normally requires a skill set and knowledge base that is completely alien to them.

Asking an artist or a carpenter to learn the core skills involved in writing bare-wire microcontroller code, or even RTOS procedures, is much like asking a first-time skydiver, long-time airline passenger, to jump out of a plane. Fear and anxiety are not uncommon reactions. “I’m perfectly comfortable being in the air as long as there’s a cabin around me and wings on either side,” they say. Because the Arduino community fosters this copy-and-paste “non-programming” environment, you find a lot of passengers in its midst.

It’s a trade-off. You get more people doing amazing things with MCUs but don’t explain what it is they’re really doing.
 

Industry and Arduino

Part of my responsibility as gadget guru at Gumstix is to keep an eye on what people do with embedded devices, IoT, development boards, and technology. I also consider myself a bit of a developer advocate, despite my extended periods of silence. This is partly to do with my involvement in backend Geppetto development and a few marketing responsibilities. I've got my hands full, to say the least. Regardless, I've noticed that Arduino is popping up in some strange places in industry.

So what role does Arduino play in industrial applications? Let's start with your bill of materials. The popularity of a given part will drive its availability. The more ATMEGAs get purchased, the more of them Microchip will make. That means adding a chip found on a popular Arduino board to your BOM means it probably won't cause many problems in your supply chain.

Now that you've got a well-documented MCU on your board, you need to start developing your application. You start collecting TRMs and white papers and quickly realize that you've done an awful lot of reading and very little programming. So why not make things easy and write some proof-of-concept code in Arduino, show the boss that the board works and press on.

Most professional embedded software developers and engineers will agree that Arduino should not be running on any product. At some point, the prototype's firmware should be rewritten in code that can be properly validated, tested and verified. Static analysis tools, unit tests, stress tests, and hardware-level debugging, among others, should be used before any embedded system leaves the lab to go to production and distribution.

To me this is an acceptable workflow. Use an Arduino sketch for proof of concept, then take the time to develop in a less abstracted language that can undergo formal verification and quality assurance. As long as end-user products arrive with stable, verified and secure code, the initial development cycle is trivial.

So the purpose of Arduino software and hardware in industry is as a breadboard to get your initial design rolling fast, to be abandoned early in the development cycle.
 

Obfuscation

As I alluded to earlier, Arduino acts as an abstraction layer between the user and the hardware's abstraction layer (WARNING, this is an abstraction of an abstraction: BAD NEWS). It simplifies the depth of interaction required to get some thing to do something. It obfuscates the complexity of the system, shrouding it in simplified libraries, well-commented 20-line examples, and hidden build processes. It encourages "printf debugging" and trial-by-fire programming, which is fine. At first.

At some point, Arduino will become more hindrance than help. It's horrible at power consumption optimization, is wasteful with memory, and has little to no consideration for security or stability. Those looking to carry on will need to invest the time to understand the minutiae of MCU firmware, RTOS platforms and engineering problem solving strategies.

Here we meet that intimidation barrier. Some might say "Hey, I can do what I want to do without learning C or assembly code, reviewing reference manuals, or penetrating the hardware abstraction layer. I'll just stay here, where I'm comfortable and hope for the best." This is the airline passenger strapped in tight, gripping his bag of peanuts and complimentary orange juice.

And now on to the main event:

Arduino and FPGAs

The Vidor looks fantastic, and I hope to get my hands on one soon. But what is it really, in the end?
  • It's a SAMD21 microcontroller board following the MKR board design
  • It includes a U-BLOX WiFi/BLE module
  • It has some pretty advanced features
    • MIPI camera interface: Looks like it's for a Raspberry Pi camera
    • HDMI connector
    • PCIe edge connector
  • and last but not least, an Altera Cyclone 10 FPGA (YAY!)
There's more, but those are the highlights.

I love it! I want one!

Here's what I know about working with Altera Cyclone FPGAs. The bitstream and toolchain are closed-source. You have to use Altera's Quartus II IDE or CLI to properly flash it. It has many application-specific custom logic elements, as do Xilinx's chips, so even program modules are rarely portable between manufacturers. Also, if you thought MCU development was hard, wait till you try FPGAs!

So how is Arduino presenting this new hardware to its primarily "beginner-to-amateur" audience? Apparently, not as an FPGA. You use pre-compiled IP (Intellectual Property) blocks from within the “Arduino Create” online IDE, which are then incorporated into your compiled sketch and flashed to the FPGA by the SAMD21 MCU. It Compliments what you could currently do with an Arduino board by providing ready-to-use functionalities from the FPGA. For example, HDMI video output. You could display a sequence of images rendered by your Arduino sketch on a TV screen or projector to showcase your creation, which would be awesome. So Arduino is adding an FPGA to boost the capabilities of the main chip on the board, without providing any understanding of its capabilities or even its purpose. The FPGA’s function is out of context. It’s a pass-through device and a magic black box. You stick functions on it the same way I used to stick ROM cartridges into my NES as a kid (if this phrase means nothing to you, see this YouTube video).

This is great for an introduction, but the choice in hardware, if you ask me, is questionable. Don't get me wrong. As I said earlier, I like me some Cyclone, but using an Altera chip, a decidedly closed-source device, with apparently no direct access, closes the door to potential digital logic designers. If they had used a Lattice chip, for which an open toolchain has been developed (thank you, Clifford Wolf), and provided a direct channel to the programming interface, this would have been a far more robust development board.

Add on top of that the user’s temptation of forfeiting the core knowledge required to deploy stable firmware, let alone soft chip architectures on an FPGA, because it "just works," and we introduce the embedded industry to a potential world of hurt.

The Takeaway


As always, there needs to be a moral to this story. Here it is:

We need to treat Arduino as a door into a much larger world. We need to provide better ways of easing makers, developers, non-firmware-engineers and inventors into the core knowledge and skills required to carry their interests beyond the Arduinosphere without sending them off to university.

Now that FPGA IPs are a part of the Arduino ecosystem, this task has been made more difficult. We need to be able to peel back the abstract. Instead of adding more pre-compiled logic blocks for the users of Arduino, we should start showing them the inner workings. Slowly. Gently. And somehow as a natural progression.

The FPGA world has been on the rise. FPGAs recently started to popping up in Modern CPUs, from Intel Xeon and AMD EPYC to the Xilinx Zinq and Altera Cyclone V SoC FPGAs. More and more maker feeds on Twitter, and articles on hardware hacker blogs are talking about FPGAs in a meaningful and excited way. The future of development, processing and making is now intertwined with flexible hardware and custom logic.

As tech professionals, we owe it to the myriad Arduino users out there to encourage them to move beyond the comfort of the figurative airliner. To put a crash mat under them and guide them to the edge of a 6 foot platform, then to a higher platform and so on, until the skydiving that embedded development appears to be is just one more jump. We in the industry are in a position to foster the interest these enthusiast creators have in using embedded and FPGA devices into a desire to learn more and to take the initiative to remove that first layer of abstraction. To progress toward an in-depth understanding of their projects’ inner workings.

Maybe Arduino.cc will take up the call as well, expose more of the Altera FPGA’s capabilities in their online IDE and provide educational resources for digital logic and bare-wire programming.

In the end, we are all part of the same tech community, making things happen in the real world with code.



TL;DR


As promised.

  • Arduino is cool and enables awesome maker projects and quick proof-of-concept prototypes.
  • Abstraction layers are great for bypassing complex concepts, but should be the building blocks of core knowledge.
  • We have to be careful in the tech industry to use more stable verifiable platforms than Arduino in our end-user and B2B products' firmware.
  • MKR Vidor 4000 brings an Altera FPGA to the Arduino ecosystem
  • Uh oh, its toolchain is closed-source.
  • More abstraction here to compensate.
  • Arduino should be as much an education tool as it is a creation tool.
  • But adding more complexity and obscuring it with even more abstraction cripples it from eventually becoming a software and (now) logic design education tool.
  • How do we encourage Arduino users to move beyond their comfort zone into the big leagues of logic design and firmware development?

Co-authored by: Dimitar Tomov, DesignFirst OU