How to Select USB Port for AVRDUDESS in Linux

[bostonman]

I have the GUI loaded and I'm trying to access a USB programmer (https://www.amazon.com/gp/product/B085CDH57P/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=B085CDH57P&linkCode=as2&tag=kiwih-20&linkId=72ee6b5db0c4bbfc13df0bb3b0f2c5e0)

From reading, the USB driver for Windows doesn't support XP, but I'm using Ubuntu regardless. I'm use to Windows where I click and it installs the driver.

When I load the AVRDUDESS GUI in Unbunu, it shows a list of ports, but they are all TTYSx.

I'm assuming I need to install a Linux driver for this programmer, but, after nearly two-hours of searching, I can't figure out how to get Linux to see the programmer.

Any advice?

[retiredfeline]

These USB devices usually show up as ttyUSB0 or ttyACM0. You should be able to see it detected in the system logs. To make them available to non-root accounts, you need a udev rule to set the appropriate permission and group ownership.

Search for howtos relating to USB ASP and USB ISP programmers for AVR.

[bostonman]

I had tried this: https://andreasrohner.at/posts/Electronics/How-to-fix-device-permissions-for-the-USBasp-programmer/

It responds with: /dev/bus/usb/003..... no such file or director.

I assume the website is using some directory that something is located, but I'm uncertain what to put here.

[retiredfeline]

The actual device path may differ. You should use the USB vendor and device IDs that pertain to your device for the udev rule. Does lsusb show that the device has been detected?

[bostonman]

If I'm reading the lsusb correctly (a command I was just introduced to), it seems to detect a device named:

Van Ootjen Techntsche Informatica shared ID for use with libsub

When I remove the programmer, this disappears.

[retiredfeline]

Ok, use the USB vendor and device ID for that in the udev rule. The /dev/bus/... path is of no consequence, it varies according to the topology of your USB bus and where you plugged in the device. In addition there should be a device /dev/ttyUSB0 or /dev/ttyACM0 created as a result of the plug in. The udev rule is just to give your account permissions to it.

[golden_labels]

I'm use to Windows where I click and it installs the driver.

In Linux the “driver” is built-in, no need to install anything.

With the programmer disconnected, run:

Code: [Select]

sudo dmesg --followConnect the programmer, observe the output. It should provide you with the required information. The programmer is likely exposed as a serial terminal called /dev/ttyACMn or /dev/ttyUSBn.

From the dmesg output you should also obtain the VendorId:ProductId pair, which will be needed to setup udev rules, as mentioned by retiredfeline above. That step is not neccessary, but manually adjusting them each time the programmer is connected is unneccessary effort.

[bostonman]

Okay, I typed:

$ sudo chmod 666 /dev/bus/usb/005/004 after typing lsusb (the numbers made more sense after I read your message).

Unfortunately when I load AVRDUDESS, the drop down menu still only shows a list of /dev/ttySx

After reading the follow up with the --follow command, I saw idVendor=16c0, idProduct=05dc

I then tried: $ sudo chmod 666 /dev/bus/usb/16c0/05dc

That resulted in a no such file or directory.

[retiredfeline]

I then tried: $ sudo chmod 666 /dev/bus/usb/16c0/05dc

That resulted in a no such file or directory.

Not surprising, the vendor and device IDs are not used in device paths (think, what happens when two of the same model are plugged in). They are for udev rules.

Again, you should look for /dev/ttyUSB0 (or maybe 1). If it exists, then you have to teach avrdudess to use that. Or try it first from the CLI with avrdude.

[bostonman]

Hmmm my inexperience with Linux is certainly playing a role.

If I do things correctly, the drop down menu in AVRDUDE should automatically be there?

So far everything I've tried doesn't add anything related to 'USB' in the drop down. It's always the same ttySx (where x is a number)

[retiredfeline]

I don't know what your GUI tool does. It may rely on a preset list and you have to manually add ttyUSB0. Or maybe it couldn't open it because of the ownership and permissions so it was filtered out.

It's only a few moments with ls to check if /dev/ttyUSB0 exists. It should also be mentioned in the system log shown by dmesg as golden_labels explained. If the permissions and ownerships are not suitable, use a udev rule to fix. Then try it with the CLI avrdude. Finally try the GUI tool. Take it in small steps.

