I can not make the serial communication using NodeJS work. Is there any success story about getting the serial comms on Omega using NodeJS?

I tried both serialport and much less popular serialport-js packages, but couldn't get to working condition.

The Omega is connected to Arduino using TX and RX pins, and I know there's no problem with the Arduino end, as the tests using Python are working fine. I just can't get anything working under NodeJS.

Wow, @luz, thanks, man! Got the thing working!

To complete the thread, here's what I did:

1. Implemented the "INIT" command in my Omega-Arduino serial protocol. Before receiving "INIT" command, Arduino swallows up anythin that is thrown at it, and does not return anything back. Only after the "INIT" command it starts to accept other commands and return responses.
2. I changed the /etc/inittab file, commenting out the line that makes openwrt await a login on the console:
   #::askconsole:/bin/ash --login
3. Edited the /etc/sysctl.conf file, adding a row at start, to prevent the kernel from writing any messages to the console:
   kernel.printk = 0 4 1 7

Ok, I can report some success:

On my Linux Ubuntu, I've created an empty dir, created package.json file with contents:

{
 "name": "Express4Omega",
 "version": "1.0.0",
 "description": "Testing the Node.js+express on Omega platform",
 "main": "index.js",
 "dependencies": {
   "express": "4.2.x"
 }
}

Then ran $ npm install --no-bin-links, to let the npm get the packages and put them in the local node_modules dir.
After the npm was done installing, I created an index.js file with the hello world example.

Then copied the folder to Omega, and ran # node index.js, and the hello world example is served from Omega just fine.

However, with node and express installed, the flash memory of Omega is pretty much full: 14.292 MB / 15.232 MB. My little project will squeeze in the remaining 1MB without any problems, but there's very little room for any extra packages should your project require any.

@Adam-Watts, since the storage space on Omega is fairly limited, I did not install any Python package manager. If you use a module in one project, then its ok to copy the module folder in your project root.

Here's my file tree:

/root/myproject - project folder
/root/myproject/serial - pyserial module, "serial" folder copied from http://sourceforge.net/projects/pyserial/files/pyserial/2.7
/root/myproject/main.py - python script that does your stuff

In you main.py file, you can then just import serial and Python will know that it has to look in the working directory for the module folder.

Now that I've made some stuff on my Omega, I'd like to develop a nice web interface to interact with it. Of course, I can make my custom script listening on a custom port, but it would be cool to see my app appear in the Onion Console.

Is there some guide, how to achieve this?

Ok, I was avoiding the oupgrade -f because of dire warnings about unstable versions.

@Lazar-Demin said in Omega2+ SPI in Python3:

We haven't done a good job of publicizing that so far. Where can we post about it so that more users are aware of the change?

I think this would be a very appropriate place: https://docs.onion.io/omega2-docs/using-the-omega-updating.html. If I prefer to stick with stable firmware version, perhaps I could just update the repo URL.

Now that I have set up the serial comms between Omega and Arduino, the next step is to write some Python code that talks to Arduino.

Installing python is easy:

$ opkg update
$ opkg install python

But this does not install the Python serial library. I couldn't figure out which package should I install to be able to do import serial.

Dammit, you're right! I should've checked the time scale on the crippled diagram.

But now I stumble on the next problem. I connected my APA-102 RGB LED strip to the GPIO pins 7 (CLK) and 8 (MOSI), and it appears that this connection causes some bad interference with Omega:

• At boot, about 20 of LEDs are lighting up and twinkling, showing that there is some data being sent out of SPI. Since I am not using the CS1 pin, my interpretation is that the data that is meant for SPI device 0, now is captured by the LED strip (it says here, that "..device 0 (CS0) is connected to the flash memory used by the Omega").
• Omega is working with random glitches, perhaps the communication with device 0 is being messed up.

Perhaps I am missing some simple fix here? Perhaps I should let the LED strip receive signal from MOSI only when CS1 is high?

Ok, thanks, I will use this python module for now, and stick with Python 2.7 until you release the Python3 version.

Ok, I think I will move on with first driving the strip from Arduino Micro, connected to Omega via serial. That will get me started sooner, as I see the "hard way" requires some extra tinkering without guaranteed results too soon. But the lights must go up or it will be too late.

Once that fallback setup will be working, I will have the safety for tinkering with lower level Linux code where I don't feel so much at home.

