We’re excited to be taking part in a webinar with our partner Nordic Semiconductor on June 20th, 2024. Note that on the signup page, there are two different timezones available! As with many webinars, the content will be available “on demand” after the fact.

Highlighting Reference Designs

The main focus of the webinar is how Golioth helps engineers get started quickly with our Reference Designs. Three of the designs we’ll featuring are:

These are fully featured end-to-end demos that highlight typical industrial use cases. I like to think that a past version of myself working as a hardware engineer at a product company would have really benefited from this model of learning. I know I would appreciate seeing an entire design that includes:

  • Hardware (both custom and off-the-shelf)
  • Firmware (open source, running on top of the Golioth Firmware SDK and the nRF Connect SDK)
  • Cloud side software
  • Visualization
  • Automation and Data routing (using the new Golioth Pipelines feature)

A generous helping of nRF Connect SDK (and Zephyr)

None of this would be possible without the great work from the Nordic team supporting all their wonderful hardware with the nRF Connect SDK. It unlocks many of the features on devices like the nRF9x family (cellular), the nRF7x family (Wi-Fi), and the nRF5x family (Bluetooth). We will talk about how we build the Golioth SDK to work alongside the Nordic SDK to make a connection to the cloud seamless for users.

Build it yourself

We will go over how you can build your own version of the Reference Designs. This is made easier by using our “Follow Along Hardware” guides, which include a parts list to buy modules “off-the-shelf” from popular distributors and a firmware binary that immediately shows the functionality of said hardware. Once you have a working design on your desk, you can also pull the code in from the Nordic SDK add-on directory in VS Code, which includes the Golioth reference designs. This is a super fast method for downloading the entire project and beginning to modify as needed. Finally, you can connect your project to Golioth and see the same data flowing out to your other Cloud services. Go from zero to hero in no time!

Don’t forget to register

Sign up today for the Nordic webinar with Golioth on June 20th, 2024. We’ll see you there!

Golioth will be joining our friends at Digikey on June 13th to talk about “Leveraging Zephyr to enable super-flexible IoT designs”.

Digikey is where we source many of the parts for our custom hardware and where we often order development boards for putting together demos. If you’ve seen our “Follow Along Hardware”, the product SKUs revolve around Digikey stock.

So we thought it would be a great opportunity to showcase just how many different boards, chips, and sensors we can control using the same base Zephyr code, while sending fleet back to the Golioth cloud.

What we will cover

In the upcoming webinar, we’ll cover:

  • The basics of Zephyr RTOS and how to get started designing quickly
  • How one code base can serve designs from 3 different microcontroller vendors with 3 different types of connectivity and two different sensor vendors!
    • NXP, Espressif, Nordic processors
    • Ethernet, Wi-Fi, Cellular Communications
    • Sensors from Infineon and Bosch
  • How to utilize Cloud services to deliver interesting features to a product with a single SDK install
  • How Golioth’s end-to-end Reference Designs can jumpstart your own IoT designs
  • How the recently announced Pipelines feature will enable even more flexibility in designs

How to register

Register for the event using this link. You will also be able to get access to the recording if you can’t make the live event, though Golioth staff be available for live Q&A directly after our presentation.

As we described in our announcement post, we had a range of demos at our kiosk in the Zephyr Booth at Embedded World 2024. Once again this conference proved to a valuable opportunity to connect with engineers across industries and get feedback on what we’re building at Golioth.

Walking through Embedded World 2024 - click to watch video on Loom

(Above: “walk the floor” in hyperlapse mode at EW24)

We met with our silicon partners, many of our design partners, and met new customers who were curious how to connect their devices to the cloud. One demo in particular drew people in and had people asking whether new Golioth capabilities could fit their needs.

Bluetooth Mesh Demo

