Best posts made by MK

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 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