Arduino

The place to post if you need help or advice

Moderators: ChriThor, LXF moderators

Arduino

Postby cbuffer » Sat Jan 13, 2018 2:32 pm

Just hoping there are some Arduino users here. I'm running Mint 18.1 Cinnamon on an AMD FX -4100. I recently bought an Arduino Micro to use with a Pi-Zero. I initially did apt-get but some of the files appeared to be corrupt. I've since downloaded from from the Arduino site twice and despite following their install and troubleshooting advice i get the following error message when starting the basic blink sketch:

Archiving built core (caching) in: /tmp/arduino_cache_581854/core/core_arduino_avr_micro_500c1552e3641bd46794a58a6b988d5f.a
Sketch uses 4130 bytes (14%) of program storage space. Maximum is 28672 bytes.
Global variables use 149 bytes (5%) of dynamic memory, leaving 2411 bytes for local variables. Maximum is 2560 bytes.
avrdude: ser_open(): can't open device "/dev/ttyACM3": Device or resource busy
An error occurred while uploading the sketch

I have obtained the same result with a laptop using Mint and an old laptop running XP. Maplins accepted the Micro may be faulty and replaced it with another which embarrassingly gives the same error. The earlier install linked the device to ACM0 and I've tried symlinking to a high tty number with no success. The native install doesn't set permissions to Execute but changing that as Root makes no difference. Would be grateful for any advice.

TIA Ken
cbuffer
LXF regular
 
Posts: 110
Joined: Thu Nov 01, 2007 12:04 am
Location: Cumbria

Re: Arduino

Postby Dutch_Master » Sun Jan 14, 2018 4:20 pm

You're correct in that it's a permissions issue, but probably different from what you expect. Linux uses groups (inherited from its Unix origin) as an additional security tool. In your case the user you use to run the Arduino IDE may not have permissions to use /dev/tty as it's not a member of the group that regulates access to the terminals. To solve it, add your username to that group. Can't give you the exact commands, but a search on the web should yield some useful results.
Dutch_Master
LXF regular
 
Posts: 2589
Joined: Tue Mar 27, 2007 1:49 am

Re: Arduino

Postby cbuffer » Sun Jan 14, 2018 5:47 pm

Thank you for that but it's not the answer. The group is called by my user name and contains dialout and tty and all the other commonly found members and I've checked all the extracted files from the download and all are executable where appropriate. And I used my username when signing into Arduino just for good measure.

Thank you for your thoughts, Ken
cbuffer
LXF regular
 
Posts: 110
Joined: Thu Nov 01, 2007 12:04 am
Location: Cumbria

Re: Arduino

Postby jonni » Mon Jan 15, 2018 5:45 pm

There are a few references to this problem online. Some people have reported success by repeatedly resetting the Arduino and reattempting the upload, but this seems like an unsatisfactory solution.

If this isn't a permissions issue (it sounds like you're in the dialout group which should be all that's needed here. check by running "groups" as your user, and "ls -l /dev/tty/ACM3 will show the device permissions"), then a bit of googling suggests there may be a conflict with the modem-manager package.

See http://starter-kit.nettigo.eu/2015/seri ... nardo-eth/

That post is old (and deals with a different board), but it seems the problem still shows up sporadically in 16.04 (hence likely affects Mint and other derivatives). It seems like mm hogs anything connected via serial link. You should be able to check if this is happening by plugging in your device and running:

$ sudo lsof | grep ACM

If you see anything relating to modem-man in the output here, then this is almost certainly your problem. The above post details writing udev rules to stop this happening, but if you don't use modems you'd be as well to remove the package entirely:

Code: Select all
$ sudo apt remove modem-manager


I don't have the hardware to hand, so this is just speculation, but I'm interested to see if this is indeed the issue. Best of luck!
User avatar
jonni
LXF regular
 
Posts: 102
Joined: Thu Jun 26, 2014 1:59 pm

Re: Arduino

Postby cbuffer » Tue Jan 16, 2018 3:33 pm

From the dreadlocks I assume the great Mr. Bidwell in on my case! Thank you.

http://starter-kit.nettigo.eu/2015/seri ... nardo-eth/
was interesting. I tried the suggestion there but no improvement. Digging into the meaning I found 2a03 is the processor for the Uno at the time that post was loaded, whereas the Micro uses the ATMEGA 32U4. Would you advise trying ATMEGA 32U4 in place of 2a03, I can't imagine anything catastrophic happening?

