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:
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.
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?
@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?