Thanks for suggestions, and I will report back my results!

I supply power via the dock's GND and 5V pins. I now tried to power it from USB socket, and the behaviour is the same — device heats up, power LED does not go on.

With or without the Omega2+ plugged in, the voltage across GND and 3.3V pins is lingering around 3.28V.

My project was working just fine, but then my Omega2+ suddenly halted. When I checked the device, it was pretty hot, so I assume the poweoff was some kind of automatic safety measure.

So I switched it off (the expansion dock switch), waited for the device to cool off, switched on again, the amber LED went on, then blinking while booting, then stopped blinking, just like normal boot sequence. But the device nevertheless started to heat up again, and after short time the power LED went off.

So I plugged in my multimeter to measure the current draw, and it shows 0.4A at this emergency-poweroff state, 0A when the expansion dock switch is off, and 1A when I switch it back on. Now the onboard power LED does not go on anymore.

The power source is 5V switched-mode power supply, there's no reason to think that it's not stable.

I my Omega2+ dead? Is there any way to find out for sure? A very disappointing and bitter end to a project that was supposed to go live for Christmas.

Ok, I was avoiding the oupgrade -f because of dire warnings about unstable versions.

@Lazar-Demin said in Omega2+ SPI in Python3:

We haven't done a good job of publicizing that so far. Where can we post about it so that more users are aware of the change?

I think this would be a very appropriate place: https://docs.onion.io/omega2-docs/using-the-omega-updating.html. If I prefer to stick with stable firmware version, perhaps I could just update the repo URL.

I am running 0.2.2

# oupgrade
> Device Firmware Version: 0.2.2 b200
> Checking latest version online...
url: https://api.onioniot.com/firmware/omega2p/stable
> Repo Firmware Version: 0.2.2 b200
> Comparing version numbers
> Device firmware is up to date!

I am not sure how I can upgrade to v0.3.0, if oupgrade does not propose it. The image repo http://repo.onion.io/omega2/images/ also does not contain any v0.3.0 images.

Ok, so I thought it's a good time to move my project to Python3. It's an APA201 RGB LED strip controller, written in Python.

Official doc https://docs.onion.io/omega2-docs/communicating-with-spi-devices.html encourages to use spidev module. The readme of the official github repo of spidev https://github.com/OnionIoT/python-spidev says that I should install python3-spidev package.

However, if I write opkg install python3-spidev in the command line, all I get is this error:

Unknown package 'python3-spidev'.
Collected errors:
 * opkg_install_cmd: Cannot install package python3-spidev.

What am I missing? Can the python3-spidev package be installed in another way?

P.S. Yes, I did the opkg update, of course.

Yeah... you're right:

# nano -V
 GNU nano, version 2.7.5
 (C) 1999..2016 Free Software Foundation, Inc.
 (C) 2014..2017 the contributors to nano
 Email: nano@nano-editor.org	Web: https://nano-editor.org/
 Compiled options: --enable-tiny --disable-nls --disable-utf8

I just installed it from an opkg package. Is the only way to fix this is to build it locally?

I also tried very hard to get I2S sound working on Omega2, but could not. So I gave up and moved my project to Raspberry Pi Zero.

When I log in over ssh (from Ubuntu), I can write unicode symbols like ĀĒŠ just fine. Also, if I cat a utf-8 encoded file that contains such characters, it is outputed correctly.
However, if I open the nano editor and attempt to enter a Unicode character, it is not displayed corretly. In fact, two or even three characters are outputed to the screen, and If I attempt to enter some other characters on the same row beyond the place where I inserted the Unicode char, then the cursor is displayed not exactly where the new characters appear, it's messed up. If I save the file and cat it out in console, the Unicode character is outputed correctly. I assume that those several characters is utf-8-encoded representation of that character, for some reason not processed correctly by nano.
What could be done to fix this?

P.S. I just checked the file opens nicely in the Onion console editor app, all Unicode characters displayed correctly. However, if I use the http Onion console terminal app, the behavior is exactly the same: can write the characters in the shell, can cat a file with those characters, but entering and displaying them in nano does not work.

@luz Thank you, I finally solved this! Ordered bunch of 74HC125D chips, there are four gates per chip. I pass through the gate only the CLK line, assuming that any MOSI traffic will be ignored by the strip when there is no CLK. So far so good, it seems that both flash memory (device 0), and LED strip are working just fine.