What are /r/embeddedlinux's favorite Products & Services?

From 3.5 billion Reddit comments

>I have a Python script running that reads the temperature from iio (the manufacturer has a kernel driver available that I’m currently using). This has a lot of overhead and I’m only able to get readings every second or so

This seems strange. I've never used iio, but I'm having a hard time understanding how this could have so much overhead that you are only able to get readings once per second. According to this, one of the ways you can access iio is via sysfs attributes, so you should be able to just use echo and cat to configure and read data from iio to see what kind of performance you're getting.

Is it possible the problem here is the iio python library you're using?

> it will always reboot after a certain number of commands are issued - normally around 250.

• Is it uptime-dependent at all? Does it matter if these ~250 commands are issued quickly in the first few minutes, or slowly over the course of several hours/days?

> I have tried using a different shell with no success

• Which shells (original shell and different shell)?

• Same number of commands until it reboots?

• Do the commands have to be issued in the same shell process? For example, if you log in (execs a shell process), issue half of the commands, log out, then log in again (different shell process) and issue the other half of commands, does it still reboot after ~250 commands?

My first thought is that maybe the memory map is incorrect, and the shell is keeping a command history in memory that grows until it hits a region of memory that causes a reboot.

When the system reboots, can you tell if it is due to a kernel panic? Does it log a message anywhere, like /dev/console? If you do not see a message, you can try setting kernel cmdline parameters like console= and panic= to get a log you can read, or even pstore logger.

If there is no indication of oops/panic then maybe the reboot is triggered by hardware. Are there any watchdogs enabled?

Are there any GPIOs hooked up to soft-reset that might be malfunctioning?

Can you add/remove kernel modules to test whether one might be causing the reboot?

A kernel space device driver is usually better. But user space device drivers are supported in Linux.

Use the uio framework instead of/dev/mem to access device registers and receive interrupts: https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html

LWN had a good overview of how a user space device driver can appear as a device to the rest of the system. (Downstream Interfaces): https://lwn.net/Articles/703785/

Reasons to write a driver in user space instead of kernel include security (driver runs with lower privileges and capabilities, and written in a memory safe language), ease of development (quicker edit/test cycle, better debuggers), licensing (no need to GPL your driver).

Yeah, I'm aware of the one session PATH variable. I just solved my problem a couple of minutes ago. I found that the channel driver is a fork of a channel driver that is already included in the OpenWRT build system. I just copied the package Makefile from that package and changed it following this tutorial: https://openwrt.org/docs/guide-developer/packages

Then I used the OpenWRT build system to do the compiling for me. I installed it on my OpenWRT OS and everything seems to be working now.

This is probably not what you want but I decided it would be interesting to see how you would connect to pcie ports together and transfer data. I don't think the non transparent bridge mode would work on the same system as its designed for connecting 2 systems via pcie.

https://www.kernel.org/doc/html/latest/driver-api/ntb.html

You might need to use memmap=nn[KMG]$ss[KMG] syntax. I'm not completely sure what "reserved" means exactly in this context.

Apparently the docs have changed, this is the current version: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html

> I need to reserve the other 2GB

What are you trying to do, why do you need some memory to be reserved? And reserved for what?

Anyways, the docs say that mem only limits memory on x86. You probably need to use memmap instead.

https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html

if you're into this gpiod business you should also label each of your gpios on this expander, it'll make it even nicer to use from bash: https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt#:~:text=%22-,gpio%2Dline%2Dnames

Stuff like gpiogett \gpiofind SOME_PIN`,gpioset `gpiofind SOME_PIN`=1`

Manipulating GPIO pins using /sys is deprecated and should be removed as of 2021

As for simulating GPIO interface: https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-mockup.html

If you're a noob one of the most important thing is community support/documentation/help. And it seems like Beagleboards has sorta slowly died/gone in the dark (awaiting for the new RiscV one) (this is entirely my own opinion on the beagleboard community, and may not be accurate!) Some of the most documented hardware is Raspberry Pi. I know Microchip has some tutorial-based MCU and MPU's for sale.

As for the wireless BBB, there is no difference, just added WiFi and Bluetooth (http://octavosystems.com/octavo_products/osd335x/), if you don't need those get the BBB (REV C), there are different revisions of it. The green one is from (seeedstudio) and it has the Grove connectors or whatnot, check into whether you want those or not.

There are great books for the Beaglebone (https://www.amazon.com/Exploring-BeagleBone-Techniques-Building-Embedded/dp/1119533163/ref=mp_s_a_1_1?crid=34QPQSOFXZ5IV&keywords=beaglebone+black+book&qid=1640627072&sprefix=beaglebone+black+book%2Caps%2C322&sr=8-1).

If you buy the BBB (Rev C) and that book, it's a decent starting point IMO, you should be fine and good to go.

Someone lemme know, but I don't think you can even buy BBB from adafruit or seeedstudio anymore; as they have ran out of stock a while ago

I have been working with Yocto for a couple years and embedded Linux for 10+ years and I mostly learned according the description of option 1. In retrospective I wish that I had taken a couple of courses as it probably would have saved me alot of time. Yocto has many pitfalls and if you do not have prior experience with building for Linux that is additional domain that you need to understand before even starting with Yocto.

I normally recommend the following book for anyone entering this field.

https://www.amazon.de/-/en/Chris-Simmonds/dp/1784392537

The author of the book also does trainings which might be worth checking out.

Another good place to look for trainings/courses is the following (virtual courses at the moment) :

https://bootlin.com/training/