@crispyoz I already did it but didn't work, got the same message

I cant find a library , every one sends bit value to control the pins , not that practical if i need to read and write from all the pins a a lot

@MickPF This depends on how you are doing your development. New players often start off doing some development on their Omega2x device, eventually, you realise this a short term solution since IoT devices are by design resource poor. The best way to do Omega2x development is to install the build system https://github.com/OnionIoT/source then you will have access to everything you need as well as the cross compiler, so you can use your more powerful desktop/notebook device for your development and then move the completed work to your Omega via scp/ftp. The headers and libraries you are looking for are on the Onion Github, https://github.com/OnionIoT Also refer to the docs on how to compile on the Omega: https://docs.onion.io/omega2-docs/i2c-c-library.html

@Pablo-Oyarzo There is protobuf and libprotobuf-c, I've started using libprotobuf-c recently but not much experience so far. To install edit /etc/opkg/distfeeds.conf uncomment line 5, run opkg update then you cna run opkg install protobuf opkg install libprotobuf-c Limited documentation is available on openwrt.org but since it pulls the code from Google's opensource github account you can find the docs there: https://github.com/protocolbuffers/protobuf

@Modest-Polykarpovich You don't need docker, as Windows 10 Home doesn't support Hyper-V but you can use other virtualisation products. VirtualBox will run on Windows 10 Home into which you install Linux, I use Ubuntu 18.

@luz Tnks, Corrected

I used libraries by modifying gpio, pyserial, urllib, getmac etc. You can try downloading libraries from docs.python.org. Copy lib to python/lib folders.

thank you for your response. I will try to interface using this library, and will provide the update

I had this exact problem and I'd also be very thankful for information on this! For the life of me I couldn't get any C programs to link against the .so files that are installable on the Omega2+. I always had to recompile or cross-compile every library myself (SPI, I2C, ALSA,..) to get the linker to work. Another interesting thing is that when you do file libonionspi.so it will say ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, corrupted section header size. As a work-around, I've uploaded the recompiled binaries at https://github.com/gamer-cndg/omega2-libs. But it feels like I'm missing something here that would allow for a successful linking with the preinstalled .so files.. Maybe a missing linker flag?

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

looking at your code, seems that might have a sync/async conflict. set() is calling async->spawn but get() is calling execSync() which will block. With a situation where you have reads and writes one of top of the other (such as a CLK/DATA pair of pins) have you run into an issue with the timing?

In light of this thread, I whipped up: http://community.onion.io/topic/2292/node-gpio-control-fast-gpio-wrapper

Hello, i have the same issue: root@Omega-0417:~# opkg install pyOnionI2C Unknown package 'pyOnionI2C'. Collected errors: opkg_install_cmd: Cannot install package pyOnionI2C. root@Omega-0417:~# root@Omega-0417:~# oupgrade Device Firmware Version: 0.1.4 b330 Checking latest version online... Repo Firmware Version: 0.1.4 b330 Comparing version numbers Device firmware is up to date! How to fix it? opkg update did not helped.