I tried sudo lsof | grep ACM and nothing happened but when I pressed the reset button the following appeared as you anticipated:

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
ModemMana 1018 root 9u CHR 166,0 0t0 616 /dev/ttyACM0
gmain 1018 1083 root 9u CHR 166,0 0t0 616 /dev/ttyACM0
gdbus 1018 1111 root 9u CHR 166,0 0t0 616 /dev/ttyACM0

Now there is a gap in my understanding. I assume that BT's HomeHub is a modem and who can live without one. But BT doesn't think it is. So when is a connection to the world not a modem and can I simply switch off the manager? And would apt-get fetch it back?

TIA Ken

Just as I posted this the delivery man called with a Uno I ordered a few days ago. Works perfectly, but is that because I ran Nettigo's instruction? Will never know:))
cbuffer
LXF regular
 
Posts: 110
Joined: Thu Nov 01, 2007 12:04 am
Location: Cumbria

Re: Arduino

Postby jonni » Tue Jan 16, 2018 4:51 pm

Hi Ken,
I assume the great Mr. Bidwell in on my case!

Indeed, 'tis I, your friendly neighbourhood rogue. I feel like we're making progress here. Modem manager is certainly afoot, and my hunch may be something like correct. The 2a03 is a USB vendor code (all USB, and PCI devices have 4 hex digit vendor and product codes), it stands for Arduino.org, so is indeed what the Uno should use. The ATMEGA has a different vendor code, which some digging around suggests is 239a. You can check this (while the device is plugged in) with the lsusb command. Assuming that's right, and modem-manager still obeys the same environment variables as in 15.04 then the command we should be running is:
Code: Select all
$ echo 'ATTRS{idVendor}=="239a", ENV{ID_MM_DEVICE_IGNORE}="1"' | sudo tee /etc/udev/rules.d/77-arduino.rules

That file should already contain the line to stop modem-manager grabbing the Uno. If you want to check that this is the only reason the Uno works, then edit the file with
Code: Select all
$ sudo nano /etc/udev/rules.d/77-arduino.rules

and comment out the first line with a #. Getting new udev rules to trigger, (or old ones not to), can be unpredictable sometimes, so a reboot may be required to be sure.

You are correct. There is an adsl modem in your HomeHub (or a vdsl one attached to it if you have BT Infinity), but Linux doesn't need to know about the hardware inside your router, just like it doesn't need to know about the hardware in any machine you ssh into. Also modem-manager is for handling mobile broadband. So removing the package shouldn't harm you unless it tries to remove a bunch of extra stuff with it, which sometimes happens. So I'd try the udev rules again. Best of luck!
User avatar
jonni
LXF regular
 
Posts: 102
Joined: Thu Jun 26, 2014 1:59 pm

Re: Arduino

Postby cbuffer » Wed Jan 17, 2018 12:44 pm

Well this has been an interesting ride. I tried echo.......239a...... and the Micro still wouldn't work. Having done some reading on modems I decided to remove the ModemManager on the desktop and the the Micro immediately fired up and I could change the led on/off intervals to show it was responding properly. When I did lsusb again the Micro showed up as 2341:8037. Since the Uno was working on the laptop I tried your echo.......239a.... on it, didn't work. So i tried again using 8037, still didn't work. There was a file in the /etc/udev/rules directory which gave information about changing rules which were in /lb/udev/rules.d. Looking at them I found some /77-mm files one of which was a blacklist to stop ModemManager from interfering with, amongst other things, some Arduino devices. They took the form of your ATTMS section but with idVendor as 2341 and idproduct== the item descriptor, so I changed your echo... instruction to make vendor ==2341 and added another ATTRS with the {idProduct}==8037. Micro still doesn't work despite the /etc......./77-arduino.rules file looking exactly like those in the /lb........./77-mm files relating to Arduino.

I can live with this and simply remove the ModemManager from the laptop but it intrigues me. Would you consider moving the file from /etc to /lib or should I live well alone?

TIA Ken
cbuffer
LXF regular
 
Posts: 110
Joined: Thu Nov 01, 2007 12:04 am
Location: Cumbria

Re: Arduino

Postby jonni » Thu Jan 18, 2018 3:02 pm

Hi Ken,

