Posts made by SpiderKenny

@crispyoz Thanks! That's an idea - I could probably just do a bunch of register level acces to initialise the display over i2c and put up something. I'll need to do a bit of learning on uboot

@luz Thanks - there's some things for me to think about there!

Hi everyone
I have built a device for a client that creates a kind of Network (UDP) to Serial convertor. It also does protocol convertion and scaling etc.

Anyway... it has an OLED display on board, and some buttons to present a UI.
Since the Onion takes about 1 minute to boot up, I was wondering how early in the boot process I could send some commands over i2c to the oled, so that something appears on the display early in the boot process?

I tried START=13 in my service file, but the difference between that and START=99 was minimal.

In other words... is it possible to use I2C and get something showing on the display early in the boot, if so, how early?

@crispyoz Great, thank you!

@MK If your application needs sufficient reliable storage, then is it a possibility for you to use the SD Card interface? That might be a better option.

Does your app write frequently to the storage? Does it over write frequently?
I don't know how much wear and tear the built in flash chip can take.

Trying to ssh from macOS Sonoma to Onion Omega 2S+ results in this message:

Unable to negotiate with 192.168.1.37 port 22: no matching host key type found. Their offer: ssh-rsa

Now, I know I can get around that by forcing the mac to use ssh-rsa by doing this:

ssh -oHostKeyAlgorithms=+ssh-rsa  root@<ip>

But is there a way to fix this permanently?

I'm using ssh-copy-id to copy my key to an OmegaS2+ so I can log in without a password from a known host.
It claims to copy the key successfully, but subsequent logins still require password.

kenny@totescore ~ % ssh-copy-id -oHostKeyAlgorithms=+ssh-rsa root@192.168.1.32
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/kenny/.ssh/id_ecdsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.1.32's password: 

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh -o 'HostKeyAlgorithms=+ssh-rsa' 'root@192.168.1.32'"
and check to make sure that only the key(s) you wanted were added.

Is it even possible to do this with Omega/dropbear?

@crispyoz BTW, in my C/C++ programming I usef the fastgpio library which uses direct register access. It's very quick and lightweight for accessing GPIO.

@crispyoz Thank you!
I've done a bit of PHP in the past too. I'll give it a try.

Hi I'm using Omega 2S+ at the centre of a new controller.
I'd like to create some custom web pages on the Omega such that I can see and control some GPIO pins, but I have no idea where to begin with the specifics.
(I mean I know how to write HTML, upload files to the Omeag etc, and I understand that the Omega is running uhttpd on /www. But I don't knwo how to access GPIO from within the html)
Is there a guide on how to access stuff like GPIO from within the webserver?

Did you try ssh root@hostname.local ?

See the difference it makes to ping on my setup:

I'm curious: How did you check that it is using half-duplex?
Full-duplex on anything with a Mediatek-7688 MCU won't work due to a silicon bug.
You can simulate full duplex by using two SPI transactions, a write, followed by a read, without dropping the CS line inbetween.

I use SPI from C++ on My Oemags S2+ without any problems. (In half-duplex!)

I recently moved some code over from a project I had running on HLK-7688A devices.
It uses RS485 to communicate with other devices.

I simply re-compiled the code using the Onion cross-compiler and it all seemed to work nicely.

Except one thing...
Every now and then I would get a corrupt message from a remote device. A chksum embedded in the protocol would not match, and ocasionally a length byte in the received bytes would be wrong too.
I thought it might be just a noisy RS485 line but when probing the actual RX line going into the Omega showed a perfectly valid signal.

On the wire the bytes would look something like this (in hex):

21 24 56 58 0D 00 01 00

But in the app the bytes being read() from the port would be something like:

21 24 56 58 0A 00 01 00

Thing is that the error was consistently the same error. Not like noise or random bits being flipped. Always the exact same corruption. I had never seen this before, this code had run fine on the HLK-7688A

It turns out that it was the terminal options I was setting on the file descriptor of the port I opened using open().
After opening the port with

fd = open(path, O_RDWR | O_NOCTTY | O_NDELAY);

I then use tcgetattr and tcsetattr to get the port options and modify things like the baudrate, parity, flow-control etc. I was using this:

options.c_iflag &= ~(IXON | IXOFF | IXANY);

But I had to change it to :

options.c_iflag &= ~(IXON | IXOFF | IXANY | ISTRIP | ICRNL);

To stop the pre-parser stripping the 8th bit from bytes and to stop it converting 0D to 0A (ie. CR to NL).

This is a bit of a simplified explanation, but it shows it pays to be careful with the options flags!
Funny how this never came up on the HLK-7688A - but they do use a very different build from OpenWRT.

Hi everyone. First time posting.
I'm folling the build instructions on github, and using the docker container.
When I run the command: ./scripts/feeds update -a
I get these errors:

Updating feed 'packages' from 'https://git.openwrt.org/feed/packages.git;openwrt-18.06' ...
fatal: unable to access 'https://git.openwrt.org/feed/packages.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
failed.

Looks like the root CA in the docker image is out of date?
Can I fix this?