> Background/requirements > Currently using Debian OS on my prototype build based on a
> Beaglebone green wireless. > Custom software is constructed in java. > System utilizes 9 axis accelerometer, vibration sensor, Bluetooth, > WiFi, LTE-M, GNSS, power management (through BB I2c and > GPIO channels) > It runs on a battery and solar. Very stringent requirements. But... I would suggest more systematic approach, which has more in-depth reach: nothing to do with neither YOCTO, neither Debian! > Power usage is important. Standby is used and still needs to listen > for vibration sensor, Bluetooth and LTE-m cellular events. > Only constrained *by power usage and data usage*. Processor or > memory usage are unconstrained except for in relation to power usage. Here, the data usage and memory usage are somehow on the same page. I will assume that main (and sole) problem here is *power usage*. > Minimizing data usage if an OS update is needed would be an advantage > No audio , video, USB or GUI is used. You need to consider deeper, more fundamental approach, here. The first control you have over the hardware is U-Boot run (boot-loader). In other words, you should, using U-Boot (I am assuming you use U-Boot), to add functions which explicity disable the next functionality in ARM (AM335x 1GHz ARM® Cortex-A8): <http://www.ti.com/product/am3358> [1] ALSA HW (some registers in Power Plane which will completely disconnect ALSA domain); [2] The same for HDMI 720p domain; [3] The same for USB domain; [4] Whatever HW blocks/domains you really do not use! Then, you need to minimize Linux driver tree, leaving only what you really use: 9 axis accelerometer; vibration sensor; Bluetooth; WiFi; LTE-M; GNSS; Power management (through BB I2c); GPIO channels (leaving the minimum GPIO usage)! I would prefer Debian (for number of reasons), but YOCTO is, certainly, the good option too! Zoran _______ On Wed, Feb 20, 2019 at 2:49 AM ChenQi <qi.c...@windriver.com> wrote: > Your main concern is about power usage. As long as you are using linux, > you might want to do the following: > 1) Custom kernel to include drivers that are necessary > 2) Do not install unnecessary packages, do not start unnecessary daemons > The above two could easily be achieved by Yocto. > > Best Regards, > Chen Qi > > On 02/13/2019 12:49 AM, andrew.r...@aktyon.com wrote: > > Hello, > > > > I’m looking to evaluate the general purpose/utility of a custom build > Yocto embedded OS. I’m trying to get my head around the benefits of using > such an OS. I’m sure it’s on case by case basis so let me provide my > background and requirements. > > > > Background/requirements > > Currently using Debian OS on my prototype build based on a Beaglebone > green wireless. > > Custom software is constructed in java. > > System utilizes 9 axis accelerometer, vibration sensor, Bluetooth, WiFi, > LTE-M, GNSS, power management (through BB I2c and GPIO channels) > > It runs on a battery and solar. > > Power usage is important. Standby is used and still needs to listen for > vibration sensor, Bluetooth and LTE-m cellular events. > > Only constrained by power usage and data usage. Processor or memory usage > are unconstrained except for in relation to power usage. > > Minimizing data usage if an OS update is needed would be an advantage. > > No audio , video, USB or GUI is used. > > > > > > So would there be a significant benefit seen by using a custom Yocto build > or would a GUIless version of Debian be just as effective? Also considering > Buildroot if that would be just as effective and simpler to execute. If > anyone has any other thoughts or concerns I would love to discuss. Thank > you for your time. > > > > Thank you, > > Andrew Rudd > > President, Aktyon > > 352-256-8086 > > andrew.r...@aktyon.com > > [image: AktyonLogoAndFontSignature] > > > > > > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto