Dear Onioneers,
I have an unused Bluetooth LE Expansion that I would like to trade for an Ethernet Expansion for the Omega. Any takers?
Dear Onioneers,
I have an unused Bluetooth LE Expansion that I would like to trade for an Ethernet Expansion for the Omega. Any takers?
@Kit-Bishop Unfortunately, I'm not using pwm. I'm just doing straight pin on, and off calls, as well as reading states. The equivalent of 'fast-gpio set 6 1' for instance, to set the 6 pin to on at 2.xV. Multiple set 0/1, get-direction calls across several pins usually causes the lock-up, but there's variability in exactly when the lock-up occurs. That's why I think it's some sort of I/O buffering overload.
@Kit-Bishop @Boken-Lin Could you write-up a quick guide to setting-up a swap partition? I think the bones are in this thread, but not the full guide. I have compiled make, m4, and autoconf from source on the Omega, and have successfully installed them, as well as a few other pieces of software. However, building and running bigger tools like SWIG, likely needs swap. I intend to use SWIG to generate a Ruby extension for the C++ new-gpio lib. BtW, other than running a little slow, the Omega is a fine build machine.
I have been experimenting with fast-gpio. When called from the shell, hand-inputting one command at a time, it is fine. When called from a ruby or python script, through shell calls, sometimes after several calls to fast-gpio in a row, the script freezes. This does not crash the Omega, but does render the process a zombie, and I have to background it, and then kill -9 it. I experienced perhaps a similar phenomenon when trying to use file reads and writes to the sysfs virtual gpio files, and after multiple operations the program would fail with fptr errors. There's something very BETA about the gpio support at this point in firmware 0.0.6 b275.
Any ideas? My next step is to use SWIG to wrap the new-gpio C++ code, and then access that from Ruby/Python. Somewhat of a hack, but maybe the new-gpio lib will take care of whatever is overwhelming the controller by the way I'm trying to do things now.
If you use external memory as an overlay, there is no reason you cannot use the Omega as a fill fledged computer to compile binaries. I'm looking for a solution on windows where I do not have to set up a VM instance with some flavor of Linux just to cross-compile software for the Omega. Anybody have a more creative solution? Could someone at Onion please just make a build tools opkg (with make and autoconf binaries)?
Is there an opkg for make and other build tools? gcc, etc. are not very useful for compiling ported code on the Omega itself without make, autoconf, etc.
Is there a reason that once we've added additional storage via overlay that we couldn't install a full gcc and associated build tools (make, autoconf, etc.) on the omega itself? I have gcc on there, but can't find a way to get make, etc. onto the little computer so I can compile other Linux software I want to port to the thing. Is there some hidden opkg of build tools I just don't know about?