"pkg test arduino" is very slow on Mac #5
Comments
|
Not sure if that helps: |
|
I looked around and I think the issue is with scanning for arduino on the weird ports like diff --git a/inst/scanForArduinos.m b/inst/scanForArduinos.m
index cf56848..ea110c3 100644
--- a/inst/scanForArduinos.m
+++ b/inst/scanForArduinos.m
@@ -154,12 +154,35 @@
# get list of serial ports to try
ports = serialportlist ();
-
- for i = 1:numel (ports)
+
+ # Filter out ports that are unlikely to be Arduino
+ filtered_ports = {};
+ for i = 1:numel(ports)
+ port_lower = lower(ports{i});
+ # Skip Bluetooth ports and other unlikely ports
+ if strfind(port_lower, "bluetooth") || ...
+ strfind(port_lower, "airpods") || ...
+ strfind(port_lower, "phone") || ...
+ strfind(port_lower, "console") || ...
+ strfind(port_lower, "debug") || ...
+ strfind(port_lower, "irda") || ...
+ strfind(port_lower, "virtual")
+ if debug_flag
+ printf("* skipping unlikely port: %s\n", ports{i});
+ endif
+ else
+ filtered_ports{end+1} = ports{i};
+ endif
+ endfor
+
+ # Scan ports in reverse order since Arduino ports are typically at the end
+ for i = numel(filtered_ports):-1:1
+# for i = 1:numel (ports)
try
s = {};
unwind_protect
- portname = ports{i};
+# portname = ports{i};
+ portname = filtered_ports{i};
if debug_flag
printf("* trying comport %s\n", portname); I also reduced the |
|
serialportlist is very naive in instrument control grabbing anything thats /dev/tty.* |
|
Interestly, the change makes it take longer for me on my fedora machine. { |
|
perhaps a change that effects just mac: |
|
Absolutely. I timed it and it was really hanging on "closing" on Bluetooth port (see the profile trace above). Does it need to wait for something, could it just hang up? I have also noticed that |
|
BTW, most of the names in this backlist I just made up. I had one "Bluetooth" and another is "debug-console" so I just thought what else could be on the Mac? |
|
For the closing, Im not sure why its doing that - I am guessing something portwise settingwise rather than we are actually deliberately waiting for the port to hangup. Is it possibly waiting for modem signal lines on close ? |
|
i pushed up a change that filters out the ports and makes a reverse order llst when ismac, so hopefully that captures most of your speedups the longer term fix will be in part working out why some ports stick. I believe I have seen it do it on my linux machine as well - probally when some bluetooth device was plugged in so if I get a chance I will relook at that. |
|
No, I think the order was specific to my board (it was also the last one on linux) not to the OS. I also do not like to rely on things like |
Good :) That means the blacklist patch should help linux as well. Perhaps we should keep an eye on some weird ports that may pop up and expand the list accordingly. |
|
yeah its too bad the naming on linux doesnt reflect what it is like it seems to on mac |
|
I rechecked the latest git. You still have Also my TeX installation should be fine: works and produces a nice-looking pdf. |
the reverse order is putting the order to the way you had it (but by building the list in reverse order rather than iterating in reverse order) - just is only doing it for mac - since on my linux machine it was making it longer in time |
In the makefile it is: cd doc && ./mkfuncdocs.py --src-dir=../inst/ --src-dir=../inst/sensors/ ../INDEX | $(SED) 's/@seealso/@xseealso/g' > functions.texi |
Yes. There is nothing Mac-specific about it. It Worked for me on both Mac and Linux because my board name was |
|
so with the reverse order it works faster for you both on mac and linux, but does not on my machine where the arduino devices seem to enumerate starting a /dev/ttypACM0 - i trued a couple of clones as well as offical arduinos in they did the same (fedora) |
|
Exactly. So it just depends on the board, not computer / OS |
|
which linux and whch board do you have ? An alternative way of detecting boards may be using the usb info rather than serial port, which may be a better option to detect connected arduis rather than scanning all teh serial ports |
|
Fedora. The board is a SparkFun RedBoard (UNO clone). There is no much info from linux misc. usb facilities. |
|
Some photos (CPU and USB-Serial converter):
|
|
yeah i have one of those floating around here somewhere will see if I can dig it up |
|
found it - mine I think was the older rev when was still using the ftdi chip, but it does at least come up ttyUSB0 I guess solution for linux at least is prioritise the ports - It will be far more like that a non /dev/ttySXX one will be the port (Unless they do actually have it looked up via a real serial port) so they should be checked first |
|
Perhaps related to mac, I see on arduino-ide images on mac, it appears to be using the /dev/cu.xxxx ports rather than the tty ones, and I sawa reference about the cu versions dont wait for the control signals to assert on open, so perhaps a hint for the serializ ports ? |
I wonder if this is a kernel issue (old vs new Macs). On mine (MacOS 15.3.2) serialportlist shows only tty. |
Yeah serialportlist basically just gets a list or /dev/tty.*, nothing else, rather than listing both - a few examples of mac matlab code only show them BUT could have just been the examples I have seen. For the ide, comment, I just noticed on some of screenshots of the arduino running on mac and showing the serialport list, that they were only /dev/cu.xxx - perhaps also just limited examples |
Running "pkg test arduino" is very slow on Mac (almost 10x slower than on linux; the same board)
On linux those "33.3 sec" test are "4.5 sec".
My wild guess is that the board does not register "End-of-Comm" and just times out.
I do not have Arduinio IDE on Mac, I programmed it on linx and rhen plugged it into Mac.
The board is SparkFun UNO clone.
The text was updated successfully, but these errors were encountered: