Serial Port device names

That would be very good @ansonhe97, thank you.

@wx4cb, I prefer the later library. The version of the library he has been using is 1.7.1 , but the version of the library we have been using is 1.0.0. This implies to me a couple of things: 1) His library likely has more features than the library we’ve been using, and 2) they (Seeed Studios) are actually updating the library he’s been using. I’ll take the updated library every time over what could be only slightly move than an early “beta” library.

When I first started using this board on Windows late last week, I actually installed BOTH libraries for the reasons I mentioned. However when I started to notice the problems we’ve been discussing, I uninstalled the library not specified by the Wiki…leaving only the library you and I have been using. Then I only installed the older library when I installed Ubuntu on the NVME drive on the board. Since that’s the only one specified in their documentation, that’s the only library I wanted to use. Little did I know.

The problem I see with Seeed Studios so far, is that they have the whole idea of software development a little backwards. You don’t develop your software and then hope someone updates the documentation afterwards. Rather you document things first and then develop afterwards. Basically, establish the specifications…and then develop to those specifications. That has NOT been done here. If it had been done, we would have been finished with this issue a couple of days ago. That’s just my 2 cents, and it might not be worth even that–but that’s the way it seems to go on any serious development project I’ve been involved with. I find that if all of your team is on the same page in regards to your developmental goals, then it’s much easier to get everyone to the same place.

Anyway, I will switch libraries today and see how it goes. I actually don’t mind the whole “SerialUSB, Serial1, Serial2” thing to be honest, because having SerialUSB and Serial (i.e.; the way it is with the old library) seems confusing to me. Is the default SerialUSB, or Serial?!? If you have both, it’s hard to remember which is which–so people coming from Arduino are going to wonder, and it will end up causing a whole bunch of “How do I talk to the Serial port?” threads in the forum. So just have one of those (SerialUSB or Serial), document it in the wiki, and that’s that. But it MUST be documented well in the wiki, and then there should be a sticky thread in the Odyssey section of the forum that directs people to the relevant wiki documentation so there’s no excuse for them not to see it.

TB

EDIT: I forgot to ask this @ansonhe97, but is there a reason why you guys just can’t remove the older library from your repository? Having two libraries available for the same board seems very confusing to me. So if you intend for us to be using the library you were using, then remove the library we were using from the repo altogether. I just don’t see a reason for it to be there, as nothing good can happen by using it. If the library you are using is newer, and is better-supported Seeed Studios, then get rid of the older one. Problem solved.

1 Like

@ansonhe97, in the image you posted of the three serial port names, I see SerialDBG. What’s up with that? Is that still valid in the newer library (the one you’re using)? If so, what happened to SerialUSB?

