Arduino core doesn't appear to be working

I received my NVME SSD drive a day early (yay Amazon!), got it installed, and then installed Ubuntu 18.04. That OS really makes this board perform well–very pleasant experience for this old Linux user! I’m sure Windows would be fine as well, but I prefer Linux.

That being said, I’ll continue trying to figure out this 4-pin header serial interface this week. @Baozhu, do you have any additional documentation you could give us on this little 4-pin header next to the Arduino header? My ultimate intention is to install i2c-tools and use the 40-pin RPi-compatible header to do some embedded projects, but it would sure be nice to have a UART to the main Linux OS. So maybe that’s what the 4-pin header is for, I’m thinking?

TB

@tcbetka no the UART on the 40 pin header is /dev/tyS4 in linux. so you have direct uart access like you would on a PI

1 Like

@tcbetka see this thread here for more information: Serial Port device names

Ah, great info…thanks. I will definitely check out that link tonight. I have installed i2c-tools, and probed the hardware. This is what I found:

https://pastebin.com/4rw9v93g

I tried to paste the output(s) here, but the formatting got all screwed up so I just used pastebin.com.

TB

you need the -r option on i2c-detect for it to show all the addresses.

OK, I had a look at that other thread. To your question about the 4-pin header’s Tx/Rx pins, he said this:

The ttyS5/6/7 serial ports are used internally, and they did not lead out on the hardware.

For the Rx/Tx on the 4 Pin, this is connected to the SAMD21, which means two hard serials can be used on SAMD21 of Odyssey X86.

…which doesn’t make sense to me since 1) nothing I tried yesterday showed any other output on the Tx pin, besides the clock-looking signal I showed in the one screen shot I posted yesterday (also posted in that other thread today), and 2) we know that the SAMD chip on this board has two UART ports–one of them appears to be SerialUSB, and the other (pins 1/3) seems to be Serial1.

So I’m afraid that unless I don’t understand something in that thread you referred me to, it doesn’t really give me any more information on the purpose/use of the 4-pin header. I see what you meant about /dev/ttyS4 though. That was helpful information, so thanks for that.

TB

@tcbetka yup exactly … i linked you to it as it gives a little more info then in here. either way, i’m no more as un-confused as i was when i started lol

you need the -r option on i2c-detect for it to show all the addresses.

Actually, that gives me no more information than I got without it. I’ve never used that switch, but I’ll research it bit. If there were 5 devices on that bus, they’d all show up without -r…at least in all the times I’ve used i2c-tools.

TB

Actually, according to THIS site, you don’t want to use the -r flag at all:

https://linux.die.net/man/8/i2cdetect

-r

Use SMBus “read byte” commands for probing (by default, the command used is the one believed to be the safest for each address). Not recommended. This is known to lock SMBus on various write-only chips (most notably clock chips at address 0x69).

Once we get the serial port dilemma solved though, then we’ll have to try to determine what device is at address 0x50 on bus 3, lol… That’s the standard address of a Bosch BNO055 IMU though, coincidentally. But I’ve never read anything that stated there was any sort of IMU built-in to this board, so it’s probably just that–a coincidence. But I bought an AtomicPi board, and it has a BNO055 on the board, as it was a board used for a commercially-available home robot assistant or something like that. But the project well belly-up, and there were a bunch of those boards that hit the market…so I bought two of them for like $40-45 apiece I think? Something ridiculously cheap like that.

Anyway, we’ll need to maybe get some help from the Seeed Studios guys on what might be living on i2c-3 at address 0x50. Maybe it’s something fun!

TB

@tcbetka i’ve never had to use it either, but for some reason (and with this board, who knows) a device i know that resided at an address that wasn’t listed int he i2c-detect but i knew was there didnt show up without the -r. run it on a real PI and it showed up irrespective

and using the -r flag is the safest way to probe for devices as it doesn’t write to the chip registers

1 Like

Yeah, that makes sense I guess. I’ve never used it, but the read-only thing might be beneficial on some non-write-only chips as mentioned on that man page I linked to. So I’ll keep it in mind.

I misspoke about the AtomicPi board before–the BNO055 was on bus 50 (i2c-50), but was at the default address of 0x28. The chip can also have an address of 0x29, if 3v3 is applied to the ADR pin. But I’ve always just used the thing with the default address. That being said, I am still trying to find some information about the Odyssey’s i2c buses. It’s like there’s a big black hole out there where this board is concerned though–but I’m sure I don’t have to tell you that, lol…

TB

1 Like

I did some more experimenting with the Serial ports today. However since this thread was officially about the lack of output on the serial port, which now appears to be solved if you use SerialUSB (and not Serial), I’ll just move my future posts regarding the serial issue to that other thread. But there’s definitely still an issue though…

TB