We’ll continue to release videos of our demos throughout the next few weeks on the Golioth YouTube channel, but we wanted to have the Cloud-connected Bluetooth Mesh demo available. It showcases many of the things we’re interested in and working on actively at Golioth:

  • Improving our Cloud – We are continually adding new features and testing against our Firmware SDK and a wide range of devices.
  • Adding more collaboration features – This demo was done by Sandra Capri of Ambient Sensors, one of the companies that is in our Design Partner program. Sandra was able to get a demo up and going on Golioth quickly and it unlocked the ability to control hardware and firmware she knew really well from the Cloud (something she was new to). We’ll have more detail from her on the blog soon.
  • Bluetooth Gateways – Bluetooth devices are amazing because they enable low power monitoring and can pass a range of data between devices. The downside is the requirement to have a programming element (such as iOS or Android app) in the loop in order to control that hardware. But what if you didn’t? We are working on a range of new gateway designs, including on our newly announced continuously verified board, the RAK5010.
  • Controlling Short Range Devices – Golioth already supports boards that have connectivity over cellular, Ethernet, Wi-Fi, and Thread. Bluetooth has always been missing from that list, and yet is one of the largest classes of devices. Watch a recent stream about Bluetooth and stay tuned to see more about Bluetooth device control, or hop over to our forums to let us know what you need.

Want to hear more?

We have been regularly doing Friday Afternoon Streams at Golioth. It’s a great way to get a feel for our company culture and see some of the unreleased things that we are working on, including hack-day demos. This week we’ll be recapping more of the stuff we saw at Embedded World 2024, as well as some new features inside the Golioth Firmware SDK. Watch on LinkedIn or YouTube, and ask questions live:

We are returning to Embedded World in 2024 (EW24) and will be showing off the things we’ve been working on at Golioth since last year. We’re also living a little closer to the edge and bringing some experiments and unreleased items to showcase on the floor. Demo gods, be kind!

We’ll be at the Zephyr booth, helping to showcase one of our favorite Real Time Operating Systems and Ecosystems (though not the only one we support!). Golioth generally only targets one part in our standard hardware setup, but we continuously verify a bunch of hardware on our Firmware SDK. This means that you can be certain that every new feature added to the Golioth Cloud and SDK is fully tested throughout our supported hardware. The great thing about Zephyr is that the underlying hardware works very similarly to all of our CVBs, because of the work from the silicon vendors that participate in the open source project. We’re excited because 2024 saw even more silicon vendors joining the fray!

Golioth Demos

Being part of a large project like Zephyr, we share time at the booth Kiosks. We’ll be at the Zephyr Booth (4-170) at the following times:

  • Tuesday, April 9th from 1500 to 1800
  • Wednesday, April 10th from 1200 to 1500
  • Thursday, April 11th from 0900 to 1130

All times CEST, which is GMT + 1

Hardware we’ll have on hand

  • Modbus Vibration monitor – This is our newest Reference Design that captures vibration and temperature data from a sensor normally used in industrial environments for large motors. The hardware in the Reference Design talks over RS-485 to the remote sensor and queries all of the available registers and publishes them to the Golioth cloud for processing and viewing.
  • Air Quality Monitor – It’s always interesting to see the trend lines of air quality metrics throughout the day. There are a lot of people that filter in and through the Nuremberg convention center, so we can track things like CO2 concentration just from the elevated number of bodies. The particulate counter is unlikely to go up a lot, but if there’s something like a cotton candy booth nearby, it could potentially have particulates flying through the air. I’ll be sure to go and investigate and clean up that particular air quality problem if the need arises.
  • Aludel Elixir – Powering our newer reference designs is the Aludel Elixir. This is an evolution of our previous designs (the Aludel Mini) that stitched together outside development boards that we loved like the Circuit Dojo nRF9160 Feather and the Sparkfun ThingPlus nRF9160. We pulled many of those components onto a bespoke PCB, and also added other components that can enhance any reference design. It all comes together in a custom milled case that enables maximum flexibility.

Aludel Elixir Rev B

Are you interested in your very own Aludel? Shoot me a note to discuss at Embedded World or fill out this form

Partner Demos:

AL2LOG at the AL2TECH booth (3A-335)

A render of the AL2LOG Unit

Our design partner AL2TECH based out of Italy is bringing an exciting new logging project based on the nRF9160 and an STM32 coprocessor. This is meant to target industrial applications that require a flexible way to capture data in a harsh environment.

The AL2LOG is a compact industrial logger with different sensor and actuator interfaces. This is based upon AL2TECH’s broad experience serving their clients in the energy meter/remote sensor monitoring industries.

The AL2LOG PCB (rev 1.0)

