Posts made by JP Norair

That works, thanks. Would be nice if this link were in the documentation!

Does anyone know where to find this?

It's not in the archives.
https://docs.onion.io/omega2-docs/manual-firmware-installation.html

However, it's the last known firmware build I've used that kind of works with ttyS0. Newer builds simply don't work with UART over ttyS0 -- I think it's a conflict of something in the musl library and I desperately wish for a uClib variant of the FW -- but that's beside the point. Right now I just want b202 so I can have again an almost-working solution.

Mosquitto is on the default Omega 2 image. You may be able to use it rather than Paho, depending on your workflow.

I'm fiddling with the onion firmware buildroot, trying to solve some issues I believe are due to usage of musl as libc. I'll come back to this in a future post.

Anyway, I've noticed that MT7688 is in fact a MIPS24KEC, not a MIPS24KC, with the E meaning it contains the DSPr1 ASE from MIPS. Therefore, we should be able to compile with the following flags in gcc:

Target Optimizations:
-Os -pipe -mno-branch-likely -march=mips32r2 -mtune=24kec -mdsp -mfix-24k

Extra Optimizations
-fno-caller-saves -fno-plt -ftree-vectorize

I'm curious if anyone has tried these options, and if there are caveats. Code compiled with 24kec (and the dsp instructions) should run and link fine with code compiled for 24kc, but just broadcasting this out there.

On the onion, you need to put the keys in /etc/dropbear/authorized_keys. Maybe you're doing this -- it's not clear. I can say is that I use rsync to upload my distro to Omega2+, and it works. So whatever you're doing is fixable.

@James-Penick Do you mind if I contact you outside the Onion forums? You can send me a Linked-In page and we can work it out from there, if it makes sense. I want to ask you a few things that are outside the scope of this forum.

Hi James: I've had enormous trouble getting Onion Omega 2+ UART to work properly. There's clearly a bug somewhere, although it's hard to say where. We think it's in musl, but, regardless, it's not something easy to fix. The latest builds of the Onion firmware are especially bad. The present stable build works somewhat. This bug is actually preventing me from deploying Onions commercially.

Here's the thread from August that details this very issue.
https://community.onion.io/topic/3654/request-for-improvement-on-driver-for-ttys_-or-help-to-do-it-myself

You can try to re-deploy using the latest Onion build, which is running on the 4.14 kernel.

$ oupgrade -l

Be warned, though, I do not have good results running UART on this version. 0.2.2 b202 has other problems, but it is more stable for me.

@mawg You should see if it's possible to run GDB on your onion -- probably you'll want the Omega2 that has the most RAM, i.e. 2+. GDB offers things like breakpoints, stack-trace, read variables, capture on fault, etc.

https://docs.onion.io/omega2-docs/c-compiler-on-omega.html

Midway down this page, there's description on how to install gdb.

@crispyoz

Do you chuckle at people using electric and pneumatic tools to build things? We have these tools now, so you probably should use them. I don't suspect anyone is "unable to manage without [GDB]," but it makes the job a whole lot easier.

As for my development methodology, most-often the huge majority of time is spent on the mac, and it's much faster to iterate on a desktop than it is on an embedded target. One example of a problem appearing in a late stage of this process is my recent struggle with the tty driver on the Omega2, which wasn't obvious until running on the omega2, but this wouldn't have been any easier to deal-with had I been running directly on the target the whole time. There's simply a bug in musl.

Anyway, the theme is pretty simple: the best strategy is the one that yields the best result in the shortest time.

@crispyoz

Why would GDB be a last resort? Obviously, you would use it with a debug build. It will show thread calls and allow trace-back to the point of any crashes. If you're programming in C, that's helpful.

Anyway, here's how I write C programs for Linux. Most of which are multithreaded, via pthreads, and many of which access devices.

1. Set up an environment on mac using the libraries you'll need, but for the mac platform. Mac uses the XNU kernel, which is based on BSD, and it's far more reliable than most linuxes. Controversial, yes, but from my experience very true. Especially for multithreaded apps.

2. Code the software in XCode. XCode has the best linting and real-time error/warning detection of any tool I've ever seen. It runs LLVM/Clang underneath, which is has a compatible interface with GCC. You'll detect most bugs before you even build your app.

3. Run the software on mac. You can use lldb or gdb (I use both). lldb is somewhat more capable IMO.

4. Once it works on mac, get it running on a Linux desktop. Use GDB for debugging.

5. Once it works on Linux desktop, get it running on the Linux target platform (i.e. Onion). A nice I/O-driven test framework for this purpose is TAP (Test Anything Protocol).

I haven't tried to run GDB on the onion, although GDB is probably what you want to use for debugging the sort of software that runs above an OS (i.e. OpenWRT Linux).

https://openwrt.org/docs/guide-developer/gdb?s[]=gdb

I don't believe the Onion has an exposed JTAG interface. Nor would you really want to use it unless you were debugging the bootloader and/or kernel themselves.

I also use Mojave (latest release) and I have not had trouble connecting to Onion.

Perhaps, though, there is an issue in a driver for a specific WiFi device that was released in Mojave 10.14.6. What macs do you have?

@Jonathan-Rizzo

I figured this out myself, so hopefully it's all correct. But it works

1. Make sure your shell is in the source directory
2. Run: "./scripts/feeds install <<your lib>>"
3. Often this works. If it doesn't we will install manually.
4. mkdir -p package/libs/<<your lib>>
5. cd package/libs/<<your lib>>
6. wget https://raw.githubusercontent.com/openwrt/packages/master/libs/<<your lib>>/Makefile
7. cd ../../../
8. make package/libs/<<your-lib>>/compile
9. make package/libs/<<your-lib>>/install
10. make package/libs/<<your-lib>>/clean

