@Alfonso-Blanco sh needs to be running indefinitely in the background. The command you need is probably something like sh > /dev/tty0 & More info on running commands in the background here. I recommend playing around with this just on the command line to get it working. Then once you've figured it out, you can add it to the rc.local so it runs at boot

@crispyoz I hadn't considered that, but it seems that getting the display connected to the Omega LTE might be the better option, if it's possible: the Omega LTE is infinitely more compact than most LTE options I've seen and having all of the network info available to software is a huge boon. From what I can tell the Omega Dash only differs in that it has the display adapter built-in, so if I can get the display connected to the Omega LTE and use the Dash drivers or OS, the LTE should be able to drive the display. Although I'm now tempted to grab the Dash and just plug in my display instead of the 3.2" and see if it works.

@Bohdan-Symchych : Must be possible, with a bridge. Please see this: https://www.latticesemi.com/Products/DesignSoftwareAndIP/IntellectualProperty/ReferenceDesigns/ReferenceDesign04/SPItoMIPIDPHY Thanks..

I think NO. It needs GPU. You can only make kernel objects (with DMA) to manual installation if anybody look for this. You'd better make I2S Sound Card support. If you need GUI, then sound needs too.

Can't wait to see more!

Hi Andrea Take a look at: https://developers.google.com/calendar/overview Personally i prefer python or php. You can use crontabs to trigger the 30min event. https://docs.onion.io/omega2-docs/running-a-command-on-a-schedule.html I don't really have any expirence with the calendar api, so I can't give you an example. But I hope this may give u an idea on how to start.

@Douglas-Kryder fair enough in that aspect

There are almost certainly ways to make this work, but they may take some non-trivial engineering. Understand and work around the SPI issues. They mostly have to do with simultaneous write/read operations and long transfers, both of which can usually be avoided at the cost of some efficiency Proxy the SPI through something else, for example a fixed-function chip (FTDI, etc) or a small MCU, hanging off either the USB or one of the UARTs See if you can use the I2S interface instead - this is normally meant to move audio data but it is not dissimilar to SPI. Many chips have offered functional blocks that did both SPI and I2S by configuring different details, which may be well within the range of what you can do with clever software Bitbang SPI on arbitrary GPIOs. Probably slow, though you can do the actually twiddling in kernel mode

@Alfonso-Blanco said in libili9225 - Controlling a ILI9225 SPI display with your Omega2: Hello Maximilian, Awesome! This is super useful. Im trying do to kind of the same but for a ILI9341. It's essentially the same, but changing the commands codes. What I've been trying to overcome (without success) is the malfunctioning of the SPIs MSB. I have had a peek at your code and it's mostly similar to mine. How did you overcome this issue? The funny thing is that for this particular display the bug doesn't matter so much -- when writing to registers, conveniently, the address of the important registers of the ILI9225 are in the range where the SPI transmitter doesn't exhibit the MSB bug. At the end of the initialization sequence though (setting the gamme curve), the bug occurs, doesn't however cause any harm. I've thought about a workaround for this, but didn't implement it yet (because it works without it it, too) -- You might be able to group register writes and such in groups of at maximum 16 bytes, and only the MSB of the first byte might be corrupted of it's from 0x40 to 0xbf. So, if the first byte isn't in that range (known good value), then the entire transmission will be bug-free. Thus you may be able to correctly write to a register between 0x40 and 0xbf be first placing a write to a lower reg (0x00-0x3f e.g.). Oh, and another hint: You can pretty much drop-in the initialization routine from here if that's where you're stuck @luz said in libili9225 - Controlling a ILI9225 SPI display with your Omega2: Great work! Thanks for porting the library! Just out of curiosity - have you tried the hardware SPI? There are issues with that, too (MT7688 hardware has a bug in full duplex transfers, and the driver needs a patch to at least support half duplex). The speed should be much better here (after all, that SPI bus is used to get data from and to the flash). Please, by all means, if you have any resources on how to easily use the hardware SPI interface on an Omega2+ from C, preferably without having to recompile / patch the kernel or firmware from scratch, I'd like to hear it. All I found was the spio-gpio-driver kernel module and library. I'd be great if you made your own project page about that if you succeed. This and another part of this project will benefit greatly from a faster half-duplex (TX only) SPI.

I have used this LCD and have gotten it to work with a tutorial here. https://www.amazon.com/gp/product/B01GPUMP9C/ref=oh_aui_detailpage_o09_s00?ie=UTF8&psc=1 This is how I got it working with the LCD https://wiki.onion.io/Tutorials/Python-I2C-LCD-Display You will need to get an expansion dock, power dock or mini dock or ardruino dock to really make it easy to work with. If you didnt, you can order one from the indygogo campaign.