Some high level features include Cellular and GPS connectivity (nRF9160), as well as external module comms using USB-C, RS-485, and CAN. There is an Ultra Low Power acquisition and logging sub system (STM32) with a true 14 bit ADC. Industrial inputs including Digital Input, Dry Contact, Pulse Counter, 0-10V Voltage Analog Input, and 4-20mA Current Loop Input. There are outputs like Open Drain Output, and programmable supplies for devices downrange of the logger. The device can also switch external 220V via a relay. For powering the device you can use a 12-24V rail, or depend on the large D-Size High Power LTC Cells.

The device communicates back to Golioth using Zephyr/NCS and can be remotely updated using Golioth’s OTA service. Data routed from the field back to the cloud is accessible via the Golioth REST API.

BT Mesh demo from partner Ambient Sensors at the Zephyr booth (4-170)

BLE Mesh Demo from Ambient Sensors communicating through Golioth, on display at Embedded World

This demo shows Golioth controlling an LTE/BLE bridge (Thingy91) that communicates to a BLE Mesh composed of a series of lights that are running the Light Lightness Controller (the LC Server) model. Eight instances of the BBC micro:bit represent lights in this demo. The boards run BLE Mesh firmware on Nordic Semiconductor’s nRF52833, which could easily be controlling an LED driver instead of the demo LEDs.

The BLE SIG standard LC server code is running on each microbit, and is communicating with the Thingy91’s nRF52840, which communicates on the mesh as an LC client, Generic OnOff Client, and Light Lightness client. Using Golioth, the  demo remotely sends a command to turn the LC server on, and lights will then slowly dim over time (as is the functionality of the LC server). Normally lights dim after several hours, but for the purpose of the demo, we set that value to several seconds. Delay values may also be set via Golioth, showing how these settings can be tuned remotely if desired. Additionally, we have created commands to allow the Golioth user to turn on the lights, while turning off the LC Server (to prevent it from dimming the lights), and to set the lightness value to any desired value.

Golioth connectivity demo at the NXP FRDM Lab

Find Golioth at the FRDM Lab at EW24

NXP is another vendor that has great support in Zephyr. We’ll be showcasing Golioth’s solution on NXP boards at their FRDM Lab in the Messepark classroom (the main open area when you walk into the conference). You can also see all of NXPs new solutions at their main booth in the presentation hall, booth 4A-222.

Even more Golioth!

What’s that? You haven’t seen enough of us yet? You’d love to hear more on-site at Embedded World? Well let’s telegraph every place we’ll be! In addition to our time showcasing Golioth at the Zephyr booth, we’ll also be giving a couple of talks at the Zephyr stage (next to the Zephyr booth):

  • April 9th at 1400: “Building end-to-end Zephyr demos on IoT hardware”
  • April 10th at 1530: “Multi MCU OTA updates with Golioth and Simple Management Protocol”
  • April 11th at 1200: “Local toolchains, no more! Using GitHub Codespaces for training people on Zephyr throughout the world”

In the evenings (if we’re still standing), we plan to attend these open events and socialize with others in the industry:

  • IoT Stars – This is a short speaker event, as well as a networking session. We’ll have some of our portable demos with us.
  • PCBarts meetup – This is a more social event hosted by a local consulting and manufacturing company. Last year this was a wonderful group of engineers showing off their projects–personal and professional–after a long day at the tradeshow.

We really hope to see you at the conference! If you’d like to talk about Golioth and how we can work together, please fill out this form!

On September 28th, 2023 at noon EDT / 9 am PDT, we’re hosting a webinar with Keenan Johnson of the Ribbit network! You have seen Keenan featured in our Case Study about Ribbit where we detail how they are using Golioth to power their fleet of environmental monitors. We’ve been giving away Ribbit kits to new newsletter signups, so be sure to sign up and enter the sweepstakes if you haven’t already.

But really we want to get into the nitty-gritty details of environmental monitoring: what are the challenges for putting devices into the field and how does someone address those challenges with a connection to the internet?

This session will cover things like:

  • Protecting a project from the elements while also still measuring those elements
  • Creating resource efficient communications back to the internet to prolong device life
  • Gathering relevant fleet health data to ensure long deployments
  • Working with community partners to deploy sensor networks asynchronously
  • Visualizing data in a useful way for all stakeholders
  • Utilizing automation to reduce engineering overhead for a large sensor network
  • Empowering citizen science to improve environmental monitoring

The presentation will last approximately 40 minutes, followed by a Q&A session with attendees that can ask questions directly to Keenan. Sign up for the webinar below!

 