More information here:
https://openwrt.org/docs/guide-developer/build-system/start

Secondly, this may be a cleaner way to do it, but I haven't tried:
https://navneetstudynotes.blogspot.com/2015/04/building-new-package-with-openwrt.html

For the sake of people who find this old-ish thread from internet search, the answer is that you’ll need to install libcurl in your buildroot toolchain, with headers and libraries.

On the omega itself, you can just copy the .so library files from your buildroot into /usr/lib (or wherever you want to keep them)

I’ve done this with several libs.

@christian-lacdael Will you be able to follow suit and write to /dev/spidev_ directly? This seems simple enough.

I have also had trouble with the ttyS_ drivers.

There are some problems with the way flushing works, but you can try using tcflush() in your code to clear the system buffers. This can cause other problems, but it also might work for you.

Do you have the code to the python task that's running?

Seems to me like there's a memory leak in the code of one of the underlying libraries. Maybe you can figure out exactly the line(s) of python that causes the leak, then we can fix the C library.

@Lazar-Demin

No: for size, cost, and power reasons we need to use the built-in UART(s).

I'm interested that @luz is having no trouble doing basically the same thing. It would be nice to know what he/she is doing that is different from what I am doing.

I will rebuild buildroot and see if this makes a difference.

@luz said in Request for improvement on driver for ttyS_ (or help to do it myself):

My versions are linux 4.14.95, musl 1.1.19 and openwrt 18.06.2

I compiled the buildroot in June, but I will try to rebuild it with whatever is the latest commit from GitHub. I'm wondering now if I was using the master branch, which would be the wrong branch to use by the looks of it. I added some of libs from the OpenWRT universe (libfts, libtalloc), but I don't think these would impact anything.

I was following the instructions here. There isn't an instruction about changing branches, so unless I built HEAD, it probably was master. I think Onion team should update the docs, if so.
https://docs.onion.io/omega2-docs/cross-compiling.html

Update:
No, the buildroot is from the 18.06 branch.

@luz are you cross-compiling or building on the onion? Maybe you could share your tty configuration. I've attached mine at the bottom of this post.

Another crazy thing I noticed on Onion is that signal(SIGINT, &handler_fn) will return non-zero if the process is launched from within a shell script. If process is launched from tty, it's fine. I ported my code to use SIGTERM instead, and to ignore the SIGINT handler. I'm curious if, somehow, this may lead to the issues.

static int sub_opentty(mpipe_intf_t* ttyintf) {
    mpipe_tty_t* ttyparams = (mpipe_tty_t*)ttyintf->params;
    struct termios tio;
    int i_par;
    int rc = 0;

    // first open with O_NONBLOCK
    ttyintf->fd.in = open(ttyparams->path, O_RDWR | /*O_NDELAY*/ O_NONBLOCK | O_EXCL);
    if (ttyintf->fd.in < 0 ) {
        rc = -1;
        goto sub_opentty_EXIT;
    }
    
    if ( !isatty(ttyintf->fd.in) ) {
        rc = -2;
        goto sub_opentty_ERR;
    }
    
    // TTY device has output and input on the same file descriptor
    ttyintf->fd.out = ttyintf->fd.in;
    
    // then reset O_NDELAY
    if ( fcntl(ttyintf->fd.in, F_SETFL, O_RDWR) )  {
        rc = -3;
        goto sub_opentty_ERR;
    }
    
    // clear the datastruct just in case
    bzero(&tio, sizeof(struct termios));
    
    // Framing parameters are derived in mpipe_opentty()
    ///@todo Currently ignores parity on RX (IGNPAR)
    i_par           = IGNPAR;
    tio.c_cflag     = ttyparams->data_bits | ttyparams->stop_bits | ttyparams->parity | CREAD | CLOCAL | ttyparams->flowctl;
    tio.c_iflag     = IGNBRK | i_par;
    tio.c_oflag     = CR0 | TAB0 | BS0 | VT0 | FF0;
    tio.c_lflag     = 0;
    
    tio.c_cc[VMIN]  = 1;        // smallest read is one character
    tio.c_cc[VTIME] = 0;        // Inter-character timeout (after VMIN) is 0.1sec
    
    tcflush( ttyintf->fd.in, TCIOFLUSH );
    
    cfsetospeed(&tio, ttyparams->baud);
    cfsetispeed(&tio, ttyparams->baud);
    
    // Using TCSANOW will do [something]
    if (tcsetattr(ttyintf->fd.in, TCSANOW, &tio) != 0)  {
        rc = -4;
        goto sub_opentty_ERR;
    }
    
    // RTS/CTS are not available at this moment (may never be)
    //if( flowctrl != FLOW_HW )  {
    //    if (rts)    tiocmbis(table->intf[id].fd.in,TIOCM_RTS);
    //    else        tiocmbic(table->intf[id].fd.in,TIOCM_RTS);
    //}
    
    // DTR is not available at this moment (may never be)
    //if (dtr)    tiocmbis(table->intf[id].fd.in,TIOCM_DTR);
    //else        tiocmbic(table->intf[id].fd.in,TIOCM_DTR);
    
    sub_opentty_EXIT:
    return rc;
    
    sub_opentty_ERR:
    close(ttyintf->fd.in);
    return rc;
}