[bostonman]

I don't know what your GUI tool does.

Oh sorry, I thought it was implied. If you care to know, it's:

https://blog.zakkemble.net/avrdudess-a-gui-for-avrdude/

[retiredfeline]

The problem with GUI tools is that what it's doing behind the scenes can be opaque. Hence my recommendation to check each step with the CLI:

• Is the USB device node created on plug in? Use ls and also look at the system log.
• Are the permissions and ownerships suitable? If not, install a udev rule.
• Can you access the device from the CLI with avrdude?
• Can you access the device from the GUI (which is probably a wrapper around avrdude)?

[bostonman]

If I looked at the history correctly, it's recognizing that the programmer is being removed and connected.

As for as using udev, I didn't find anything that was easily connected to setting rules - or maybe it's my lack of understanding the commands.

I'm calling it a night. I've been tinkering with this programmer for almost five-hours without luck.

[PKTKS]

If I looked at the history correctly, it's recognizing that the programmer is being removed and connected.

As for as using udev, I didn't find anything that was easily connected to setting rules - or maybe it's my lack of understanding the commands.

I'm calling it a night. I've been tinkering with this programmer for almost five-hours without luck.

It looks like you have fallen into at least 2 major pitfalls:
-  The first one is depending on a GUI to use a way smarter tool (avrdude)
   and the folk behind that GUI is way below the puddin using "MONO" to that.
   Sum insult to offense and you will go nowhere with that pile of MONO junk..

- Second pitfall is using a systemd  thingy system in which your control over drivers
and devices is pathetic bad relying on those "rules" instead of your own setup.

Bottom line to use such tools on a decent *NIX distro is having all the power of the tool under the command line..  and under *YOUR CONTROL*  the proper drivers...

Drivers?  yes you need all the kernel drivers regardless these "distro" sudo apt..
In such cases is very important having the serial and parallel ports (RS232 like) drivers because most of the avrdude gizmos rely on some sort of them...

you have "TERMINAL" mode (aka serial modem like mode)..
so you will definitely  need all the modem drivers in the kernel tree..
and proper devices.. all previously loaded  *BEFORE*  that systemd shit things

Not so hard but a initial steep step is certain

Paul

[bostonman]

I'm not exactly sure what you're trying to say.

From how I interpreted it, you're not fond of this hardware and the method of interfacing the manufacture chose?

Basically I'm using this to extract the firmware from my 3D printer before I upgrade it to new firmware. From my understanding, this programmer is ideal for reading the firmware and saving it. To upgrade, it's a different, and simpler process.

I thought this programmer would be basically plug and play, and hoping to resolve it because I need it for about thirty-seconds. Unfortunately after many hours last night of searching the Internet and trying different things, I had to give up because my eyes were tired.

Now that I think of it, I have a (very) slow Win7 mini computer. Maybe it will be enough to get me through this hurdle.

[PKTKS]

I'm not exactly sure what you're trying to say.

From how I interpreted it, you're not fond of this hardware and the method of interfacing the manufacture chose?

Basically I'm using this to extract the firmware from my 3D printer before I upgrade it to new firmware. From my understanding, this programmer is ideal for reading the firmware and saving it. To upgrade, it's a different, and simpler process.

I thought this programmer would be basically plug and play, and hoping to resolve it because I need it for about thirty-seconds. Unfortunately after many hours last night of searching the Internet and trying different things, I had to give up because my eyes were tired.

Now that I think of it, I have a (very) slow Win7 mini computer. Maybe it will be enough to get me through this hurdle.

Let me try to say same thing with other words...

Every USB gizmo out there needs a proper driver on  top of the common base.
( being that EHCI or OHCI or UHCI )

Serial or parallel USB gizmos will need on top of that the proper PROTOCOL as well

The command line tool avrdude is complete - self sufficient and works fine.
It is just required to tell it which port and protocol to use (via command line)

The way to do that is after loading the proper USB and serial driver (or parallel)
you still need to load the proper PROTOCOL driver as required by your gizmo.

Piece of cake - as long as you already know which drivers and protocols the gizmo uses.