As embedded developers, we’re consistently seeking ways to make our processes more efficient and our teams more collaborative. The magic ingredient? DevOps.Its origins stem from the need to break down silos between development (Dev) and operations (Ops) teams. DevOps fosters greater collaboration and introduces innovative processes and tools to deliver high-quality software and products more efficiently.

In this talk, we will explore how we can bring the benefits of DevOps into the world of IoT. We will focus on using GitHub Actions for continuous integration and delivery (CI/CD) while also touching on how physical device operations like shipping & logistics which can be streamlined using a DevOps approach.

Understanding the importance of DevOps in IoT is crucial to unlocking efficiencies and streamlining processes across any organization that manages connected devices. This talk, originally given at the 2023 Embedded Online Conference (EOC), serves as one of the many specialized talks freely accessible on the EOC site.

GitHub Actions for IoT

To illustrate how to put these concepts into practice, we’re going to look at a demo using an ESP32 with a feather board and Grove sensors for air quality monitoring. It’s important to note that while we utilize GitHub Actions in this instance, other CI tools like Jenkins or CircleCI can also be effectively used in similar contexts based on your team’s needs and preferences.

For this example we use GitHub Actions to automate the build and deployment process.

The two main components of our GitHub Actions workflow are ‘build’ and ‘deploy’ jobs. The ‘build’ job uses the pre-built GitHub Action for ESP-IDF to compile our code, and is triggered when a new tag is pushed or when a pull request is made. The ‘deploy’ job installs the Golioth CLI, authenticates with Golioth, uploads our firmware artifact, and releases that artifact to a set of devices over-the-air (OTA).

Imagine an organization that manages a fleet of remote air quality monitors across multiple cities. This GitHub Actions workflow triggers the build and deployment process automatically when the development team integrates new features or bug fixes into the main branch and tags the version. The updated firmware is then released and deployed to all connected air quality monitors, regardless of their location, with no additional logistics or manual intervention required. This continuous integration and deployment allows the organization to respond rapidly to changes and ensures that the monitors always operate with the latest updates.

Let’s delve into the GitHub Actions workflow and walk through each stage:

  1. Trigger: The workflow is activated when a new tag is pushed or a pull request is created.
    on:
      push:
        # Publish semver tags as releases.
        tags: [ 'v*.*.*' ]
      pull_request:
        branches: [ main ]
  2. Build: The workflow checks out the repository, builds the firmware using the ESP-IDF GitHub Action, and stores the built firmware artifact.
    jobs:
      build:
        runs-on: ubuntu-latest
        steps:
        - name: Checkout repo
          uses: actions/checkout@v3
          with:
            submodules: 'recursive'
        - name: esp-idf build
          uses: espressif/esp-idf-ci-action@v1
          with:
            esp_idf_version: v4.4.4
            target: esp32
            path: './'
          env:
            WIFI_SSID: ${{ secrets.WIFI_SSID }}
            WIFI_PASS: ${{ secrets.WIFI_PASS }}
            PSK_ID: ${{ secrets.PSK_ID }}
            PSK: ${{ secrets.PSK }}
        - name: store built artifact
          uses: actions/upload-artifact@v3
          with:
            name: firmware.bin
            path: build/esp-air-quality-monitor.bin
  3. Deploy: The workflow installs the Golioth CLI, authenticates with Golioth, downloads the built firmware artifact, and uploads it to Golioth for OTA updates.
    jobs:
      build:
        runs-on: ubuntu-latest
        steps:
        - name: Checkout repo
          uses: actions/checkout@v3
          with:
            submodules: 'recursive'
        - name: esp-idf build
          uses: espressif/esp-idf-ci-action@v1
          with:
            esp_idf_version: v4.4.4
            target: esp32
            path: './'
          env:
            WIFI_SSID: ${{ secrets.WIFI_SSID }}
            WIFI_PASS: ${{ secrets.WIFI_PASS }}
            PSK_ID: ${{ secrets.PSK_ID }}
            PSK: ${{ secrets.PSK }}
        - name: store built artifact
          uses: actions/upload-artifact@v3
          with:
            name: firmware.bin
            path: build/esp-air-quality-monitor.bin

