Actions
Forum Thread Details
  • Replies 15 replies
  • Subscribers 99 subscribers
  • Views 4224 views
  • Users 0 members are here
Related

What hinders your BeagleBone project?

cstanton

You could call this a series of discussions... 

When I was first introduced to BeagleBone, the BeagleBone Black was just released, and I managed to kill it. 5 volts on a 3.3v logical input without being aware thanks to a devicetree not being updated for an LCD display, but I had no idea, I'd only just been given the hardware and I was entirely new to it. Completely killed the kit. Then there was the difficulty of working with assembly for the PRUSS... it was a long list of interruptions.

So what tends to stop you from developing with a BeagleBone? Do you find that you encounter a problem part way through the project? Is it some knowledge you're lacking or is it the software? Is it how the hardware behaves or doesn't how you expect it to? Is it the operating system when you want to work bare bones or bare metal with the hardware?

Would you benefit from help with Linux? Or is it something else?

We're looking at expanding our content and what we ask from BeagleBoard to help introduce their products and guidance on their products, and I'm interested in what you need help with, so reply and let us know, regardless of knowledge level.

Parents

  • A proper use case. This applies to all SBC's. I have yet to find a power hungry requirement to use a Beaglebone or other SBC when an MCU can deliver what I require with much less power.

    Mind you that may change. I'm pondering over whether to develop a POE solution for a sensor network linked to an edge device. Beaglebone looks very suitable as the edge device, as one element of my project requires a variable voltage PWM signal... but then again when you look at the price of some of these Beaglebone capes, it makes you think twice about whether this project is worth the sunk cost... so that's my 2nd reason... cost.

Reply

  • A proper use case. This applies to all SBC's. I have yet to find a power hungry requirement to use a Beaglebone or other SBC when an MCU can deliver what I require with much less power.

    Mind you that may change. I'm pondering over whether to develop a POE solution for a sensor network linked to an edge device. Beaglebone looks very suitable as the edge device, as one element of my project requires a variable voltage PWM signal... but then again when you look at the price of some of these Beaglebone capes, it makes you think twice about whether this project is worth the sunk cost... so that's my 2nd reason... cost.

Children
  • in reply to BigG

    For me, the rollover from µC to SBC (except for size) is when I'm

    • building gateway/edge devices
    • have database, or processes with a long lifecycle that are candidates for the likes of node-RED
    • calculation heavy libraries like OpenCV

    At that moment, the BB has an advantage if real time operation is a requirement, with the PRUs.
    Although taming those is still difficult for me, after several years of practicing.

  • in reply to Jan Cumps

    Yes, those are very good aspects. I'm rather interested in the first element (building gateway/edge devices) to get me started.

    For example, does the use of Docker images make things easier or is this an over-complication. I'm assuming this is typically required if you're planning to replicate your solution on other Beaglebone boards etc. otherwise best ignore.

    Then how do you configure the LAN (assuming it's Ethernet). For example, do you simply add an Ethernet switch and plug things in. What other software controls are added to handle LAN in terms of setting IP addresses etc. How do you configure firewalls and other security elements.

    Also what about using gateway/edge device as a USB hub. For microcontrollers this is often an over-looked solution to create a star topology. How do you go about setting this up etc. What USB host library works best.

    In relation to databases, which works best. I have a tendency to jump to a LAMP solution, but this is very overweight and it would be handy to swap out the PHP for Python etc.

  • in reply to BigG
    BigG said:
    In relation to databases

    This may be a topic on itself.
    If the goal is to capture sensor data and aggregate/preprocess it, a relational database isn't a must in many cases.
    And if more than that needs to be maintained, I prefer a database hosted on one of the cloud solutions, or on a real server.
    On the Pi, I try to restrict to only those databases that are required by the software that runs on it.  And the temporary collection of sensor data for pre-processing, as mentioned earlier.

    (edit: also: it is a great platform to learn anything Linux. In that case, the above doesn't count. I was thinking about a design that has to serve duty)