@sam-walton The easiest way to set the state of a GPIO at boot is to add the relevant command to the /etc/rc.local file. Depending on your requirements you would use something like gpioctl dirout-low 18
Pls try the sshfs extension, to see if that works for you.
MS always makes it "awesome"..
# onion os version (just FYI)
=== Version Info ===
Omega firmware: v0.3.2 b242
onion-os - 1.0.6-1
1: Set a passwd for the omega user to connect from your workstation over ssh, passwd is the easiest way.
Install SSH FS extension for VSCode in the VS
$ ext install Kelvin.vscode-sshfs
or DL the vsix & add to VSCode
SSH-FS shall create its own icon in the left panel, under "Soucre-Control","Extensions" etc. Click on it to setup the new ssh connection/credentials (IP, username, remote folder etc), pointing to omega.
Click on the "Folder+:" icon under the new connection entry.
This will effectively add the remote folder to the current workspace. You will be
prompted for the passwd, if that was left blank in #2.
The connection also gives a shell prompt.
Any file that is created under the newly added "remote" folder shall be created physically under the remote folder. "Save" to apply code changes.
The plugins (C/++, Python etc) that you have installed in your WS works as usual,
while you code.
My workstation is Linux, so there was no need to install any ssh client. If you
are on Windows, putty might work. I have not tried it.. but I guess it would work,
since I see "putty" mentioned in the configuration page of #2.
No, you're not the only one who stumbled across this. It's 5 years later, and the Omega still has issues joining and staying joined with, a network with apostrophe's in the SSID?
We are shipping 250 end items per year to paying customers - paying a lot, I might add. Anyone know of a solution that doesn't require a custom hack job into each product that has already been shipped? Anyone from Onion listening?
@luz Thanks. 5100ns Maxretries value(default suggested for ws2812 on readme Github) by this I meant the same as you said, could not convey though.
I checked the hardware design, we dont have level-shifter emplied. I will try with level shifter and let you know here.
I appreciate your prompt attention. Thank you @crispyoz @luz .
@dixit I just noticed this post after answering the other one in the p44-ledchain thread
Hearing that you had similiar problems with the ws2812-draiveris driver as with my p44-ledchain, I can conclude that the problem is most likely not the timing, but the hardware (missing level shifter?).
Because ws2812-draiveris always meets the timing for the WS28xx - as you might have seen when porting it, it simply locks all interrupts and then bit-bangs the data.
While this is good for meeting the LED chip timing (and simple to code), locking interrupts for dozens of milliseconds is a cardinal sin in a Linux driver. On the original AR9331 CPU (Omega1), where ws2812-draiveris originates from, this was the only way to get such SmartLEDs working at all, so ws2812-draiveris is as good as it can get on that chip.
However, on the MT7688/Omega2 with its PWM units, the p44-ledchain way to do it, without locking interrupts, is the way to go. And that works easily, at least with WS2813 or WS2815, with all 4 PWMs running in parallel with 1000 LEDs each.
I spent some time implementing refclk in my platform driver, but then I found that sound/soc/ralink/ralink-i2s.c seems to have all that done already. So it seems like my ultimate solution is just to comment out everything having to do with clocks and hardcode the expected 12 MHz frequency.
I forgot about Banngood. Went with this one:
Banngood always looks a bit suspicious to me but I did order some items there about 3-4 years ago and it did arrive. So, hopefully this sensor works ok.
Two years later: Just in case anyone runs into that problem, I found a solution that work from linux userspace:
In the kernel messages (which can be viewed with the dmesg command), there is a line like:
[ 0.358842] m25p80 spi0.0: w25q128 (16384 Kbytes)
or (in newer OpenWrt versions):
[ 0.639801] spi-nor spi0.0: w25q256 (32768 Kbytes)
This is a message from the spi-nor kernel driver after detecting the actual flash chip. So it is not dependent on the flash size that is baked into the firmware image, but shows the real size of the flash chip. Both of the example lines above are from a firmware made for the Omega2. The first is run on an actual Omega2, the second shows 32M so it is a Omega2+.
The only gotcha with this is that the dmesg buffer is not infinite and will loose older lines when too many new ones arrive. This means detecting the flash chip size needs to be done shortly after startup.
So I put the following line into a startup script (e.g. /etc/rc.local) :
dmesg | sed -n -r -e '/spi0.0: .*w25q/s/.*(w25q.*\))/\1/p' > /tmp/flashchip
With this, the chip name and size is captured and can be read any time later from /tmp/flashchip to detect an Omega2(S)+ vs Omega2(S).
Finally - Solved!
@CyrilSneer I have some string sitting on my desk. Can you tell me how long it is please?
This is the same as your question, there is no specific information so it is not possible to answer your question. As a first step perhaps you can share:
What language you are using (script/C/python etc)
A sample of your code
How you are building your code
What model Omega2 are you using
What firmware version you are using
All the basics
Looks like your connection to Community was lost, please wait while we try to reconnect.