And this is not something to "let systemd load something out there..."

You do need to understand the gizmo and properly load the things..

A simple example may worth more than 1000 words..

Code: [Select]

# *IF* the gizmo talks only over USB 1.1 
modprobe -a uhci-hcd

# any serial gizmo will require a serial module
modprobe -a usbserial

# CH34x and very common chipsets requires their own driver on top of serial
# (arduinos fallback mostly on FTDI serial)
modprobe -a ch341
modprobe -a cp210x
modprobe -a pl2303
modprobe -a ftdi_sio

# any serial terminal RS232 aware will perhaps require CDC-ACM control
modprobe -a cdc-acm

# and other devices like bar code readers .. GPS... require specific protocol drivers..
# ...



The advent of USB OTG deprecated some of the old phone drivers.. (usb_phone)

But several DMM still require some sort of CHIPSET (CH341 or FTDI) driver
with their own protocol

SYSTEMD rules are just a bunch of very poor solution for that.. 

Hope it helps.
Paul

[golden_labels]

After reading the follow up with the --follow command, I saw idVendor=16c0, idProduct=05dc

There is no information about a device being created in /dev?

If not, then I stand corrected. I was pretty sure USBasp uses standard serial communication.

After digging a bit deeper, it seems that indeed they are implementing USB protocol by bit-banging controller’s ports and not offering standard communication. But it should still require no drivers and avrdude implements the communication directly. If you invoke it manually, does it work? With programmer being set to "usbasp” and port as “usb”?

Code: [Select]

avrdude -c usbasp -P usb …
PKTKS: could you please spilling your anti-systemd fanaticism in every Linux-related thread? In particular if the issue seem to not even be related to systemd?

[bostonman]

It's really unfair for me to provide too many answers because I'm quite new to Linux.

I can move around terminal navigating directories and stuff, but many, many of these commands, and how to confirm what I'm reading, are foreign to me.

I found a write up which gives the directions of:

    sudo apt install gcc-avr avr-libc binutils-avr avrdude,
    then avrdude -c usbasp -p m1284p -U flash:r:aneta8-flash.bin:r

This is per: https://01001000.xyz/2020-08-06-Updating-Firmware-Anet-A8-Board-1.7/

Fortunately I think my (very) slow Win7 mini laptop will run this. I had to download a driver which is baffling to me because I didn't see anything regarding needing a driver. The one I found was (I think) a 3rd party which I wasn't too fond of using, but the website looked legit because it went into details about using the programmer.

[PKTKS]

(.)
PKTKS: could you please spilling your anti-systemd fanaticism in every Linux-related thread? In particular if the issue seem to not even be related to systemd?

Geez not a chance in hell ...
Here comes the situation where it is unavoidable.   

SYSTEMD or POTTERIX is a fork of *NIX made as a BUSINESS.
Nothing wrong about that - I am all favor to business... 

Sponsored POTTERIX systems have gone against every single safety best practice rule of *NIX on the book..  reason obvious (apart being sponsored  by patrons)  is to have unattended *NIX images for sell like "CLOUD" services and/or goonies and newbies on the IT mafia buz. corps

Perfect for my 6y old nephew..
and I ve  made a POTTERIX for his games just fine..

BUT!! For serious *NIX machines  it is just unbearable.

This particular case boils down where..:
- Or one will talk about "rules" to automatic "init" shit in parallel via "systemd".. OR..
- Or one will have a safe sane system where a skilled folk will load proper drivers ..
- with proper order (very important and explained earlier)
- and proper safety and security best practices..  this is NOT SYSTEMD

On serious safe *NIX machines?  Forget POTTERIX.
It is no rant nor anti-nothing..

POTTERIX is a business - you are part of it.. or not

or you just have a problem forced into your hands.
alas they taken control of the solution.. for their obvious reasons..

simple facts.

The folk need to go via the proper way..
Far from what will not put him on the control.

Paul 

[Ed.Kloonk]

Sometimes with ardrunios I have comms/connection problems and it goes away when I use a better USB cable.

Can you check that the voltage going to the board is high enough?

After plugging in, can you run

Code: [Select]

dmesg -T

