Jim, Thanks for the feedback and insight. That is incredibly valuable to know your experience. We did separate the hardware and software, but I agree the next step will be to write the HW server in C/C++.
Given your experience and feedback, I think you may have saved us several headaches, so thanks so much for sharing! Hopefully that sets us on the right track! Cheers, On Wed, Oct 7, 2020 at 12:47 PM Jim F <[email protected]> wrote: > We built and delivered over 1000 ocean buoys in a design cycle that lasted > about 9 months based on the pocketbeagle MCM. The original plan was to > build a PCA on which the pocketbeagle sat (in order to satisfy some "COTS" > spec) but the cost of doing so got prohibitive, so we just squished the > boards into one. Not so much difference. Our initial prototypes used BB > blue and pocketbeagle, and they worked fine with a tangle of wires > connecting to different sensors and interfaces. We had no issues flashing > things, ever; that just worked (but on the PB we used SD cards, obviously). > I think I'm chiming in with Gwen on some of this here: > > In our case we built everything to run on Linux using a mix of python3 and > C. I definitely regret not doing all in C. It would have been nice to have > compile-time checking of code, as the linter just can't catch everything we > threw at that codebase. But python did let us add some fairly complex > features very quickly compared to C. I would absolutely not field a > hardware system using JS, but I highly value reliability (says the guy who > did half of it in python, so take that for what it's worth). One of our > biggest issues was boot time, which we never got better than 30 seconds > (but most of the time I had to do that was off the clock anyway). > > If I were doing what I guess you're doing, I'd move the hardware > interfaces into a compiled solution and focus hard on error trapping. A > system shouldn't lock up because a voltage went out of range (unless it > went too high and you blew up the input, but that's bad hardware design). > Realistically almost all of the work we did on that job was learning about > errors to trap. Python's duck typing is awesome for prototyping but made my > life hell in a tight delivery schedule. Trapping things like "the logs > partition is full" seems hard in JS - a bugaboo which made my stuff die in > 24 days, if I recall correctly. > > Anyway, if you separate the UI (in JS, or whatever it has to be) from the > hardware interface, it would be easier to make the system more robust and > capable. I would do all the HW interface in C if I had to do it again, and > it wouldn't have taken much longer to implement, might have cost me 10% > additional dev time. Define the inputs very well on the hardware side (i.e. > clamp them), and in the software reject any signal outside the expected > range. If you can completely eliminate the OS and go to a compiled > baremetal solution (or a stripped down RTOS like what TI offer for Sitara) > you will eliminate the linux cruft (you probably don't need chrony, syslog, > a filesystem, etc.) which makes for a simpler system that is easier to > debug. Of course then you'll spend a lot more time programming, but your > yogurt machine won't need to reboot so much. > > The biggest issue we have in this type of job is testing. Software guys > know how to build a nice test framework. It works great all the way up till > you have to deal with some external piece of hardware that might not always > do what you expect. In my case, I had a modem which worked well except when > it failed in a variety of exciting ways; a GPS receiver which occasionally > reported impossible locations, and a series of different analog- and > digital-output sensors which all found interesting ways to work wrongly. > I've built test hardware for jobs, but I've never had to automate testing > of a system involving so many disparate parts. That's really, really hard > to automate, and I've yet to find an approach which doesn't require me to > turn it into a career. As I said above, defining the range of the inputs is > key, but it's so much easier to do with an analog signal than a digital > protocol. Even then, should actuator 1 do X when both sensors 1 and 2 are > at their negative limits - sometimes these things aren't completely obvious > until you think them through. > > Those are just some thoughts from someone who has been there. Good luck > though. > > Jim > > On Wed, Oct 7, 2020 at 8:41 AM [email protected] < > [email protected]> wrote: > >> Hello beaglebone community, >> >> This is my first post. >> >> I used beaglebone to develop a prototype for for a self-cleaning >> smoothie machine that we plan to commercialize (see video below). It has >> multiple sensors and outputs to run motors/solenoids while ensuring user >> safety. >> >> https://www.youtube.com/watch?v=76XDJK5V0PA&feature=share&; >> ab_channel=PascalKriesche >> >> Right now we have. BBB running a linux OS and running a script we >> wrote in JS. One issue we have had was the 1.8V analog sensors losing >> signal which required us to reboot the system every tie that occurred. We >> also had an issue flashing 2 out of our 4 prototypes with an image that >> worked (seems to be a firmware version issue leasing to an incorrect >> hardware pin mapping). >> >> I know eventually we want to use a chip on board, but for the initial >> production run we were hoping on sticking to a prebuilt onboard computing >> module for the initial 1000 units in order to save time and costs. I was >> wondering if anyone in this forum had experience launching a product with >> beaglebone and if this instability can be resolved with the correct I/O >> filtering on our PCB and software functionality. >> >> Thanks in advance! >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/faf26e97-c403-4dac-adc8-7acede4832b9n%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/faf26e97-c403-4dac-adc8-7acede4832b9n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h_JnKd2AA2%3D7Ny7FM0SCGfw5f%2B8hoA9z%2B7QJMtH7oj%3DEg%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h_JnKd2AA2%3D7Ny7FM0SCGfw5f%2B8hoA9z%2B7QJMtH7oj%3DEg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CANJpQB7DTHV1N1rBNrPZFW-eUoCgASHo5cqLSNHBg5NW92%2B-2Q%40mail.gmail.com.