Uart Serial1( &sercom0, …
Uart Serial2( &sercom5, …
Uart SerialDBG( &sercom1, …

TB

1 Like

@tcbetka i totally agree… if the other one is the one we are supposed to use then great, that’s what i’ll use.

with regards to the uarts that he posted im curious now too. Im not going to be back home till friday so can’t test anything, but you can try that multi-serial sketch i posted above with the new library and see what happens. basically anything you type on any serial port will appear on the others so it tests all of them at once

1 Like

Yeah, you’ll know pretty quickly what’s going to work–just compile the sketch. If the compiler complains, then it ain’t gonna work. If it compiles, then you’ve got to test.

TB

1 Like

you might have to change the “serial” class names to the ones in the library but you canm’t get much simpler than that sketch

Yeah, that’s no problem at all. Been programming over 10-12 years now. I can handle that. My point was that if the compiler fails (because it doesn’t know about about Serial2, for example), then that pretty much tells you how it will go from that point.

TB

@tcbetka @wx4cb

Hi all, i agreed with what you said. Yes this is a problem on our half, as in early days of our business/software management was pretty poor and caused different versions of board libraries are hugely different to each others. Now we are trying to keep the same software, same naming systems and so on. Yes you are right, the new board library i provided is the most up to date version and continuously fixing bugs.

1 Like

Understood. I will test with the newer library tomorrow, but strongly recommend you just remove the older library from your repository. Seems like a good way to not cause a bunch of users to create a TON of support support threads in your forum. Then, as soon as @wx4cb and I verify that things are better for us here, testing on different OS’s, and that the documentation is accurate, you might also consider removing this thread as well. Once things are fixed and properly documented in the wiki, this thread really doesn’t apply anymore–and would probably only confuse people who come along afterwards.

Just my opinion.

TB

Yes i agree, but as company side we need to be careful deleting resources as we know some people will still be using the old version of that board library. So we will do this very slowly and carefully. :smiley:

@tcbetka @wx4cb

Thanks again for all the concerns, and yes we will figure out a way to avoid doing a hard delete on resources and progress with this.

Sounds great. I’ll test the new library today. Hopefully it will make it so that I do not have to force-kill the IDE to get the serial monitor to work again.

TB

Hello @ansonhe97

I am testing the new library. I uninstalled the old one (v1.0.0) and installed the one with version 1.7.2, as you showed in the updated wiki. It does work–however there are some issues yet:

  1. Both SerialUSB and SerialDBG both work now, to print output to the Arduino IDE’s serial monitor. I am not sure why this is, or whether or not it’s the effect you wanted with the newer library. But both work equally in terms of function in my code–I just don’t get IDE recognition of SerialDBG, in terms of syntax highlighting. For example, see line #22 in the editors in my attached screen shot:

  1. Serial2 is now recognized AND works as well as Serial1 (yay!), using the new pin diagram as you’ve updated it. This is great news and means we will have two UART ports to play with for peripheral components. So that issue seems to be resolved.

  2. For the life of me, I cannot determine whether or not SerialUSB (or now SerialDBG) is working correctly to SEND serial characters. It wasn’t working with a sketch that I wrote, so I tried it using the SoftwareSerialExample sketch in the Seeeduino Zero examples list. Not only doesn’t that give me anything sent over the SerialUSB port (I cannot read anything on ttyACMO from the Linux side), but I don’t even get any sort of output from that sketch. Therefore I cannot make any determination as to whether or not SerialUSB/SerialDBG is actually working correctly. Maybe @wx4cb can check on this issue on his end, when he gets back home tomorrow.

  3. Perhaps the most concerning issue for me then is that the IDE still freezes a fair bit of the time, and then must be force-killed after you use the serial monitor for a number of repeated attempts to send a character over the serial port. It doesn’t seem to matter whether I use the SerialUSB or now the SerialDBG object–it will just freeze if I try to close the serial monitor, and then I must force-fill the whole IDE in order to reset it. It used to freeze after I sent only a few characters, but now it seems like I can send as many characters as I want at a time, and make as many attempts as I would like. But then when I try to close the serial monitor by clicking the ‘X’ at the upper right corner…the serial monitor doesn’t close, and the whole IDE freezes. I believe @wx4cb experienced this issue in his evaluation as well, so it seems like it’s not just here with my board. Are you able to reproduce this issue?

Anyway, I am going to test some of the code I have written using a different Arduino. I want to verify that it is all working in that code using the Odyssey board.

TB

An update, with some modest success in further exploration of item #3 in my first post (just above)! I grepped your library for the serialEvent callback and found the serialEventRun() method in this file:

/home/tb/snap/arduino/14/.arduino15/packages/Seeeduino/hardware/samd/1.7.2/cores/arduino/main.cpp

I used the Arduino example “serialEvent” sketch, and changed that method’s name to serialEventRun, and am able to echo back text on the SerialUSB port. Note however that this DOES NOT echo back while using the SerialDBG port. It simply does not work with the SerialDBG object–but it’s odd that I am able to get the same output printing with the SeriaDBG and SerialUSB objects. I can only echo back while using the SerialUSB object, but can output equally well with both the SerialUSB and SerialDBG objects. Very odd.

Maybe @wx4cb can also verify my findings on this as well.

TB

you will probably find that SerialDBG is an output only port maybe. no clue. but if you can only get output from it and not input.

i’m just working on mine now. and just to be clear @tcbetka, it’s SerialUSB and Serial1 Serial 2? do we know which one is related to which port yet?

1 Like

ok.

same sketch as before except changed to Serial 1/2/USB.

exactly same cable setup as before - nothing done with that board between then and now.

As you can see i’m able to access ttyACM0 (usb port) and also ttyS4 (Serial1) perfectly fine in linux.

However, i’m now getting framing errors on Serial2 which is the 4 pin header.

image

I’ll have to try CuteCom–I was just trying to cat the ttyACM0 file, from the command line. So it was probably just me that couldn’t access the serial data from the Linux side–I probably just screwed up. I didn’t try ttyS4 though (Serial1), so maybe I’ll give that a try next time as well.

As to the ports, yup: SerialUSB (monitor), Serial1 and Serial2. There’s the SerialDBG thing in there as well, but I certainly can’t seem to send characters over it…so I plan to just use SerialUSB.

So it looks to me as though the only real issue still remaining from my list two days ago, is #4: The IDE locking up. I was still getting several IDE lock-ups though, and some framing errors yet. I wonder if the two are related somehow? Are you seeing those on your end at all @wx4cb?

TB

1 Like

@tcbetka you should be able to access /dev/ttyACM0 and ttyS4 as long as your user is in the “dialout” group and it’s permissions are 766 (chmod 766 /dev/ttyS4 etc)

as for framing errors. yea i had no problems with the usb or the ttyS4 port (40 pin header uart reading the 28 pin headers uart), the only issue again is with the 4 pin headers uart - which worked perfectlyt fine under the other library but not this library.

I don’t know if it’s something i’m doing wrong, but i went back to the other library and the code worked perfectly fine after I reverted back to Serial/Serial1/SerialUSB

as far as the DBG port/class i wouldn’t even worry about it

Well, you don’t need to be in the dialout group if you try to access the port (file) as root of course.

I agree on the SerialDBG thing–it’s irrelevant for me. I will just use SerialUSB. As for your code not working with this (newer) library, I can’t explain that. Serial2 works great for me with the new library, and the updated pin-outs. I can’t recall though whether or not I put a logic analyzer on Serial2 to check for the same framing errors I have seen on Serial1, so I’ll need to re-check that when I’m in the lab again a bit later on today. I think I checked that port, but I can’t recall now for certain.

TB

1 Like

yea there’s definately something going on with that 4 pin header on mine. with this library

it looks like it’s not clearing the input buffer or anything like that

.

if you got some example code and a wiring diagram maybe i can replicate it