I am trying to enable Arduino-like serial output for my BeagleBone Rev5.
From what I understand the UART mapping is like this:
UART0 <=> /dev/ttyO0
I am running the latest Angstrom distro:
http://downloads.angstrom-distribution.org/demo/beaglebone/Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.04.13.img.xz
I have disabled the Angstrom default getty on /dev/ttyO0 by modifying this file:
/etc/systemd/system/getty.target.wants/serial-gett#ttyO0.service
(gleaned from this question: Automatic login on Angstrom Linux)
I commented everything out which I believe should stop getty from starting on that port. Once done I rebooted the board and am no longer able to connect via serial console so that seemed to work.
But I now cannot find any reliable information on how to configure that UART so I can transmit data. I have looked extensively but all the documentation refers to older versions of Angstrom that don't seem to reflect the most recent release.
For example they all say to exec a command like this:
root#beaglebone:~# cat /sys/kernel/debug/omap_mux/uart1_rxd
(http://www.gigamegablog.com/2012/01/22/beaglebone-coding-101-using-the-serial-and-analog-pins/)
But when I try that, there's nothing there:
root#beaglebone:/sys/kernel/debug# ls
asoc gpio musb-hdrc.0.auto regulator usb
atmel_mxt_ts hid musb-hdrc.1.auto sched_features wakeup_sources
bdi iio pinctrl suspend_stats
bluetooth kprobes pm_debug tracing
dri memblock pwm ubi
f2fs mmc0 regmap ubifs
root#beaglebone:/sys/kernel/debug#
The latest release of Angstrom seems to be from April 2013 which is much newer than most of the blog posts I've seen regarding this. It seems that the new version of Angstrom does things differently than the old versions. Does anyone have any idea how to actually USE the various hardware on the new versions of Angstrom/BeagleBone?
root#beaglebone:/sys/kernel/debug# uname -a
Linux beaglebone 3.8.6 #1 SMP Sat Apr 13 09:10:52 CEST 2013 armv7l GNU/Linux
root#beaglebone:/sys/kernel/debug#
I'd love a specific answer but would be quite satisfied with any information I can get regarding how things work in the newer versions of Angstrom.
EDIT:
Turns out I just didn't try hard enough. I plugged the BeagleBone into the network and did
opkg update
opkg install python-pyserial
Once that was done I was able to write a small program that would dump out over the built-in serial/USB port (/dev/ttyO0) at whatever data rate I want.
With getty for serial disabled I can write as much as I'd like without issue. If the getty is turned back on it'll interrupt my connection whenever it detects something is happening at a slower speed, at that slower speed.
Thanks for all the help. I especially appreciate the information about how nothing is figured out re:device tree since that's a problem I'm going to face myself as I try and use a BeagleBone for other projects.
The command you showed has nothing to do with baud rate, it controls pin muxing. Many microcontrollers have many more peripheral functions than I/O pins, so the I/O pins need to be mapped to peripherals, and not all connections are possible. For your case, you need to designate particular pins as UART transmit and receive.
I haven't done it myself, but I found a considerable amount of documentation describing that control of pin muxing via sysctl and the proc filesystem was recently replaced with a new system based on Device-Tree. And that as a result virtually all existing examples are broken. Worse, there may not even be a working device-tree-based equivalent for some commands.
As far as setting the baudrate, you would normally use cfsetispeed() and cfsetospeed() from termios.h, as described in the Unix specification.
You don't specify the language you want to use.
In any case, I think you'd better study the Serial Programming Guide for POSIX Operating Systems, which will give you al lot of informations about how serial ports are handled in Linux
Related
I need to count the transitions of a 50KHz binary signal using a BBB. I think using the TIMER4 triggered by the external signal connected to the pin P8.07 would be the easiest way.
So, I issued the following commands to load the proper cape and setup the pin as a timer :
./config-pin overlay cape-universaln
./config-pin P8.07 timer
Everything seems to work and nothing appears in dmesg.
My question is : How can I read the value of TIMER4 ? I looked in SysFs and find nothing interesting. Nothing in /dev as well. How can I retrieve the value of the timer counter I just setup ? I'm open to a C/C++ solution as well, but I would like to avoid doing kernel-space programming.
I'm using the latest Ubuntu Linux for BeagleBone, kernel 4.1.10-ti-r21.
With a little googling I see a pps driver for the AM335x DMTimer subsystem here: https://github.com/ddrown/pps-gmtimer
It looks like it hasn't been merged upstream and the README gives instructions on building it into the 3.8 kernel - you could revert back to 3.8, or you could adapt that for 4.1, in which case you may need to tweak the Device Tree overlay as well for the newer version of the dtc compiler that's in 4.1.
You could also write a pulse counter firmware for the PRU (with only a 50KHz input it wouldn't need to be very optimized at all to catch every pulse). You could send a signal to the ARM every so often and catch that in your userspace program.
Another option would be to directly access the DMTimer registers from userspace using mmap to map the /dev/mem file (example of this method for GPIO here), but that's a pretty "hacky" way to do it, and it's generally frowned upon in the GNU/Linux world to do that sort of stuff from userspace instead of from kernal space.
So I have a Beaglebone black, and a servo/led controller http://www.adafruit.com/product/815. I'd like to control it from a C/C++ program running on the included Debian Linux.
I see there is a driver included in the kernel "pwm_pca9685", and it did create some items in the /sys directory, but nothing that seems to make any sense.
So I know that at least I need to tell the module what i2c address the chip has, so how would I do that, and then how to send various pwm commands to chip?
So I ended up forgoing the use of the driver, as I was unable to find any information on it. Instead I used various ioctl calls, such as is used in this code from Adafruit: https://github.com/adafruit/Adafruit-PWM-Servo-Driver-Library/blob/master/Adafruit_PWMServoDriver.cpp
I have this AT91 SAM9G25 running a Embedded Linux with Busybox as distro. I already checked the datasheet but unfortunately I didn't get far, here's the problem:
There's a Pin SHDN for the shutdown. It is high during boot and I'd like to set it to low when hitting "poweroff" in Busybox - so the system is still powered on at this moment, it's just part of the poweroff-process.
I know I'll have to write a shutdown script in /etc/init.d/ . The problem is, I don't know which is the variable for the SHDN-Pin in Linux for the SAM9G25. Does anyone have an advise ? The only useful thing I got from the datasheet is, that the pin is called "SHDN" Ball=D8, but I can't work with these in Linux.
Thanks for your help
Kind Regards
You can simply use poweroff as there is a driver for the shutdown controller in the linux kernel. That driver is already using:
at91_shdwc_write(AT91_SHDW_CR, AT91_SHDW_KEY | AT91_SHDW_SHDW);
so the SHDN pin should be driven high.
You should try to check your .config file for this configurations
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_AT91_POWEROFF=y
CONFIG_POWER_RESET_AT91_RESET=y
or these:
CONFIG_OLD_CLK_AT91=y
CONFIG_AT91_SAM9_ALT_RESET=y
CONFIG_AT91_SAM9G45_RESET=y
CONFIG_AT91_SAM9_TIME=y
CONFIG_HAVE_AT91_SMD=y
CONFIG_SOC_AT91SAM9=y
depending on your kernel version
I got a RFID reader (GigaTek PCR330A-00) that is meant to be recognized under linux/windows as a (Human Interface Device) keyboard/USB.
I hate to say this but it is working as a charm under Win7 but not "really" under Linux.
Under Debian-like distros (x/k/Ubuntu, Debian,..), or Gentoo, or... I just can't have the device working at all: the device scan well (it has its USB 5V, so it is happy/beeping/blinking) something happened in the dmesg, but no immediate screen display of the RFID Tag code as expected (and seen under win7)
Support is claiming it is ok under RHEL or SLED "enterprises" distros... and I must admit I saw it working under a RHEL4... I tried stealing the driver but did not succeed having my reader working...
My question is thus double:
1./ How can I hack the kernel to add support to my device (simply register PID/VID?) ?
2./ What is different at all in a "enterprise" proprietary distro? how can I re-use it?
Thank you for any hint/help.
Cheers,
If you have the source code of the driver you can compile it against the current Kernel your system uses, since the Kernel only allows drivers for its current version. Then you can try to load it as a Kernel module, notice that by doing this, you do not hack the Kernel you just need your current system's Kernel header to compile the driver against it.
You may want to check this http://www.freesoftwaremagazine.com/articles/drivers_linux in order to grasp the basics.
Hope this helps.
I have a problem probably with my arm toolchain but maybe there's something other that I do wrong. I have Chinese made dev board qq2440 using Samsung s3c2440 ARM9 uC. I'm using Ubuntu x86 with native gcc(4.3.3) and cross-compile version arm-unknown-linux-uclibc-gcc (crosstool-NG-1.3.2) 4.3.2
I followed tutorials from http://blog.leshak.ru/english/pages/how-to-install-u-boot-linux-2629-rootfsjffs2-busybox-1132-into-nand-qq2440/
and used Leshak's kernel patches for that board. Problem is that his binaries work perfectly and mine don't...
I communicate with my board over RS232 (serial port) and I have serial terminal configured on target Linux. I use Leshak's uboot image. To configure my kernel I use following command line:
qq2440> setenv bootargs 'noinitrd root=/dev/mtdblock2 rootfstype=jffs2 rw console=ttySAC0,115200'
For target I use vanilla Linux sources version 2.6.29, with patches created by Leshak. I don't honestly believe that this will ever be supported officially by Linux as it's not mainstream product.
My kernel image starts booting up, but it probably changes bandwidth (or CPU frequency) to some non standard value (tried all standard ones already). Instead of dots indicating loading kernel into memory I've got only trash instead. Unfortunately it doesn't probably finish the boot process as the network interface nor file system don't come up. So I figured out that it panics somewhere in the middle.
Any ideas what should I do next?
Thanks & regards,
Chris
There are a lot of different things that could be going on here.
It sounds like you are talking about a serial port, and that it appears to be giving garbage once control is passed to the kernel from uboot. Am I understanding that correctly?
Look into specifying the baud rate, parity, etc. for the serial console on the kernel commandline.
Oh, and IIRC, there was some 'early_printk' thing in the ARM Linux tree that might help you debug serial console problems. (But I'll warn you -- it's been a couple years since I dealt with that so my memory is fuzzy.)
Double-check that the memory address layout (the locations of all the various devices) matches what your board has. (I think this is probably not the issue, but wanted to mention it for completeness.)
You say that you have a binary kernel that works correctly; compare the kernel config of that kernel to the config you are using for building your kernel. Investigate every difference, particularly any specific to ARM.
You may want to double-check the endianness of your toolchain vs what your board is expecting. Some of the ARM / XScale processors can be configured to big-endian or little-endian in software, so it might be worth double-checking.
Just enable the debug build of the kernel[while building the uImage] so that you get a more clearer picture of the scenario [Just would make your boot up somewhat slow since all the printk's would be enabled].
Can you check whether you are passing the correct parameters to the UART ie. Serial Port Name, it's baud rate etc This would be provided by the board manufacturer-Samsung
WRT the network instead of DHCP can you just assign a static ip address to your system as it might be possible that the DHCP process is still not ON.
Also a better option would be to use NFS but yeah, it depends on your choice and the purpose of your application. To use NFS, your network should be UP & running and your filesystem should be shared.
As retracile has already pointed out "Endianness" could be a point to look into !!!
You can refer this link which might help you out since it is specific to S3C2440
Hope this helps.
-hjsblogger
I had a similar problem at one point when I omitted --send-cmd from picocom. this is the command I issue to picocom for serial uBoot comms with the mini2440.
picocom -b 115200 /dev/ttyS0 --send-cmd "sx -vv"