Nice! This can indeed save some dev time!
@Lazar-Demin : I'm for PoE as well. Lot's of my applications need connectivity without having power availability. It's much easier to install a simple RJ45 cable than a new wall socket...

@crispyoz : I have a PoE board (with a bunch of other features you probably do not need: RTCC, Touch screen interface, RFID reader etc...), don't hesitate to get in touch if you're interested. Other features can be stripped away.

Hi Community,

I've been developing a new device embedding an Onion Omega 2S+ with the need of a small (3,5") touch screen. First, I had a look at the Omega Dash (which seems to be the first choice as many functions are already integrated). However, I ran into 2 main issues:

• First: As I'm much more comfortable using Python than C, I had some issues really getting the hang of LVGL.
• Second: The resistive touch screen, didn't really quite fit my requirements regarding "quality". A capacitive touch would be much nicer.

I had a look at several posts from this forum, and noticed many people where looking for touch solutions. However, I didn't find anything regarding capacitive touch....

I therefore went on the hunt of a capacitive touch solution which I could handle with the Omega. Requirements are as follow:

• 3,5" capacitive touch (not resistive)
• Cover Lens Bezel
• Reasonable price
• Drivable with some Python code

After a lot (I really mean a lot) of research, I finally tested a solution from 4D Systems: https://4dsystems.com.au/products/. This Australian company offers quite a lot of different screens and controllers. I finally chose a 3,5" touch screen which can be driven by their diablo 16 controller: https://www.mouser.fr/ProductDetail/4D-Systems/DIABLO16?qs=0lQeLiL1qybL%2FKx9ffo26w%3D%3D

This solution needs quite a bit of custom PCB design, but as my device anyway needs a custom PCB, it wasn't a real hastle integrating the diablo 16 onto the board. The nice thing here is, all the heavy lifting is done by the controller, which directly interfaces with the Omega with a simple serial connection. So once the hardware is done, just get out the Diablo 16 documentation and start writting serial commands....nice.....

Here are my conclusions to this project:

Advantages:

• Super easy to use, once the hardware is integrated. Just write a simple code in the language of your choice (Python in my case) and start talking with the Diablo16 via UART!!!
• 4D Systems offers a free IDE called 4D Workshop enabling a drag and drop style interface in order to design your screen. Again this is super easy and terribly reduces dev time!
• The result is great! The look of the screen and the touch interface are really excellent. The touch response is really fast and gives the user a good experience.

Disadvantages:

• You do need to make a custom hardware. However, I think 4D also offers some intelligent displays directly integrating the controller. This will also require some hardware dev but probably less complexe as directly integrating the controller onto your board.
• All the static data (images, fixed texts, screen layout etc....) is not stored on the controller. The controller accesses this data on an external MicroSD card. This implies two things: You need to integrate this onto your board and you need a high quality industrial grade MicroSD card if you want your product to last.
• As the screen layout is directly written onto the controller and the MicroSD, you cannot perform any remote updates.
• For a final system, you need: Screen + Controller + MicroSD Card + a bunch of other passive components... All this adds up to a certain sum $£€.

Not sure this will meet the requirements for other projects, however for my purposes, this was a great solution enabling a really nice looking device, development simplicity at a reasonable cost. I tried to attach a small video of the screen interaction, this however failed in this post...sorry.

My device as such bundles some other features:

• Ethernet connectivity
• POE (This is really cool as sometimes I need to deploy this device where there is no AC access, and deploying a simple Ethernet cable is wayyyyyy easier than a 220V power line :-))
• 13,56MHz RFID reader (Serial connection with CR95HF controller from ST)
• RTCC chip (MCP7951X from Microchip) with minimum 3 days backup power storage. This is in case power and internet connection would fail simultaneously. The chip is connected to the Omega via SPI.

I'm a little short on time, but I'll try to post some more infos regarding these other features.

Best,

Hi,

I never really found an alternative to just run the code directly on the Omega and use "standard" debugging techniques like "print". We try to work as follows:

• Create a python script which can be mainly tested on the dev machine (PC, Linux, Mac...whatever you are working with)
• Ensure a good logging mechanism in the script in order to be able to write debug infos into log file (always a good thing even once your in production and need to debug a device)
• Once your script is done to 90%, finish debugging on device.

If you find a better solution, I'll be glad to ear from you :-).

Best,

Hi Community,

Just an update on this. Thanks to @crispyoz , I had A LOT of really interesting documentation to read. So this is how I would summarize my investigations:

• Point 1 was that after dumping a 2,967MB file into /root, the du -h command showed a total additional storage usage of 5,8MB (3MB in /root and 2,9MB in /overlay). As I understand, the overlay FS is a union of 2 filesystems. In OpenWRT the two filesystems will be /rom containing the rootfs and /overlay which will be the actual storage space. As in my understanding /root is uncluded in /overlay, this explains why the du command counts the used storage as double.

