@wx4cb, are you in Florida, by chance? Is that your HAM call?
Figured as much. KF9QL here, in Wisconsin.
I spent an hour or two down in my electronics lab this morning, working with the board and my Saleae logic analyzer. Here are some thoughts…
- SerialUSB.println() does work with the serial monitor, as you can see here:
I noted that “Spud!” didn’t appear on either the 4-pin header Tx/Rx pins, or the Tx/Rx pins of the 28-pin header.
- No matter what I send over the serial monitor’s output, I get this on the Tx line of the 4-pin header:
It appears to just be an asynchronous clock signal, but it never changes with any sort of data sent from the serial monitor’s output field. Otherwise both the Tx and Rx lines on the 28-pin header are logic level low during this time–which makes sense, given that I think it’s mapped to the Serial1 port (see below).
- Interestingly enough, I did get some activity on the Tx line of the 28-pin header, when I used the Serial1 object (Serial1.println()) and tried to send the string “hello world” across. But it was filled with framing errors and I never got the full string, like can be seen here:
I watched for 10-15 seconds, and never once got a full “hello world” string without errors. But it does appear that pins 1 & 3 on the 28-pin header is indeed mapped to Serial1 in the API. I find this a bit strange though, seeing how they’re using SerialUSB for the programming port.
- Most concerning is that the entire IDE seems to lock up if I try to send characters across the serial monitor output more than 3-4 times. When I was trying to send characters across so that I could detect them on either bus (4-pin or 28-pin), the serial monitor would hang after I tried to send more than 3 or 4 times. It would just lock up, and I’d have to force-kill the entire IDE with the Task Manager in Win10 because there is no option to just kill the serial monitor. Most disconcerting. Then, when I’d open the IDE again, it defaults to the Arduino Yun board (might be the first one in the list?), completing forgetting about the SAMD21 I was trying to work with. At least it seemed to reset the board though, because sometimes when I would restart the IDE the SAMD would be COM3…and other times it would be COM4. I never did have to jumper the Tx/Rx pins on the 4-pin header to reset the port.
So my “formal” opinion (for what it’s worth) is that there is indeed something funky about the implementation of the Arduino core on this x86 Odyssey product. But that seems very strange–because there are pictures in the product demo video of the board connected to a TON of different sensors and other peripherals. Surely someone has tested the terminal function in the serial monitor?!?
At first I thought the problem might be the serialEvent method that is included in the Arduino demo sketch, as this is essentially a method called automatically by the Arduino core library after each loop() iteration. But even removing that code from the project doesn’t make a difference–the IDE still locks up.
I did find the pin-out and schematic diagrams for the Arduino Zero board, and want to go through those to see how they’ve mapped the SerialUSB port to the chip. But I doubt that there’s a way to evaluate the traffic on that bus, given that things are wired together on the Odyssey board itself. So @wx4cb is definitely correct in that we need more documentation for this product.
TB
The framing errors are strange. Try testing it with minicom on the 40 pin header (/dev/ttyS4) see if you get consistant output. So what I would doi is tie tx/rx on each one to the respective pin on each header (28/40 pin) and see if you have any issues.
There is a program call realterm on sourceforge that might help you in that as it does show crc and framing errors etc and also the state of the lines.
it’s weird how there is just a clock signal on the 4 pin header… i’m wondering if it’s not i2c and just silkscreened wrong what is the frequency of the “clock” ?
as far as the pictures, that’s it, they may be “just pictures” i know the ttyS4 port works fine as i’ve used that to connect to devices.
@wx4cb…well, the i2c clock would have no signal until the master pulled the SDA line low, and then you’d see the clock get pulled low as well and do its thing. You shouldn’t see a clock going all the time like in my trials this morning. So although the board might not be silk-screened correctly, from my experience working with i2c I don’t think this is a mislabeled i2c bus. That said, to your other points, I ordered an NVME SSD drive this morning, and it will be here Monday. So I’ll get it installed on the x86 and then install Ubuntu on it. Then I can play around with some Linux tools like minicom. But I’ll check out the realterm application you mentioned. I’ve used it in the past, but not for several years. I also need to research framing errors a bit as well because I’m not used to doing much with a UART, other than basic stuff on the Teensy and RPi units…which just always seems to work.
The other thing I’m going to try with Serial1 is to connect a GPS unit I’ve used in other projects, and try to read data from it over Serial1. That will at least give me activity on the Rx line, and I can also echo it back on the Serial1 Tx line as well as use the logic analyzer. So I should definitely be able to detect errors on one or the other line (or both). I have a couple of sketches using that GPS, that I’ve run on a Teensy 3.2 device–which should give me a good starting point. I just need to dig around on gitlab to see if I can find them again.
While this sort of testing can be educational in that sense, it seems like an awful lot of work for something that should “just work.” LOL…
TB
1 Like
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
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:
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