For those eager to dive in and start implementing DevOps into their own IoT development process, we’ve provided an example Github Actions workflow file on GitHub. Feel free to fork this repository and use it as a starting point for streamlining your own IoT firmware development process. Remember, the best way to learn is by doing. So, get your hands dirty, experiment, iterate, and innovate. If you ever need help or want to share your experiences, please reach out in our our community forum.

Visual Studio Code, colloquially known as VS Code, has become the de-facto Swiss Army Knife of Integrated Development Environments (IDEs). It is already configured for a lot of different languages and ecosystems when first installed. It’s also great for developing Zephyr RTOS projects, but not out of the box. Jonathan Beri presented at talk at the 2023 Embedded Open Source Summit detailing how to configure VS Code for Zephyr development.

To follow along, check out Jonathan’s example repository for us Zephyr in Visual Studio Code.

New to Golioth? Sign up for our newsletter to keep learning more about IoT development or create your free Golioth account to start building now.

VS Code for Embedded Development

Most of the pre-configuration rolled into the stock installation of VS Code centers around languages used in web development. But increasingly we see the IDE called upon for embedded system development–moving beyond merely working with source code to include native debugging and flashing. These more specialized features tend to be the areas requiring custom configuration. Notably, Nordic and NXP are both actively developing VS Code environments for Zephyr.

For those who prefer to maintain their own workspace configuration, selecting the right extensions is a good place to start. The Microsoft’s extensions for C/C++ and Cmake are table stakes for embedded development. Jonathan also recommends the Cortex Debug plugin and suggests that Microsoft’s Embedded Tools is a newer plugin you may find useful.

Diving into Configuration Files

The meat of the talk comes about sixteen minutes in as Jonathan walks through the settings files he’s using to configure his workspace: settings.json, tasks.json, launch.json, and extensions.json. You can view these files in the example code repository.

Telling VS Code where to find GCC will get syntax highlighting and linting working well. Preventing CMake from trying to auto-configure Zephyr projects will silence a lot of the popup window noise when opening a new VS Code window. And setting up the task runner is akin to configuring aliases for your oft-used commands, accessible from the VS Code command palette. Finally, debugging configuration and recommended extensions round out the workspace-specific configurations using the built-in “profile” features.

All the Things You’ve Been Missing from VS Code

If you’ve already tried developing for Zephyr in VS Code it’s easy to forget what you’ve been missing. The live demo begins at about 20:30 and immediately shows the most basic annoyances have been solved. There are no longer random red squigglies sprinkled throughout your code, because VS Code now knows where to find all of the header files. You can jump to OS-specific function declarations as expected and access the function syntax hinting because the entire Zephyr tree is accessible for the extensions. These features are not novel, they’re just not fully configured out-of-the-box.

Building and flashing works as expected, because your target board and programmer have now been specified in the configuration. They’re triggered via simple to remember commands like west build that Jonathan added to the command palette via those JSON files. The serial terminal connection to the device is available in the IDE without having to juggle external console windows. The general noise floor of the IDE is almost non-existent at this point, all thanks to a comprehensive configuration that makes the developer experience worlds better.

Modern Tools for Modern IoT

Zephyr RTOS is paving the way for the next generation of embedded devices. As the Founder and CEO of Golioth, Jonathan Beri recognized the power of Zephyr to support cross-vendor hardware in the IoT space, which makes it possible for Golioth to support the hardware that you the choose (and not a narrow set of hardware required by your IoT Cloud). As this talk shows, he spends a lot of hands-on time with the RTOS and is sharing the workflow he has developed over the last several years.

Set aside an afternoon to prototype your IoT Fleet. Your first 50 devices are free with Golioth’s Dev Tier. Follow Jonathan’s examples for using VS Code, and you’ll be sending sensor data to the cloud in a matter of hours!

Golioth is your instant IoT cloud that lets you choose what hardware you want to use. We’re able to remain hardware agnostic because Zephyr RTOS has great cross-vendor support. As the fastest-growing RTOS, Zephyr is well worth learning, but we’ve found most people need a little help getting started. Golioth’s next free Zephyr training happens online on August 23rd. We hope to see you there!

We’ve been hosting these free trainings for the past two years, and our approach has evolved over that time. Golioth’s Lead Developer Relations Engineer, Chris Gammell gave a talk on how we approach hosting remote training at the 2023 Embedded Open Source Summit. Anyone interested in teaching a remote course on embedded development will find this interesting as you will surely face the same challenges we have.

