My idea is to crossdevelope on pc, sending the resulting rom over USB, resetting the SNES which will instantly run the code. Is this possible with the SD2SNES? As I cannot find any information about it, my guess is unfortunately that this is not yet implemented, or in worst case not even possible with the architecture. I would be very happy for a heads up over the situation.
To my knowledge there is no "public" documentation regarding what the USB port can do -- only speculative things stated on forums. "Development" is the only thing that has ever been stated semi-definitively, which is a vague statement in itself.
If you want a definitive answer, then it's possible to get one: ask Krikzz or Ikari.
Otherwise, I would suggest looking around to see if there is something like an "SD card emulator", which would be a piece of hardware with, a USB port (or something) that you'd hook to your PC and manage/maintain through software on there -- and on the other end, an SD card/connector which you'd insert into the SD2SNES. I don't know if something like this exists.
Point: back in the day, console copiers had parallel ports for this purpose, but the software and interface was finicky (I even wrote a LPT transfer utility myself), sometimes working for a few transfers then failing (requiring either a PC reboot or a power-cycle of the copier). So, most of us got used to using floppy disks: assemble code on a PC, copy the resulting .smc to the floppy, eject it, put it in the copier, power-cycle the copier, load the file, see the results, rinse lather repeat.
Today, you have SNES emulators. I suggest using them to make your life easier, then when you get something that seems to be working well on several emulators, try it on actual hardware.
If you want a definitive answer, then it's possible to get one: ask Krikzz or Ikari.
Otherwise, I would suggest looking around to see if there is something like an "SD card emulator", which would be a piece of hardware with, a USB port (or something) that you'd hook to your PC and manage/maintain through software on there -- and on the other end, an SD card/connector which you'd insert into the SD2SNES. I don't know if something like this exists.
Point: back in the day, console copiers had parallel ports for this purpose, but the software and interface was finicky (I even wrote a LPT transfer utility myself), sometimes working for a few transfers then failing (requiring either a PC reboot or a power-cycle of the copier). So, most of us got used to using floppy disks: assemble code on a PC, copy the resulting .smc to the floppy, eject it, put it in the copier, power-cycle the copier, load the file, see the results, rinse lather repeat.
Today, you have SNES emulators. I suggest using them to make your life easier, then when you get something that seems to be working well on several emulators, try it on actual hardware.
At one point I got the idea to use WiFi enabled SD cards to do basically the same thing, but never actually tried it. Assuming it actually worked, it would have basically been an expensive novelty compared to just doing most of the testing in an emulator.
I didn't even know Wi-Fi SD cards existed! Can you really send files to them remotely? Or is the Wi-Fi only meant for sharing the contents of the SD card with other devices?
There's both the plain "wifi in SDIO form factor" thing, which is really more of a wireless card that one interacts with using SPI, as well as things like the EyeFi which will use local flash as a cache and upload things over wifi to some configured server.
I don't remember a thing that's useful in the other direction, equivalent to "here's a windows share on an SD card", but it probably exists.
I don't remember a thing that's useful in the other direction, equivalent to "here's a windows share on an SD card", but it probably exists.
Toshiba's FlashAir cards are bidirectional, but I have no idea how well they work otherwise (or would work in a sd2snes).
Back to the actual topic, ikari posted a comment some time ago with some info about future USB functionality, and the already-existing serial UART (that I totally forgot about) here: https://sd2snes.de/blog/archives/370#comment-645752
Back to the actual topic, ikari posted a comment some time ago with some info about future USB functionality, and the already-existing serial UART (that I totally forgot about) here: https://sd2snes.de/blog/archives/370#comment-645752
Quote:
As for USB, yeah I have something in mind for that but the implementation details are still foggy… I’d like to provide an upload/configuration interface as well as a console that can be used to log things from the SNES side.
If you want to upload by wire right now, you can use the serial UART console. It’s available on the 14-pin header on the side of the board, using the pins marked TX3 and RX3 (there’s a pinout table printed on the PCB). It speaks 3.3V 115200 8N1, no flow control, and supports xmodem uploads. When the sd2snes is running you enable the serial console by sending an ESC character. It prompts you with a ‘> ‘.
Relevant commands are put <filename> and load <filename>.
put <filename> requests an xmodem transfer from your side. It might take a longer time for the transfer to start (~30s) if you don’t respond within three seconds… I’m not sure why. Might as well be some issue with my specific xmodem client…
load <filename> loads a ROM and executes it, returning to the prompt.
The console supports some other commands that might be handy, such as memory reads and writes, and hex dumps (all on sd2snes on-board memory only, no SNES WRAM, sorry ^^)
The sd2snes’s memory sharing technology allows you to read and write memory while your code is running.
There is no command reference at the moment but take a look at cli.c to get an idea: https://github.com/mrehkopf/sd2snes/blo ... /src/cli.c
If you want to upload by wire right now, you can use the serial UART console. It’s available on the 14-pin header on the side of the board, using the pins marked TX3 and RX3 (there’s a pinout table printed on the PCB). It speaks 3.3V 115200 8N1, no flow control, and supports xmodem uploads. When the sd2snes is running you enable the serial console by sending an ESC character. It prompts you with a ‘> ‘.
Relevant commands are put <filename> and load <filename>.
put <filename> requests an xmodem transfer from your side. It might take a longer time for the transfer to start (~30s) if you don’t respond within three seconds… I’m not sure why. Might as well be some issue with my specific xmodem client…
load <filename> loads a ROM and executes it, returning to the prompt.
The console supports some other commands that might be handy, such as memory reads and writes, and hex dumps (all on sd2snes on-board memory only, no SNES WRAM, sorry ^^)
The sd2snes’s memory sharing technology allows you to read and write memory while your code is running.
There is no command reference at the moment but take a look at cli.c to get an idea: https://github.com/mrehkopf/sd2snes/blo ... /src/cli.c
Ok, thank you all! As I suspected, nothing is really implemented yet. UART would be quite slow I suspect, and regarding wifi SD cards, I have never seen one able to receive data (only send). Anyway, for now I was only curious over the USB port and not about other options. For now it seems like it's not usable for what I want to do.
johey wrote:
Ok, thank you all! As I suspected, nothing is really implemented yet. UART would be quite slow I suspect, and regarding wifi SD cards, I have never seen one able to receive data (only send). Anyway, for now I was only curious over the USB port and not about other options. For now it seems like it's not usable for what I want to do.
Ah, that was in response to my question... I never got around to fit a nice little serial interface on my SD2SNES, but since nothing's happened with the USB interface since then maybe it's time now. 115200bps isn't too bad compared to the current alternative for testing a ROM (eject SD from SD2SNES, insert in computer, mount, copy file, eject, insert, navigate to file via the sd2snes interface...). At least not when working with a 64KB image, which is usually enough for testing stuff. Having the serial connection active for some caveman debugging while the code is running is pretty nice as well.
This cable should do the trick, right? PL2303HX-USB-to-TTL-Serial-Cable
Serial cable and header strip ordered! Thinking about usage, it would indeed be neat to facilitate printing from the SNES side via an MMIO register. Maybe right above the MSU-1 registers at $00-3f:2008/$80-bf:2008. While connected, any bytes written there would simply be printed over the TTY.
Hi, a year ago i patched the sd2snes firmware for usb uploads.
Yesterday i posted a link on another forum and sanni reminded me, that here is an active thread on this topic, too.
It's a good idea to have the USART Adapter connected as well for debug outputs. ^^
Example:
Upload rom + sram - COM4
./usb2snes --device=4 --sram --write --file=myrom.srm
./usb2snes --device=4 --write --file=myrom.smc
./usb2snes --device=4 --boot
Hint:
some games have an additional 512byte backup unit header,
use the --skip option here
greetings, saturnu
Yesterday i posted a link on another forum and sanni reminded me, that here is an active thread on this topic, too.
It's a good idea to have the USART Adapter connected as well for debug outputs. ^^
Example:
Upload rom + sram - COM4
./usb2snes --device=4 --sram --write --file=myrom.srm
./usb2snes --device=4 --write --file=myrom.smc
./usb2snes --device=4 --boot
Hint:
some games have an additional 512byte backup unit header,
use the --skip option here
greetings, saturnu
If you still need to upload via USART, here is my old xmodem upload script.
Serial upload-script for linux v0.1
What's needed:
USB to UART with +3.3V TTL Adapter
i'm using a PL-2303HX
http://www.dx.com/p/pl2303hx-usb-to-ttl-converter-module-149859#.U_HgrnWfnIY
Connection:
sd2snes 14-pin-connector 6 (TX3) to uart RX
sd2snes 14-pin-connector 7 (RX3) to uart TX
Howto:
- install the minicom and lrzsz packages
- add user to uucp group
# usermod -a -G uucp saturnu
- relogin the user
- start and config minicom once
115200 8N1
no flowcontrol
- set the script executable
# chmod +x upload.sh
- start the script with filename and device
# ./upload.sh homebrew.sfc /dev/ttyUSB0
- wait until script asks to start the snes
- wait until game starts
upload.sh
xmodem.script
Serial upload-script for linux v0.1
What's needed:
USB to UART with +3.3V TTL Adapter
i'm using a PL-2303HX
http://www.dx.com/p/pl2303hx-usb-to-ttl-converter-module-149859#.U_HgrnWfnIY
Connection:
sd2snes 14-pin-connector 6 (TX3) to uart RX
sd2snes 14-pin-connector 7 (RX3) to uart TX
Howto:
- install the minicom and lrzsz packages
- add user to uucp group
# usermod -a -G uucp saturnu
- relogin the user
- start and config minicom once
115200 8N1
no flowcontrol
- set the script executable
# chmod +x upload.sh
- start the script with filename and device
# ./upload.sh homebrew.sfc /dev/ttyUSB0
- wait until script asks to start the snes
- wait until game starts
upload.sh
Code:
#!/bin/bash
if [[ $# -eq 0 ]] ; then
echo 'sd2snes uploader script - by saturnu'
echo 'upload.sh <file> <device>'
echo 'upload.sh test.smc /dev/ttyUSB0'
exit 0
fi
TMP_BN=$(basename $1)
TMP_DN=$(dirname $1)
cat xmodem.script | sed -e 's/fname/'$TMP_BN'/' -e "s|path|"$TMP_DN"/|g" > xmodem.tmp
minicom -D $2 -S xmodem.tmp
rm xmodem.tmp
if [[ $# -eq 0 ]] ; then
echo 'sd2snes uploader script - by saturnu'
echo 'upload.sh <file> <device>'
echo 'upload.sh test.smc /dev/ttyUSB0'
exit 0
fi
TMP_BN=$(basename $1)
TMP_DN=$(dirname $1)
cat xmodem.script | sed -e 's/fname/'$TMP_BN'/' -e "s|path|"$TMP_DN"/|g" > xmodem.tmp
minicom -D $2 -S xmodem.tmp
rm xmodem.tmp
xmodem.script
Code:
verbose on
print "script loaded - please start snes"
sleep 2
expect {
"ok"
timeout 10 goto panic
}
print "\nneed prompt\n"
sleep 1
send "^["
expect {
">"
timeout 10 goto panic
}
print "set filename\n"
send "put fname"
expect {
"OK, start xmodem transfer now."
}
! sx pathfname
expect {
">"
}
send "load fname"
panic:
! killall -20 minicom
print "script loaded - please start snes"
sleep 2
expect {
"ok"
timeout 10 goto panic
}
print "\nneed prompt\n"
sleep 1
send "^["
expect {
">"
timeout 10 goto panic
}
print "set filename\n"
send "put fname"
expect {
"OK, start xmodem transfer now."
}
! sx pathfname
expect {
">"
}
send "load fname"
panic:
! killall -20 minicom
saturnu wrote:
Hi, a year ago i patched the sd2snes firmware for usb uploads.
Yesterday i posted a link on another forum and sanni reminded me, that here is an active thread on this topic, too.
It's a good idea to have the USART Adapter connected as well for debug outputs. ^^
Yesterday i posted a link on another forum and sanni reminded me, that here is an active thread on this topic, too.
It's a good idea to have the USART Adapter connected as well for debug outputs. ^^
You should do a merge request to integrate it in the official repos.
Thanks anyway, i will test that tonight.
Do you think it might be possible to have a linux / macosx build of usb2snes ?
ikari_01 has the firmware patchset and source since about a year now. ^^
he is still busy with other features that have a higher priority for him, like an upcoming wallpaper support. (but it's still on the agenda)
i've already attached a linux 64bit static binary as well.
as the business man says, "in the long run we are all dead".
so i decided to release it as an interim solution anyway.
if someone really needs to improve this for personal needs, i can upload the source to my github account. ^^
he is still busy with other features that have a higher priority for him, like an upcoming wallpaper support. (but it's still on the agenda)
i've already attached a linux 64bit static binary as well.
as the business man says, "in the long run we are all dead".
so i decided to release it as an interim solution anyway.
if someone really needs to improve this for personal needs, i can upload the source to my github account. ^^
saturnu wrote:
if someone really needs to improve this for personal needs, i can upload the source to my github account. ^^
I would not mind to have access so I can make a osx build.
here is the link to the github repo, if you want to compile the upload tool under osx
https://github.com/saturnu/usb2snes
https://github.com/saturnu/usb2snes
Hey, saturnu,
thanks a lot, this could indeed come in handy.
However, when trying to issue any command like you posted, I get a "character device file does not exist" error, whatever that means. I tried it with --device=0 through --device=5.
What am I doing wrong (aside from not using Windows
)?
thanks a lot, this could indeed come in handy.
However, when trying to issue any command like you posted, I get a "character device file does not exist" error, whatever that means. I tried it with --device=0 through --device=5.
What am I doing wrong (aside from not using Windows
)?I looked at the code. You need to specify the full path of the serial port device in /dev, i.e. --device=/dev/ttyS0. It's going to vary based on disto, kernel, and serial port IC; sometimes it's /dev/ttyACMx. You'll need to dig around in dmesg and so on to figure out what the appropriate device name is. Important: the device needs to be a character device, not a block device. ls -l will show you this; see the far left field ("d" meaning directory, etc.)? "c" means character device, "b" means block device, etc..
The port may need to be pre-configured for 9600 baud, 8N1 (tou can accomplish this with stty), BUT, it looks like init_portio() should do this for you through cf*speed() functions and setting the appropriate terminal capabilities on the device.
P.S. -- I want to say that it makes me very happy to see this type of code in this day and age. Yeah, there's a lot of use of magic numbers in it, so it needs to be cleaned up, but it's a great example of serial I/O interfacing on *IX -- something that isn't done much any more. Seeing it made me happy. :-)
The port may need to be pre-configured for 9600 baud, 8N1 (tou can accomplish this with stty), BUT, it looks like init_portio() should do this for you through cf*speed() functions and setting the appropriate terminal capabilities on the device.
P.S. -- I want to say that it makes me very happy to see this type of code in this day and age. Yeah, there's a lot of use of magic numbers in it, so it needs to be cleaned up, but it's a great example of serial I/O interfacing on *IX -- something that isn't done much any more. Seeing it made me happy. :-)
first you need to put the usb firmware into the /sd2snes folder.
after starting the snes, the os should detect the new usb device.
under windows you may want to install the sd2snes.inf file, but for me using windows 10, the cdc device was recognized out of the box.
check out the device manager "Ports (COM & LPT)" to see what COM number is mapped to the device.
if there is something new under "Other devices" try to use the sd2snes.inf as a driver.
i'm not sure from memory, if you need to start usb2snes.exe as administrator or not.
COM6 would be:
# usb2snes.exe --device=6
under linux it's using the cdc_acm module
# lsmod
Module Size Used by
cdc_acm 32768 0
# dmesg
[ 1022.869276] usb 1-11: new full-speed USB device number 4 using xhci_hcd
[ 1023.055115] cdc_acm 1-11:1.0: ttyACM0: USB ACM device
[ 1023.055253] usbcore: registered new interface driver cdc_acm
[ 1023.055254] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
in this example it's
# usb2snes --device=/dev/ttyACM0
in your case ii looks like you want to use a COM-Port number within linux. ^^
what you really need to specify is the char device filename.
after starting the snes, the os should detect the new usb device.
under windows you may want to install the sd2snes.inf file, but for me using windows 10, the cdc device was recognized out of the box.
check out the device manager "Ports (COM & LPT)" to see what COM number is mapped to the device.
if there is something new under "Other devices" try to use the sd2snes.inf as a driver.
i'm not sure from memory, if you need to start usb2snes.exe as administrator or not.
COM6 would be:
# usb2snes.exe --device=6
under linux it's using the cdc_acm module
# lsmod
Module Size Used by
cdc_acm 32768 0
# dmesg
[ 1022.869276] usb 1-11: new full-speed USB device number 4 using xhci_hcd
[ 1023.055115] cdc_acm 1-11:1.0: ttyACM0: USB ACM device
[ 1023.055253] usbcore: registered new interface driver cdc_acm
[ 1023.055254] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
in this example it's
# usb2snes --device=/dev/ttyACM0
in your case ii looks like you want to use a COM-Port number within linux. ^^
what you really need to specify is the char device filename.
Thanks, guys. I'm on Linux, and honestly, I have no idea how to determine a specific USB port's (that my USB-->USB mini cable is connected to, with the sd2snes connected on the other end, and powered) device name. My workstation has 8 USB 2.0 ports, in case that helps.
Bildschirmfoto vom 2016-08-30 22-25-00.png [ 85.65 KiB | Viewed 2284 times ]
Aww, never mind. I can still go by the old method of transferring my ROM onto the card, etc.
Attachment:
Bildschirmfoto vom 2016-08-30 22-25-00.png [ 85.65 KiB | Viewed 2284 times ]
Aww, never mind. I can still go by the old method of transferring my ROM onto the card, etc.
koitsu wrote:
something that isn't done much any more.
it's an easy way to get around using extra proprietary drivers or libusb (on any of the major os). ^^
... and you don't have to hassle with driver signing by microsoft (or the installation of unsigned drivers).
btw: the project has a pid
http://pid.codes/org/ikari_01/
[$tt@nana ~]. lsusb --tree
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 11: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 11: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 14: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
or just use
[$tt@nana ~]. dmesg
to see if a new device registered
try /dev/ttyACM0 instead of /dev/ACM0
or /dev/ttyUSB0
/dev/ttySx are more or less real oldschool serial ports
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 11: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 11: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 14: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
or just use
[$tt@nana ~]. dmesg
to see if a new device registered
try /dev/ttyACM0 instead of /dev/ACM0
or /dev/ttyUSB0
/dev/ttySx are more or less real oldschool serial ports
Thank you, saturnu! With dmesg, I was indeed able to identify the sd2snes' port, but still ...
Bildschirmfoto vom 2016-08-31 20-54-17.png [ 62.01 KiB | Viewed 2240 times ]
... I get a "device: file open error" even though the ROM file definitely exists, as you can see in the screenshot (note that the error persists even if I use ./furryrpg.sfc instead of plain old furryrpg.sfc). The exact same thing happens for SRAM, BTW.
Sorry to keep you bothering with this, but the --verbose option doesn't really offer any substantial help either, so ...
Attachment:
Bildschirmfoto vom 2016-08-31 20-54-17.png [ 62.01 KiB | Viewed 2240 times ]
... I get a "device: file open error" even though the ROM file definitely exists, as you can see in the screenshot (note that the error persists even if I use ./furryrpg.sfc instead of plain old furryrpg.sfc). The exact same thing happens for SRAM, BTW.
Sorry to keep you bothering with this, but the --verbose option doesn't really offer any substantial help either, so ...
"device: file open error" isn't talking about the ROM not being open-able, it's talking about the /dev/ttyACM3 device. I will give you the root cause/answer at the end, but here's the code:
Flags O_RDWR = open device with read-write capability, O_NOCTTY = don't assign a controlling terminal (this matters for tty devices, which sometimes serial devices can be classified as). In other words: the Linux kernel (and/or device drivers) rejects the open() call (returns -1); the author of this code could do well to use perror() or strerror() to print human-readable errno so that you could at least get a little more detail. In this case, I would bet money errno==EACCES (Permission denied). Had the program done that, you would've had a little more idea what might be wrong (maybe).
But the root cause of why this isn't working? You're running this program as yourself, a non-root user. Serial devices (and most devices in general!) cannot be opened by non-root users. Try putting sudo in front of the entire command you're doing, or switch to root entirely (sudo -i then run the commands). I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
You can even see that the usage syntax for this command (usb2snes -h or --help) advocates it in the code (I have no clue why this usage syntax tries to show a *IX device path as \dev\ttyACMx -- these slashes are backwards/wrong, *IX uses / not \.)
Code:
if( check_chr(device) != 1) {
printf("character device file does not exist!\n");
return -1;
}else{
fd=open(device, O_RDWR | O_NOCTTY);
if (fd==-1) {
printf("device: file open error\n");
}
}
printf("character device file does not exist!\n");
return -1;
}else{
fd=open(device, O_RDWR | O_NOCTTY);
if (fd==-1) {
printf("device: file open error\n");
}
}
Flags O_RDWR = open device with read-write capability, O_NOCTTY = don't assign a controlling terminal (this matters for tty devices, which sometimes serial devices can be classified as). In other words: the Linux kernel (and/or device drivers) rejects the open() call (returns -1); the author of this code could do well to use perror() or strerror() to print human-readable errno so that you could at least get a little more detail. In this case, I would bet money errno==EACCES (Permission denied). Had the program done that, you would've had a little more idea what might be wrong (maybe).
But the root cause of why this isn't working? You're running this program as yourself, a non-root user. Serial devices (and most devices in general!) cannot be opened by non-root users. Try putting sudo in front of the entire command you're doing, or switch to root entirely (sudo -i then run the commands). I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
You can even see that the usage syntax for this command (usb2snes -h or --help) advocates it in the code (I have no clue why this usage syntax tries to show a *IX device path as \dev\ttyACMx -- these slashes are backwards/wrong, *IX uses / not \.)
Code:
if( gopt( options, 'h' ) ) {
#ifdef __unix__
//unix
fprintf( stdout, "Syntax: sudo ./usb2snes -d \\dev\\ttyACMx [options] ...\n\n");
#ifdef __unix__
//unix
fprintf( stdout, "Syntax: sudo ./usb2snes -d \\dev\\ttyACMx [options] ...\n\n");
koitsu wrote:
Serial devices (and most devices in general!) cannot be opened by non-root users. Try putting sudo in front of the entire command you're doing, or switch to root entirely (sudo -i then run the commands).
Thanks, koitsu, but no thanks.
Sorry, but we aren't living in the early 2000s any more, where you had to open a root shell just to enable WiFi functionality for your state-of-the-art notebook. If this (i.e., root access to my system) is what this software requires to run, then goodbye and Godspeed, software. Reverting back to vanilla 0.1.7c in 3 … 2 … 1 … bam.
A better option than becoming root would be to either add yourself to the "dialout" group (at least that's what it's called on debian, you can look at the /dev/ttyACM* node to find out what group owns it), or to change the permissions on the /dev/ttyACM* node so that you can access it as an unprivileged user.
for me it's uucp and yes the backslash instead of a slash is of course a typo. ^^
crw-rw---- 1 root uucp 166, 0 31. Aug 21:38 /dev/ttyACM0
# usermod -a -G uucp saturnu
crw-rw---- 1 root uucp 166, 0 31. Aug 21:38 /dev/ttyACM0
# usermod -a -G uucp saturnu
lidnariq wrote:
A better option than becoming root would be to either add yourself to the "dialout" group (at least that's what it's called on debian, you can look at the /dev/ttyACM* node to find out what group owns it), or to change the permissions on the /dev/ttyACM* node so that you can access it as an unprivileged user.
Not going to do any of that, either.
Does ucon64 require root privileges? Does it require any workaround BS (sorry)? No! No, it doesn't. I know because I've been using ucon64 with my SWC devices for ages, even on 64-bit Linux systems.
So why would any new transfer software require higher user privileges than ucon64 does? … Right. Don't use this software (sorry, saturnu).
I covered this in:
...but now I'm apparently having to do exactly that.
If you want to accomplish this, go look at the ownership and permissions on /dev/ttyACM3. It's probably owned by root, possibly group wheel. Check the permissions: does group have read/write access, or just read? If the group has read/write access, then add yourself to whatever that group is (it might be wheel, it might be dialout, it might be something else), then you should have the ability to R/W the device without being root.
If the group has no read/write access at all, then you need to look into what is managing the devices on your Linux distro to figure out how you can improve/change the permissions for that device. As stated: devfs and systemd are the two main ones on Linux right now. You *absolutely* can do this, including giving it its own group (lidnariq mentioned the group dialout, but it can be whatever; see /etc/group).
As a crappy workaround, you could also avoid worrying about the group entirely and just tweak whatever (devfs/systemd rules) to make the device have permissions of 0666 (specifically: globally read/write) so that you don't even need to worry about the group. The security risk here is that any user (including any non-root process or daemon) could be able to access the device. It's your call.
Quote:
I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
...but now I'm apparently having to do exactly that.
If you want to accomplish this, go look at the ownership and permissions on /dev/ttyACM3. It's probably owned by root, possibly group wheel. Check the permissions: does group have read/write access, or just read? If the group has read/write access, then add yourself to whatever that group is (it might be wheel, it might be dialout, it might be something else), then you should have the ability to R/W the device without being root.
If the group has no read/write access at all, then you need to look into what is managing the devices on your Linux distro to figure out how you can improve/change the permissions for that device. As stated: devfs and systemd are the two main ones on Linux right now. You *absolutely* can do this, including giving it its own group (lidnariq mentioned the group dialout, but it can be whatever; see /etc/group).
As a crappy workaround, you could also avoid worrying about the group entirely and just tweak whatever (devfs/systemd rules) to make the device have permissions of 0666 (specifically: globally read/write) so that you don't even need to worry about the group. The security risk here is that any user (including any non-root process or daemon) could be able to access the device. It's your call.
koitsu wrote:
I covered this in:
...but now I'm apparently having to do exactly that.
Quote:
I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
...but now I'm apparently having to do exactly that.
No.
Again, check out ucon64. There's just no need for root permissions in this day and age.
you don't have to apologize, to honest - i don't really care if you use it or not. ^^
it's ok that you are a linux beginner and i think someone else can still profit from the infos on this thread.
it's ok that you are a linux beginner and i think someone else can still profit from the infos on this thread.
saturnu wrote:
it's ok that you are a linux beginner
Da lachen ja die Hühner.
Ramsis wrote:
Does ucon64 require root privileges? Does it require any workaround BS (sorry)? No! No, it doesn't. I know because I've been using ucon64 with my SWC devices for ages, even on 64-bit Linux systems.
So why would any new transfer software require higher user privileges than ucon64 does? … Right. Don't use this software (sorry, saturnu).
I'm sorry, why do you think that you should by default be allowed as an ordinary user to connect to a serial port when that serial port might be used by something privileged (such as, say, a cellular modem containing your network connection) ?So why would any new transfer software require higher user privileges than ucon64 does? … Right. Don't use this software (sorry, saturnu).
That's why you should explicitly set it up such that you can access the serial port. There is no other way to opt in to the elevated permissions necessary to talk to the serial port. (Go ahead and try. Any such program will either fail, or be setgid)
Ramsis wrote:
koitsu wrote:
I covered this in:
...but now I'm apparently having to do exactly that.
Quote:
I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
...but now I'm apparently having to do exactly that.
No.
Again, check out ucon64. There's just no need for root permissions in this day and age. :!:
Show me how you use ucon64 with a device (serial port, parallel port, etc.) on *IX. Then show me the permissions of that device (ls -l).
Your reluctance to accept how *IX is designed (the security aspect of devices), as well as the fact that you can solve this easily through configurations (it's not difficult! This is UNIX 101 stuff), is cute. The reason devices are special on *IX is because *IX as a multi-user system, where you do not want and end-user doing something like, say, writing zeros to the entire hard disk device; serial ports, printer ports, USB ports, VGA framebuffers, ttys (each users' shell gets one), the on-board speaker, etc. all fall under this category. It's like you're actually/intentionally being belligerent to how to solve the problem both 1) correctly, and 2) securely. :\ You DO NOT have to use sudo, but if you don't, you have to make sure your Ramsis user is in the correct group and the device has the proper R/W permissions for the group. Seriously: that's it!
@Ramsis: How do you use the sd2snes serial console or program it using OpenOCD? The same problems apply there. OpenOCD brings its own udev rules for a number of FT2232 adapters though, so you might just not have noticed.
saturnu wrote:
koitsu wrote:
something that isn't done much any more.
it's an easy way to get around using extra proprietary drivers or libusb (on any of the major os). ^^
... and you don't have to hassle with driver signing by microsoft (or the installation of unsigned drivers).
btw: the project has a pid
http://pid.codes/org/ikari_01/
Oh, that's really cool. I've been looking for somebody to do something like that ever since the USB-IF racket revoked the MCS VID (not that I really care, I bought a couple anyway, in addition to the handful of freebies I've gotten from Microchip). I really hope the way that they're managing the project keeps them from running afoul of the USB-IF the way MCS did, though even if they did, they'll probably just continue on anyway like MCS has.