Posts made by Maximilian Gerhardt

Already discussed in http://community.onion.io/topic/1671/compiling-lede-on-windows-10

@Max-Mitchell If you have installed the cross-compiler tools, mipsel-openwrt-linux-as is there alongside with mipsel-openwrt-linux-gcc which can also compile inline assembler. This definitely works, as I have programmed the Omega2's DSP coprocessor with SIMD assembler instructions

@alejandro-neujovics Maybe it's easier to you to write the driver in C/C++ and call the executable from nodeJS?

@Carst-Dan Have you tried the repos listed in https://docs.onion.io/omega2-docs/c-compiler-on-omega.html?

@alejandro-neujovics Best way would be to port the Arduino driver at https://playground.arduino.cc/Code/LCD12864 to JavaScript (if you have access to the SPI bus there at all..)

@Rhys-Jones Which device exactly are you plugging in? If you plug it in on a Linux PC, what does dmesg say? This should give you the info on which driver is needed.

@Yvan-Gagnon What package are you trying to install? What is the contents of your /etc/opkg.conf?

@Yvan-Gagnon opkg update and retry.

@Don-Elwell I've wondered about the same thing when thinking about an Omega2(S) with a PCIe graphics card Let me know if you find out something..

@Lazar-Demin Great to see it working. If you need a gateway you can also use a ESP8266 NodeMCU board with another RFM95 module and configure and flash the https://github.com/things4u/ESP-1ch-Gateway-v5.0 firwmare on it, also see http://things4u.github.io/. Needs a little bit of fiddling around with the configuration and pinout; Also be aware that the EUI of the TTN gateway must be the one that the firmware spits out on startup (it's made up of the ESP8266's MAC address and two 0xff in the middle).

So what exactly are the problems you have, and what code are you running?

@Brian-Franklin said in I2C and C++:

so then I copied the libraries reference above from
https://github.com/gamer-cndg/omega2-libs
put them in the /sources/minitest2c/ directory
same errors(s)

You should temporarily rename the .so libraries

// confirmed /usr/lib/liboniondebug.so exists
// confirmed /usr/lib/libonioni2c.so exists

to something else so that the linker doesn't attempt to link against these. Then add -L . to the compiler options to add the current directory (.) to the linker search path.

@Brian-Franklin What exact code are you running and what exact problem do you have?

As linked in the repo, https://github.com/OnionIoT/i2c-exp-driver/

Did you recompile the .so from source or did you copy the from your Omega2? Because the latter never worked for me. (see https://github.com/gamer-cndg/omega2-libs)

Actually when you follow my kernel modules tutorial it will also compile the kernel and give you the upgrade and flash .bin images. Clone and see https://github.com/OnionIoT/source#using-a-linux-system.

In https://github.com/OnionIoT/fast-gpio/blob/master/src/fastgpioomega2.cpp, the FastGpioOmega2() constructor calls _SetupAddress(REG_BLOCK_ADDR, REG_BLOCK_SIZE); which open("/dev/mem", O_RDWR), then mmaps 1024 bytes starting from the given base address. The result tof the mmap is stored into regAddress and based on this memory-mapped address the program accesses the registers. So the file handle is not needed anymore and is closed.

The mmap-ed block should later freed using munmap() but the code doesn't do that. However, it should still work.

I.e. I don't see a problem with the library code. What is the application program you've written to access GPIO15?

The entire main SoC is the same, 580MHz MIPS (MT7688) with 128MB DDR2 RAM. The Pro Version is the Omega2S+ with a 8GB eMMC and a LiPo charger, with a 384 MB swap file from flash to expand the RAM (already described here) and a few Dock accessories for the USB-Serial and power part.

I see no reason why the firmwares for the Omega2+ and the Omega2 Pro shouldn't be compatible with each other, please correct me if that's wrong.

And using the same SoC with the same silicon bugs for the SPI also means we'll inherit the exact same problems with full-duplex transfers there.

Nice project idea. But why abandon the Linux OS and all the peripheral drivers and start everything writing from scratch? For the sake of a pure speed advantage or wanting to learn MIPS assembler? I feel like doing a UBoot bootloader + using baremetal C/C++ combination would have very similiar performance and be way more feasable to program.

Still as soon as you want something like USB for Audio you probably don't want to re-implement the USB stack and USB peripheral driver from scratch. Or multitasking. (maybe use FreeRTOS on an Omega? ;))

How is data shared between the Omegas? You say you have a 'combined RAM' but the memory / data bus of the Omega isn't exposed? How are they going to have shared memory?

As for the video output, I think the fastest way to output the framebuffer would actually be USB because of its highest available bitrate. That's why I started using USB display adapters (here), they have an ok performance for low resolutions (90FPS @ 160 × 144 @ 16bpp) but need substantial optimizations for higher resolutions. I did rendering to SPI displays here.

Or:

• use the even higher-speed Ethernet peripheral and an FPGA to render to a SPI display an HDMI encoder chip
• write framebuffer into shared RAM or a dedicated RAM which a FPGA renders out

The only problem I see with graphics / 3D performance is the missing GPU. Everything has to be done in software. Maybe you can at least accellerate a few 2D operations with DMA acellerated copying though. I was using software-rendered OpenGL here (MESA 3D).

The whole thing sounds a like a modern Nintendo64 (64-bit MIPS CPU @ 93.75MHz for game logic, 64-bit Reality Coprocessor @ 62.5MHz as GPU, audio processor, I/O processor, loadable with custom Microcode for programming the rendering stages), just that we have two 580MHz 32-bit MIPS cores now (with a 64-bit DSP).

links with it are very welcome

Only datasheet of the MT7688 I know of is at https://labs.mediatek.com/en/chipset/MT7688 and https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/documentation, I'd gather the rest of peripheral drivers from the linux source code and patches (https://github.com/OnionIoT/source) or other bare-metal implementation (e.g. GPIO)

Anyways if you want to work together I'd be a happy about a mail.