Skipping the Dev Env Setup Process by Using Kasm

The biggest challenge to teaching a new embedded OS is not in the coding work the attendees will be doing, but in setting up every build environment correctly. It takes time to install all the compilers and library code. This is further complicated by differences in attendee OS choices, versions, and existing configuration. We found that anywhere from 45 minutes to the entire training was gobbled up with this step.

Kasm container for Zephyr development

Kasm container running inside Firefoxs show VS Code with the Zephyr build process in a terminal window

The solution we chose last fall is to pre-configure a build environment for all attendees. For an in-person training, this would best be done by providing a laptop to everyone that standardizes the experience. But we’re hosting training remotely, so we spun up a Kasm workspace so the build environment is loaded via web browser.

Each attendee logs into our Kasm instance, which includes the Zephyr SDK tools (compilers, etc), the Zephyr tree (kernel, driver, and library code), Golioth’s Zephyr Training example code repository, the self-guided Golioth Training docs, and Visual Studio Code (VS Code).

As Chris outlines in his talk, with this approach an attended can be compiling their first Zephyr code in a little more than one minute. Admittedly there is some tap-dancing around the issue of programming a local device when the code is being compiled in a remote container. But we’ve had great success doing this with Nordic’s desktop tools.

Getting That In-Person Atmosphere, When Not In Person

Our training is self-guided, using a Docusaurus-based document site that’s available to anyone interested. But one of the benefits of signing up for the live training is that Golioth staff who are experienced with Zephyr are there to share that experience and answer questions. This is no boring webinar, we take the remote-training experience and make it feel a lot more like being in a classroom!

Golioth Zephyr Training group photo from Gather.town

One of the study groups in Gather.town from the July 12th Golioth Zephyr Training

To add interactivity we use the Gather.town online platform. It’s feels a lot like the original Legend of Zelda; you have an 8-bit avatar that you can walk around the virtual classroom. When you get close to other people (or walk onto one of the table-group carpets) a group video chat automatically opens. You can raise your hand using an emoji and an instructor will walk over to help.

In three hours, we get to know each other, learn how to compile and run some code, and discuss myriad topics that transcend the words found on the self-guided training docs.

Upcoming Training

If your company is planning to host a remote training that centers around embedded engineering, watch Chris Gammell’s talk. He drills down from how Golioth conducts our training to the experiments that led us to these solutions. From large toolchains and local USB ports, to live interactions and working with different attendee skill levels, he will help you find the happy path for your organization.

If you’re still getting up to speed with Zephyr RTOS, join us for the upcoming Golioth Zephyr Training on August 23rd, 2023.

Golioth booth at 2023 Embedded Open Source Summit / Zephyr Developers Summit

The Golioth team just returned from the Embedded Open Source Summit after a fantastic week talking about Zephyr, Embedded Linux, and of course, the future of the Internet of Things. We presented talks, we showed off hardware demos at our booth, and we talked to hundreds of awesome engineers.

The Embedded Open Source Summit (EOSS) was a collection of different conferences hosted by the Linux Foundation, including the Zephyr Developer’s Summit (ZDS). Our booth  demonstrated the Golioth IoT platform used for automotive applications (CAN + GPS), power monitoring, air quality monitoring, and trash can monitoring; all based on Zephyr RTOS. Golioth makes it easy to connect microcontroller-based devices to the internet, with prebuilt features for data management and fleet control.

ZDS gives us the opportunity to discuss the many use cases we see from our customers with the developers and maintainers of the RTOS that we most often use. Having such direct insight into what’s coming down the road helps Golioth stay on the bleeding edge of what is possible.

Why EOSS/ZDS?

The Golioth Zephyr SDK is an open source library build on top Zephyr RTOS. It delivers great cross-platform support and a wonderful network stack, and allows us to support the widest range of customer hardware needs. While we also offer a cross-platorm SDK based on FreeRTOS (which supports Espressif’s ESP-IDF, Infineon’s ModusToolbox™, and Linux), we see the widest interest in Zephyr from our customers.

We don’t just go to the Zephyr Developer’s Summit, Golioth is a silver member of the Zephyr Project. As a member of the Technical Steering Committee, we’re on weekly calls about the future of Zephyr, but nothing compares to spending in-person time with our friends and partners–ZDS is the perfect place to do that.