• Point 2 was that the df command however only returns an additional storage usage of 0.8MB after dumping my 2.967MB file. I couldn't find any explanation for this in the OpenWRT specific flash layout. However, some dark memory popped into my mind regarding JFFS2 and compression. Following Stackoverflow post seems to confirm my thoughts:
  https://stackoverflow.com/questions/31622039/jffs2-filesystem-storage-usage-inconsistent-with-real-file-size

To conclude:
1 - It seems du and df commands do not calculate storage the same way. du seems to add the individual file sizes, whereas df seems to take into account the "real" used flash storage taking into account JFFS2 compression algorithms.
2- This makes it quite difficult to evaluate remaining storage. For my projects I think I'll go over to practical use cases with max file sizes (+ some safety) in order to make sure my applications do not run out of storage.

Open Points:
1 - Does anybody know where I could find the Omega specific flash layout (just out of curiosity in order to cross check it with the standard OpenWRT flash layout found here: https://openwrt.org/docs/techref/flash.layout#explanations)?
2 - I think the Omega Flash in of NOR type. I however was unable to find any official datasheet confirming this. Does anyone have this kind of ressource?

Hi Community,

I was wondering how to create custom apps for OnionOS. Except for some dead links here (https://onion.io/the-onion-app-sdk-is-here/), I haven't found any kind of documentation. I'd like to create a simple administration app on a browser available GUI. I'd like to use the OnionOS environnement. Else I'd have to build a full server in Django or something (don't know if Django even runs on the Omega).

Thanks,

MK

@Lazar-Demin Thanks for this!

@Lazar-Demin : Thanks a lot. It took us some time to finalize this dev :-). Correct: The MicroSD only is accessed by the display controller. However, over serial commands from the Omega to the display controller, you can interact with the display itself. I'm pretty fond of this, as just dumping some serial commands really is easy.

I therefore have two MicroSD slots on the board. One is reserved for the display controller and only accessed by it. The second one is connected to the Omega2S+ and serves as memory extension.

If this can be an interesting solution for you, don't hesitate E-mailing me. I'll send you a proto board.

Best,

MK

@crispyoz : Thanks for this. Didn't really want to change rc.local as this is for me a "production file". Changing something in production isn't really easy from a process point of view

However, I guess DTS are compiled somewhere in the Firmware....so making a change here won't be easy either.... I'll probably then go for the change in rc.local and hope it won't mess up things in production

Hi Community,

I recently bricked a couple of omegas (was clearly my fault as we used rubish power supplies which just stopped working during firmware Update).....Omega does not like this

However, I loaded a new firmware onto the devices via USB and by fiddling a fancy FTDI serial converter onto the device in order be able to enter some commands.

Everything is fine now, except that the UART2 output is by default set to GPIO (and I need it to be a serial port). Using omega2-ctrl gpiomux set uart2 uart works, but this will revert at the next reboot....

Before the manual firmware Update, UART2 was set by default to UART, now it is set by default to GPIO.

How can I set the default back to UART?

Thanks,

MK

Hi,

I never really found an alternative to just run the code directly on the Omega and use "standard" debugging techniques like "print". We try to work as follows:

• Create a python script which can be mainly tested on the dev machine (PC, Linux, Mac...whatever you are working with)
• Ensure a good logging mechanism in the script in order to be able to write debug infos into log file (always a good thing even once your in production and need to debug a device)
• Once your script is done to 90%, finish debugging on device.

If you find a better solution, I'll be glad to ear from you :-).

Best,

@crispyoz Thanks for the return of experience. But I understand you are using your own OS images and not the ones from Onion. The latest firmware (up to November 2024) was 0.3.4 based on OpenWRT 18.06 and now they made a jump to OpenWRT 23.05. Correct?

Makes sense......
https://en.wikipedia.org/wiki/Year_2038_problem

@luz : Thanks for this. I'm running the firmware version 0.3.4 (running OpenWRT 18.06) which is the latest version before the newest OpenWRT 23.05 released by Onion in October this year. I do not wan't to switch to 23.05 as according to the docs quite relevant changes have been made, and I do not wan't to affect my firmware.
So basically, I can either run a OpenWRT Version 18.06 with the date issue or switch to 23.05 which will be a huge hassle....

Any idea?

Hi Community,

Came accros this interesting phenomenon:

Setting a date doesn't work after 2038. This is not sooooo far away, and there is a good chance, some devices going into the field today will still be working in 15 years.

What might happen, when this point is reached? Couldn't find anything related to this issue.

Nice! This can indeed save some dev time!
@Lazar-Demin : I'm for PoE as well. Lot's of my applications need connectivity without having power availability. It's much easier to install a simple RJ45 cable than a new wall socket...

@crispyoz : I have a PoE board (with a bunch of other features you probably do not need: RTCC, Touch screen interface, RFID reader etc...), don't hesitate to get in touch if you're interested. Other features can be stripped away.

@crispyoz : Great! Thanks a lot!

Hi Community,

Has anybody figured out if it is possible to grand the access to the OnionOS to another user (other than root)?

Thanks,

MK