
If I were in your shoes, I would start with: Or your coder is writing based on GNU assumptions or bugs that aren’t present or don’t operate the same way.

In theory they provide the same functionality, but there are all kinds of tweaks and differences between them that perhaps you are encountering. Your MiniPC may be complining against GlibC vs Musl or whatever option is being used on your GLInet firmware. You also have the whole slew of “cross compiled using an entirely different tool chain” to consider. I have seen times where problems arise with serial communications on MIPS hardware simply because the interface was written poorly and the timing the device expected was not being adequately delivered due to lower CPU power/processing speed of the MIPS board. Wondering how I could find the reason for these problems.ĥ2 42 36 00 01 21 50 B0 0E 0A 12 09 02 00 58 9FĠC 00 65 15 97 00 71 05 3E 1B 28 07 00 00 00 00Ġ0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Ĭan anyone share how I could monitor the communications to get some idea of where these errors are coming from.Īs Entropy512 pointed out, there are a huge number of possibilities here since you’re talking about a custom piece of code, talking to a custom hardware device.Ĭomparing to code running on a MiniPC is not really relavent, other than proving that the device/software combination works in that specific scenario. I compared this to some Linux devices I have (mini PC’s) and they do not show these errors. On all of the gl-inet devices I’ve tested, they show CRC errors. Opkg install kmod-usb-serial kmod-usb-serial-ftdi kmod-usb-uhciĮcho 0260 00a4 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

The software is a custom one that someone is building for me. No matter what I do however, I keep getting CRC errors with the communications. I have been testing gl-inet devices for the past few days, mostly the ar150m and the ar300m to see if they could be used with a temperature sensor that I need for customers.

I’m not sure where else to turn at this point.