Spell checker wants the word ardrunios to be drunkards. Hmm.

Though shalt check voltages.

[bostonman]

Partially good news.

Using my junk Win7 mini laptop, I was able to utilize the driver I downloaded. When I first tinkered with the driver, the programmer was showing in the hardware list. Also, the GUI seemed to recognize the programmer, but, since it wasn't connected to the board, it gave a communications error.

Today I connected the programmer to the board, turned on the printer, plugged the programmer into the USB, and Win7 didn't see it. After some frustration, I randomly connected and disconnected stuff in different order and reinstalled the driver. Once I disconnected the programmer from the printer and started the GUI, Win7 recognized the programmer. At this point I connected the ribbon cable from the printer to the USB programmer and things worked just fine.

I must say, this was a horrible experience because of quirks.

Hopefully I did this correctly. Although failing is not a major issue because I'm just preserving the original firmware before upgrading to a newer revision should I need to resort to the original firmware.

I 'read' the firmware and saved it as a .bin file. Does this seem correct?

[PKTKS]

(.)
I 'read' the firmware and saved it as a .bin file. Does this seem correct?

IT DOES.

If you can read the gizmo chances are you can write it as well.

Do not miss the chance and as soon as the "GUI" thing recognizes your device..

Go there on that pile of gui applets to find the proper CHIPSET drivers required...

Take note and try avrdude on console (Windoooze does have consoles.. )
You should be able to that as well

Same command line should work in *NIX  loading the "CHIPSET" driver
as explained earlier..

Paul

[westfw]

I have the GUI loaded and I'm trying to access a USB programmer (https://www.amazon.com/gp/product/B085CDH57P/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=B085CDH57P&linkCode=as2&tag=kiwih-20&linkId=72ee6b5db0c4bbfc13df0bb3b0f2c5e0)

When I load the AVRDUDESS GUI in Unbunu, it shows a list of ports, but they are all TTYSx.

[ ... many suggestions aimed at finding the correct tty ... ]
SO MUCH BAD ADVICE.

What "programmer" have you selected?

Your programmer is a USBASP-style programmer that enumerates as a HID device, shouldn't need a special driver, and doesn't show up as a serial port.If you select the correct programmer inf the "programmer" field ("Any usbasp clone with correct VID/PID" is a good guess), you should have a "usb" (just by itself.  No "tty.usbxxx" or "usbserialxxx" or anything) option in the PORT field, and that's what you should use.

[PKTKS]

I have the GUI loaded and I'm trying to access a USB programmer (https://www.amazon.com/gp/product/B085CDH57P/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=B085CDH57P&linkCode=as2&tag=kiwih-20&linkId=72ee6b5db0c4bbfc13df0bb3b0f2c5e0)

When I load the AVRDUDESS GUI in Unbunu, it shows a list of ports, but they are all TTYSx.

[ ... many suggestions aimed at finding the correct tty ... ]
SO MUCH BAD ADVICE.

What "programmer" have you selected?

Your programmer is a USBASP-style programmer that enumerates as a HID device, shouldn't need a special driver, and doesn't show up as a serial port.If you select the correct programmer inf the "programmer" field ("Any usbasp clone with correct VID/PID" is a good guess), you should have a "usb" (just by itself.  No "tty.usbxxx" or "usbserialxxx" or anything) option in the PORT field, and that's what you should use.

That depends... 

*IF*  the kernel in use has builtin HID support chances are it will be enumerated.

Otherwise you still need to properly load (in proper order)  HID driver

Code: [Select]

modprobe -a usbhid

And yet depending again if one is using a vanilla average joe kernel..
You will need some sort of "serial" driver... if the chip is not (already) registered

Typical drivers like CH341 and FTDI will automatic register with next serial or USB tty in chain.

Code: [Select]

## systemd udev rules are crappy so always good to note
mknod /dev/ttyUSB0 c 188 0

On the other hand common modem terminal CDC ACM modems register other terminals

Code: [Select]

modprobe -a cdc-acm
mknod /dev/ttyACM0 c 166 0

Things will be different for different kernels and hoping a vanilla "rule set" may fail with some particular gizmo.