We presented three talks on our work with Zephyr over the past year, and enjoyed many of the other topics and discussion presented. Update: All videos have now been published on the Zephyr YouTube Channel!

Everyone Needs to Get Connected

Early morning Golioth booth before the EOSS/ZDS crowds arrived

There was a constant flow of interesting people to speak with at the Golioth booth. This year was a special treat, since ZDS was co-located with the Embedded Linux Conference, the Automotive Linux Summit, and three other conferences.

Overwhelmingly it’s apparent that there is a trend of moving IoT devices down the stack, from being Linux-based to being microcontroller based. That’s where Golioth specializes.

Jonathan Beri and Mike Szczys at the Golioth booth during 2023 EOSS/ZDS in PragueWith the silicon technology available today you should be able to connect microcontrollers to the internet, update the firmware remotely, send and received data with the device, and control not just one device but thousands upon thousands. You should be able to do this with a device you choose (and design with your exacting specifications0, not one dictated to you. You should not have to write all of this IoT cloud management code yourself. This is what we stand for, and what people told us they needed in conversation after conversation at this conference.

The development cycle for custom hardware is long, but your device management cloud software is already written. Give Golioth a try, your first 50 devices are free.

A Little Team-Building Goes a Long Way

Golioth team at the 2023 EOSS/ZDS conference dinner

We love conferences because we get to meet you there. But as a fully-remote company, we also get to meet the rest of the Golioth crew in person. Jonathan, Chris, and I were all at Embedded World in March, so it hasn’t been too long for the three of us. But it was quite exciting to meet Marko Puric, who joined us as a Field Application Engineer in May. Keep an eye out for more from Marko here on the blog and elsewhere in the Golioth universe.

IoT projects and products fail at a spectacularly high rate; not in the field, but by never making it out of the lab. One of the myriad reasons is time to market. When you have a fixed amount of time to make an idea work and deliver that product to the marketplace, you don’t get a lot of retries. That’s why I gave this talk about how to get the most out of your “Rev A” (first revision of) hardware. It was delivered as one of the free talks from the Embedded Online Conference (EOC) in 2023. You can view this and many other highly specialized talks on the EOC site. Registration is required for viewing the other free talks and there is a nominal fee to join the site and view the talks from this year and last year.

Balancing Act

Why not “move fast and break things”? Why bother caring about Rev A? Despite reduced costs around hardware thanks to quick turn manufacturing services domestic and abroad, it’s possible to get hardware fast…but there is still a delay between a Rev A and Rev B board. What’s more, the decisions you make in your early hardware prototypes can carry with you throughout the life of a product, and it makes sense to shoot for a best-case scenario when planning and executing your first spin of a prototype. This talk covered three areas of the prototype process.

Before Rev A

The “before” is all about planning, especially across different teams. Hardware designers for IoT products need to make sure they communicate properly with their firmware and cloud teams, in order to maintain good expectations. A written plan about what you’re hoping to get out of the Rev A prototype and how to maximize the testing of that prototype will ensure you don’t waste or duplicate efforts later. Design reviews are a crucial component to allow different teams to voice their needs before manufacturing.

During Rev A

Once your prototype is planned, designed, and manufactured, you need to execute on your testing plan. Your testing methods will help you to understand when a prototype has met or missed goals set during planning. This part of the talk also reviews some testing tools that can help teams get more data from their prototype device.

After Rev A

Once you have thoroughly tested your Rev A prototype, a post-mortem of what went wrong (and right) is crucial. It will ensure you improve your process (for future Rev A prototypes) and also capture all of the needed changes for a Rev B prototype.

Case Study

Golioth does not build and sell finished hardware products.  But we do regularly create “Rev A” hardware when we create different Reference Designs. These are built to help accelerate teams looking to build an end product but wouldn’t mind benefiting from someone else showing how to build the first spin of a design. Our Reference Designs are built on top of a prototyping platform we created that attempts to balance flexibility, a quasi-finished look, and a relatively compact design. None of these categories are super optimized, as that is left up to the user hoping to build a finished product.

We’re always looking for new Reference Designs to build to help accelerate engineers’ Rev A prototypes. If you have any requests or need help building out your prototype, let us know on our forum or drop us a note.

Conference Talk Slides