@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.
Do you have a logic analyzer–maybe those are framing errors? Given the number of duplicate characters seen though, I would expect that you might see some problems with the IDE hanging as well. Have you?
Well my IDE hangs when I’ve tried to send characters repeatedly over the serial monitor. So that’s sending them over SerialUSB, and not Serial2. So I guess I shouldn’t expect there to be an issue then on your end with that port, as the IDE’s serial monitor should have nothing to do with it.
I’ll put my LA on Serial2 Tx a bit later today to see if I can see any issues. I’ll also check Serial1 again too, now that I’m using the new library.
Oh, I reverted to just using the example serial communication sketches included in the IDE. I took my code out of the equation early last week. I forget exactly which sketch I used, as I’m not in my lab right now though. But I tried more than one of the examples, and got pretty much the same behavior. I just changed the Serial object names to suit me.
That code was using a GPS module anyway, so unless you had the same one, it would have been difficult to duplicate the circuit. Also, there were five source files…not just the sketch. So I decided to simplify the evaluation by using “standard” code–examples from the Arduino IDE library.
You got output on the Serial object? HUH?!? I have never once gotten anything off that port on this board–no matter which library I’ve tried. But you’re using the same library as I am now (1.7.2), and I’m choosing the same board in the list as you’ve shown.
I just ran wires from the 4-pin header (Serial2) to the little breadboard that my GPS was on. Then I used the logic analyzer on some wires at the GPS module I had been using with my code. I will try your other wiring though–from the 28-pin header to ttyS4. I’ll see how that goes later today.
I spent some more time this afternoon, and here are my observations:
You are correct, and I can’t explain it, but now I am in fact getting output from the Serial object on the serial monitor! All I can think of to explain that I didn’t see this before (but do see it now), is that I’ve tried so many things that I just didn’t try the Serial object after I installed the new library. But here’s a n image of the code I was running…and the output I got.
I did install Cutecom and was able to see the output there as well–so I was likely just doing it wrong the other day when I tried to look at the /dev/ttyACM0 file from Linux. We’ll chalk that one up to an error on my part.
I am still getting framing errors on Serial1 though, running the code I posted above. As you can see I did flush the serial buffer(s) each time through the loop, just to be sure. There were no framing errors seen on Serial2, but there still were errors on Serial1. Also, for whatever reason, the Saleae UART decoder seems to give me incorrect ASCII characters for the output on both the Serial1 Tx and the Serial Tx pins. And I connected the LA probes to very short jumpers attached directly to the Tx pins themselves. The Serial1 framing errors are seen on virtually every data packet too by the way, just as I saw it before.
Speaking of incorrect UART character decoding, I’m getting that on the Serial2 port as well…and I can’t explain that either. I’m using the same Saleae LA and software that I have been using this whole time, and I’ve gotten it to produce “normal” character output on several other occasions–besides the previously reported framing errors of course. I’m seeing two decoded values on Serial2, as seen in the two images that follow. Very strange. You’ll note that the one value reported here (‘24’) seems to be the same as that decoded on the Serial1 port (sans framing errors).
To @ansonhe97: Can you reproduce any of the errors I’m still seeing here? Are you testing the individual UART ports on the SAMD21 chip, and if so, are you using a logic analyzer?
@tcbetka it would appear to me that the framing errors might be a baud rate issue. i’m not around at the minute to test, but try lowering the baud rate to 9600 and see if the framing errors go away. if they do, go up in baud one at a time (19200, 38400, 57600) to see if they come back and where. it could quite well be a baud generation timer issue.
That’s a good idea. I’ll try that when I go back down there again. I think I did actually get them at 9600 baud rate, last week during one of my tests. But to be totally honest I’ve forgotten what all I’ve done as there have seen so many different things, lol…
But it’s a good idea though, so I’ll definitely try it when I’m in the lab next.
By the way–there’s another thread on the forum here, and it’s related to the i2c bus. It appears to me as though there’s an issue with the i2c bus(es) on the Linux side as well, but I haven’t yet put much time into exploring that. I did want to tell you though that your -r flag tip seems to come in handy with i2c-0, i2c-1 and i2c-2, as many of the addresses are apparently read-only. If if just use i2cdetect -y 0 for instance, there are a BUNCH of addresses that don’t show up. But throw in the -y flag, and they all seem to show up. So your trick seemed to work!
I mentioned earlier today that I stopped using the code I wrote early last week, and moved to using the example sketches from the Arduino library. So I just uploaded the code onto a Teensy 3.5 I have here on a breadboard, and it seems to work perfectly. Here’s a screenshot of the output:
By the way this is the same code that gave me virtually no output the other day, when I took the following screen shot (also posted above). I had to put in a bunch of debug prints just to try to make sense of what was(n’t) going on…
I will attach a link to a zipped archive of the code in this project. It should work on any Arduino-related device that uses the Serial object for the USB monitor, and has a second serial device to connect to the GPS. I should think it could also be a SoftwareSerial device as well. I am using the Adafruit Ultimate GPS unit.
This got me thinking last night. And it turns out that you were right!
About 10 days ago I installed Saleae’s new version of the software that you use with their logic analyzers. It’s called Logic2 while the original software was called Logic. Well it must not be a mature software product yet because it seems that every time I start the software, it yells at me to install an updated version. There’s a good-sized pop-up dialog that appears in the lower left corner of their application, and it’s sort of annoying because it’s somewhat obtrusive. So a couple of days ago I decided to just go ahead and finally install the update…so I did. Then I did the tests where you saw those weird errors, and thought this was a potential baud rate issue. So this morning I explored it a bit, and what do you know: It WAS a baud rate issue!
It appears that their application keeps some preferences around–like it remembers whatever decoders you had set up in the older version, for example. In my case, I had two serial decoders: One each for the Rx and Tx pins. And they were configured for a baud rate of 115200, and it did work when I provided the screen shots where we had seen the framing errors along with partial ASCII output. But apparently when the update got installed, several settings seem to have reverted to the default for the decoders. This includes a baud rate of 9600. This would not have been a problem were it not for the fact that baud rate is hidden inside a menu in the decoder set-up wizard–because otherwise it would be quite apparent from a glance. But to see the baud rate in their software you have to go into the “edit” menu for each decoder, and that’s hidden a level in. So I just plain missed it, and since the software update apparently reset the baud rate (and some other things, actually) to default…I was using the WRONG baud rate. So it was definitely a great catch on your part @wx4cb.
So then (finally)…I did re-set the baud rate to 115200 in the Logic2 software, and checked both the Serial1 and Serial2 port Tx output. It seems to be perfect! I examined 15-20 print output packets for each port, and didn’t find one framing error in the bunch. See these screen shots:
Thus it does indeed appear that the updated library (v1.7.2) has likely fixed the framing errors that I had been seeing here on the logic analyzer. Since none were seen at 115200 baud, I didn’t even both to change the code to check for any at slower baud rates.
NOTE: I do still get IDE (Arduino v1.8.12) freezing when I try to close it after multiple attempts to send data over the SerialUSB port. It does seem to close eventually now though–but it takes like 15-20 seconds to do so. In the past (with the older Seeed Studios v1.0.0 library) I would have to force-kill the IDE as leaving it for a few minutes still wouldn’t shut the application. The only way I could kill the serial monitor was to force-kill it. Thus I would say I’m seeing a bit of an improvement on that as well.
So the problems seem to be getting whittled down I think. This is good news, because this board really has great potential. I did manage to figure out the i2c buses on the 40-pin header (see other forum thread), and I even tested the i2c bus on the 28-pin header last night…and it seems to work correctly as well. I haven’t used any of the 40-pin header’s i2c buses in “production” code just yet, but the i2c bus on the SAMD21 header seems to work correctly using some of the Arduino example code.