This is definitely the unmistakable odour of progress, despite my bad guesses about what your hardware's USB ids are. It doesn't really matter where you put udev rules (the idea is that ones from upstream go in /lib/udev/rules.d whereas ones you make yourself go in /etc/udev/rules.d), so I doubt moving the file will have any effect .

I'm writing a feature about elementary OS (don't spoil the surprise--Ed) at the moment, which is based on the same Ubuntu 16.04 as your Mint install. So I investigated the /lib/udev/rules.d/ directory, and in particular the file 77-mm-usb-device-blacklist.rules. This already contains the line
Code: Select all
ATTRS{idVendor}=="2341", ENV{ID_MM_DEVICE_IGNORE}="1"

which confuses me, since this on its own should be enough to keep modem-manager's hands off the Micro. However, our investigations with lsof suggest this wasn't the case, and the fact it does work when modem-manager is removed all but confirms modem-manager is indeed the culprit. Perhaps there is some other device node that needs protecting from mm's grasp, perhaps there's another stray udev rule, perhaps this is because you're stuck on the old Mint 18.1 kernel. It may be interesting to dig deeper, but it may be more interesting to forget about it and get involved in serious Arduino business. Happy hacking!
User avatar
jonni
LXF regular
 
Posts: 102
Joined: Thu Jun 26, 2014 1:59 pm

Re: Arduino

Postby nelz » Thu Jan 18, 2018 6:26 pm

jonni wrote:This is definitely the unmistakable odour of progress, despite my bad guesses about what your hardware's USB ids are. It doesn't really matter where you put udev rules (the idea is that ones from upstream go in /lib/udev/rules.d whereas ones you make yourself go in /etc/udev/rules.d), so I doubt moving the file will have any effect .


That's not quite true. The files in /lib belong to packages and can be overwritten by an update of said packages. Your changes should always go in /etc, which is safe and has priority over the rules in /lib.
"Insanity: doing the same thing over and over again and expecting different results." (Albert Einstein)
User avatar
nelz
Site admin
 
Posts: 9046
Joined: Mon Apr 04, 2005 11:52 am
Location: Warrington, UK

Re: Arduino

Postby cbuffer » Thu Jan 18, 2018 6:40 pm

Thank you for your help Jonni. I removed the MM from my laptop and the Micro worked. Re-installed MM out of curiosity and the Micro didn't work. Removed it and works again. Must tell all the windows people how to overcome with Linux. Look forward to your article on elementary, their blurb makes it look beautiful.

Regards, Ken
cbuffer
LXF regular
 
Posts: 110
Joined: Thu Nov 01, 2007 12:04 am
Location: Cumbria

Re: Arduino

Postby cbuffer » Thu Jan 18, 2018 6:48 pm

nelz wrote:That's not quite true. The files in /lib belong to packages and can be overwritten by an update of said packages.


Oh spit! My long time saviour from disaster has joined us and pointed out something I read last night but didn't sink in. Well I'm intending to try Fedora 27 off the DVD shortly - will see what happens there.

Ken
cbuffer
LXF regular
 
Posts: 110
Joined: Thu Nov 01, 2007 12:04 am
Location: Cumbria

Re: Arduino

Postby jonni » Fri Jan 19, 2018 2:59 pm

nelz wrote:That's not quite true. The files in /lib belong to packages and can be overwritten by an update of said packages. Your changes should always go in /etc, which is safe and has priority over the rules in /lib.

Good clarification. The rules in there also have a nice warning to that effect at the top. But if I make a new file in /lib/udev/rules.d, then it will stay there and be respected until some package puts a file there with the same filename, right?
cbuffer wrote:My long time saviour from disaster...

Yours and mine both... I wonder if those heathens at Linux User & Developer have a Micro for me to break, I want to know wha gwarn here. Anyhoo, back to me feature/tax return/other overdue tasks.
User avatar
jonni
LXF regular
 
Posts: 102
Joined: Thu Jun 26, 2014 1:59 pm

Re: Arduino

Postby nelz » Fri Jan 19, 2018 10:31 pm

Right, but it's just wrong!
"Insanity: doing the same thing over and over again and expecting different results." (Albert Einstein)
User avatar
nelz
Site admin
 
Posts: 9046
Joined: Mon Apr 04, 2005 11:52 am
Location: Warrington, UK


Return to Help!

Who is online

Users browsing this forum: No registered users and 2 guests

cron