Knowing in advance the serial chipset is a very good thing.
A single command chain will enable your environment regardless underlying system

Your mileage will vary cf. distro
the only fit all solution is indeed loading by hand the proper driver chain
Paul

[PKTKS]

I have a programmer gizmo in hands still trying to figure what sort of driver I will need to enable COM with it...

IT DOES ENUMERATE .. fine as any USB gizmo XHCI can provide at least device IDs.

Code: [Select]

usb 1-1.2.4: new full-speed USB device number 9 using xhci_hcd
 usb 1-1.2.4: New USB device found, idVendor=1fc8, idProduct=310b, bcdDevice=
 usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-1.2.4: Product: WinUSBComm
 usb 1-1.2.4: Manufacturer: [url=http://www.zhifengsoft.com]www.zhifengsoft.com[/url]

Nevertheless that crappy WinUSBComm is whatever it is.. no driver ready so far.

So even being enumerated I can not access the chip 

Paul

[madires]

To automatically set specific access rights create/edit /etc/udev/rules.d/99-local.rules and add something like:

Code: [Select]

# AVR Programmer directly
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", MODE="0660", GROUP="plugdev"
or

Code: [Select]

# AVR Programmer as tty
ACTION=="add", SUBSYSTEM=="tty", ATTR{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", MODE="0660", GROUP="plugdev"

The user should be a member of group 'plugdev' in this case. And replace xxxx and yyyy with the correct IDs.

If you like to create an alias device add:

Code: [Select]

... , SYMLINK+="My-AVR-Programmer"

That will create also /dev/My-AVR-Programmer each time the programmer is plugged in.

[westfw]

your programmer is a USBASP-style programmer that enumerates as a HID device, If you select the correct programmer inf the "programmer" field  you should have a "usb" option in the PORT field

Well, that was an interesting theory I had, and describes the way that things work on Windows, but it doesn't seem to apply to linux.
I loaded up Mono and dudess on an Ubuntu system, and sure enough:  no choices other than the inappropriate serial ports.I'm not sure that I'd expect libusb raw access to HID devices to work through an emulator like Mono :-(

I think your best bet is to figure out how to use avrdude from the command line.

[golden_labels]

I think your best bet is to figure out how to use avrdude from the command line.

Indeed, but three days after I suggested an avrdude invocation we still received no response. ¯\_(ツ)_/¯

[PKTKS]

your programmer is a USBASP-style programmer that enumerates as a HID device, If you select the correct programmer inf the "programmer" field  you should have a "usb" option in the PORT field

Well, that was an interesting theory I had, and describes the way that things work on Windows, but it doesn't seem to apply to linux.
I loaded up Mono and dudess on an Ubuntu system, and sure enough:  no choices other than the inappropriate serial ports.I'm not sure that I'd expect libusb raw access to HID devices to work through an emulator like Mono :-(

I think your best bet is to figure out how to use avrdude from the command line.

There seems to be 2 "classes" of different "invocations" for avrdude (attach)

The first most common one is the UART terminal related in which the proper driver "should" be automatic attached to the proper terminal (being ttyUSB or other)

The chipset driver should be loaded.. and ..NOT EVERY DISTRO out there uses UDEV...
All busybox images are free from UDEV..  so does Slackware and some others..

So rules are useless and the device should be carefully checked.

The other type of INVOCATION  related no UART chipset..
And that type is the type used by these programmer I am testing..

it is only attached to libusb and any appler should use libusb directly...

It "seems" that avrdude "could" do that one the address is recognized.

So far I have gone this far but still trying to read data...

Code: [Select]


 usb 1-1.2.4: new full-speed USB device number 9 using xhci_hcd
 usb 1-1.2.4: New USB device found, idVendor=1fc8, idProduct=310b, bcdDevice=
 usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-1.2.4: Product: WinUSBComm
 usb 1-1.2.4: Manufacturer: [url=http://www.zhifengsoft.com]www.zhifengsoft.com[/url]

found USB  (vendor=0x1fc8 [www.zhifengsoft.com], product=0x310b [WinUSBComm]) at libusb:001:008


INVOCATION on this type relates port to the usb keyword.. and proper address..

The trick here is to find the libusb addr

Paul