I recently received a LittleBits Arduino Coding Kit and thought the Arduino IDE would immediately recognize it.
I noticed that when I choose the "Arduino Leonardo" on the Tools -> Board as the instruction video said to do, the Tools -> Serial Port menu is grayed out.
I have already added myself to the "dialout" and "uucp" groups, ran the "arduino" program as root, ran a whole bunch of commands dealing with permissions, restarted the computer, plugged it into all the ports, reinstalled the drivers, and tried everything else I came across. For some reason, I can't figure out how to get this to work.
I use Xubuntu on an i686 architecture by the way, if that even matters.
I think you don't have permissions to read/write the serial port device. Even running Arduino application as root, it's running on a Java JVM, and calls other programs to compile sketches and burn the board... it's hard to figure out what's happening in the background. Also, is not a good idea to run programs as roout unless necessary.
Try this. First list your serial port devices.
ls -l /dev/tty*
There's should be one called /dev/ttyUSB0 or /dev/ttyACM0 or something like that (not /dev/ttySx). That one is your Arduino. Add read/write permissions for every user to that device file.
sudo chmod 666 /dev/ttyUSB0
Use the device you have. Now run the Arduino IDE, if the issue is with permissions, then it's done. Unfortunately, you'll have to do this every time you unplug the board or reboot the system.
Related
I am working with a SOM mounted on a carrier board running Ubuntu 14.04 with the generic 3.13 kernel.
While testing out the peripherals, I hit a problem with serial communication.
Basically, I can transmit data from the custom platform to an external Linux machine, but I can not properly receive data from the external Linux machine to the custom platform.
Through my research I have messed with all sorts of BIOS settings, baud rates, hardware flow control, parity, etc. Nothing has worked. Most info I have found online just says "Make sure your baud rates and other settings match", and they do. It is not my first time working with Linux serial ports. But it is my first time encountering a problem like this.
Does anyone have any suggestions, recommendations, or has anyone ever seen an issue like this before?
More info: We are running a quad-core Intel Atom micro with a custom serial breakout interface. The serial port is at /dev/ttyS0.
EDIT (clarification):
If I set up a session in Picocom or Minicom, I can send characters from our custom platform (running Ubuntu 14.04) to another Linux PC (also running Ubuntu 14.04). However, if I try to send characters from the Linux PC to our custom board, I sometimes get nothing, and other times get unrecognized characters (they show up as bubbles with question marks in them).
I can also simply echo a string to /dev/ttyS0 on the custom platform and receive it on the Linux PC. I just can't get it to work the other way around.
I would like to get started with programming on arduino, and am considering buying this kit https://www.sparkfun.com/products/11930 but I'm concerned about not being able to run this on linux.
I still don't know much about arduino, but could I still run this properly, and still be able to follow the programs without some obvious linux/windows differences?
Also, if anyone has any other reccomendations for some others kits to people new to arduino programming, but not new to programming, I would love to hear them.
The Arduino IDE itself runs fine under Linux (as well as Java programs can), and the compiler works perfectly (it uses GCC under the hood). If you're using a serial connection then it changes from COMxx to /dev/ttyNNNxx (e.g. /dev/ttyUSB0 [although I haven't actually seen it yet since I use a ISP programmer, but it should look something like that]). Also, no extra drivers needed. However, whether you're using a serial connection or a ISP programmer, you'll want to add a udev rule so that user access to the device is allowed.
You can install arduino on Ubuntu with the following command.
sudo apt-get update && sudo apt-get install arduino arduino-core
Is this something you are looking for ?
So I need to read some streaming data from /dev/ttyACM0 in Ubuntu.
However I'm a Windows guys so I'm looking for something like PuTTY so I can point, click and make my problem go away.
How do I get streaming data from a com port, or in this case /dev/ttyACM0 which is a USB cable working as CDC? I just want to confirm that the device is sending what I think it should be sending.
Apparently putty is available on Ubuntu https://apps.ubuntu.com/cat/applications/saucy/putty/ . So, if you installed that you may get the same user experience you are used to from Windows. Alternatively minicom is probably one of the most common alternative ( http://processors.wiki.ti.com/index.php/Setting_up_Minicom_in_Ubuntu ).
I want to install the drivers of the video camera on my linux computer.
I write the command:
modprobe usbserial vendor=... product=...
what I expected to get was ttyUSB0 (or sth simmilar) in the /dev directory.
Instead what is getting installed is sg3 (whatever that is) and when I run a program that is supposed to send a command to start recording I get no results (but no errors either).
(I changed what I had previously: fd = open(/dev/ttyUSB0,...) to /dev/sg3 but I guess this is not a configuration that enables sending this kind of data.
What might be the problem? (Sorry if it's a basic question)
cameras and linux can be tricky.
Start by plugging in the camera and running
lsusb
google for the id to see if anyone has a step by step tutorial or at very least can tell you which modules are needed.
Most common drivers seem to have been migrated to the kernel, so rebulid your kernel make sure the modules are built.
Some more obscure usb modules have to be built by hand.
I have a serial GPS connected to an embedded PC via serial<->USB adapter (Prolific PL2303). Every 5 minutes a shell script runs a Python script that reads GPS data via Pyserial then upload them to Internet. If I plug my GPS directly to the PC (via PL2303) everything is ok and my system runs forever BUT if I use a usb HUB between pl2303 and the PC I have a this problem: the Python script runs ok for about 3-6 hours then it goes in a D-state (uninterruptible sleep) and the shell script cannot run it again (I can only shutdown the system, no kill possible). I checked my script and I used usb hubs from various vendors (powered and not) with the same result.
PS my embedded pc (from Embeddedarm) runs an updated Debian Lenny.
Ho can I fix it ?
A process in D state means the kernel (most probably a device driver), has put your process into uninterruptible sleep.
To be honest, there is probably quite little you can do about it as a user, unless you intend to debug the kernel USB stack and/or specific USB chipset device driver.
Here is what would do -
Make sure the kernel configuration of you embedded device has the kernel config option for the magic sysreq key and the run time configuration for it turned on. See: http://en.wikipedia.org/wiki/Magic_SysRq_key on how to do that.
Recreate the problem (have the process get stuck in D state).
Find out the PID of the stuck python script with ps and run strace -p PID on it. This will give you the specific system call that the process is sleeping in.
Send the magic sysreq key command 't', that lists all tasks and their kernel stack to console. Look for the specific task of the python script by PID, see at what part of the kernel code exactly are you stuck.
Open the kernel code and try to debug the problem if you can, or port it to the relevant mailing list if you don't.
One more suggestion would be to try and see if the problem goes away in a more recent kernel version then Debian ships. If so, you know it is a bug fixed in newer version of the kernel and you have the choice of either using the newer version and try to port the fix to the old version you care using.
Good luck! you'll need it...
Ubuntu launchpad has a bug filed that is suspiciously like yours. The workaround suggested is:
modprobe -r pl2303
modprobe pl2303
See if this works around the bug?