As a workaround, you could use software SPI instead of hardware SPI. Unfortunately you'd need to re-route the SPI connections to different pins, as the hardware SPI pins can't be switched to GPIO because SPI is needed for accessing the flash. For SW SPI just load the spi-gpio-custom module for example like:
After this, you have a 100kHz SPI bus at /dev/spidev1.0 using GPIO0..3 for CS/SCK/MOSI/MISO in that order. For the mode parameter, see spi.h. I'm using this in several Omega2 based projects successfully.
Doesn't seem to have completed successfully.
When it's finished, it will print "Done" and reboot, similar to this:
____ _ ____
/ __ \___ (_)__ ___ / __ \__ _ ___ ___ ____ _
/ /_/ / _ \/ / _ \/ _ \ / /_/ / ' \/ -_) _ `/ _ `/
\____/_//_/_/\___/_//_/ \____/_/_/_/\__/\_, /\_,_/
W H A T W I L L Y O U I N V E N T ? /___/"
Glad to see everyone is as excited about the Omega2 Pro as we are! :D
A few clarifying points:
The Omega2 Pro is an addition to the Onion family. We will not be discontinuing Omega2 and Omega2+ for the foreseeable future.
The firmware is an Onion-flavored OpenWRT 18.06. We will still continue to create firmware for the Omega2 family, and the OpenWRT 18.06 version will make its way to the Omega2 and Omega2+ in the short term.
There is an option to the "call" procedure when logging from Python:
# Log messages to "LOCAL0" facility
# Write something to the logfile
syslog.syslog(syslog.LOG_INFO, "This is a logged message")
You may then filter these from the shell:
root@Omega:~# logread -l 800 | grep "local0"
Thu Dec 13 09:02:24 2018 local0.info log.py: This is a logged message
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.
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).
The missing 'inet addr' in the latest ifconfig output would indicate that the device has not successfully received an address via dhcp from your AP, so it isn't successfully connected.
I can replicate this by using an incorrect password when trying to connect to my AP. ie. iwconfig shows a successful looking apcli0 entry, while no inet addr on the same interface reflects in ifconfig.
Perhaps try removing the wifi network and re-adding it?
Or some additional log info may help diagnose further?
I was using a JSON file to store data from the script. I don't know why it took me so long to do this, but I included the logging for the script in cron and an error was generated indicating that it could not find my JSON. It appears when running the Python script from the shell, it must use the working directory. I included the full path in my script and it works now.
Though, I have no idea what changed from yesterday to today...
Tip of the Day: Use the logs to help diagnose an issue. They are terribly useful.
My recommendation is using NodeJS. I use NodeJS with Azure IoT Device and I dont run into any storage size issues. One little trick I found, install all your modules in /tmp, then move the node_modules folder to / . The folder will be highly compressed once its in flash memory.