I've been trying to make the serial communication work on my BBB for days now and I am running out of ideas.
When I use just the BBB and connect MISO/MOSI I get the signal transfer on MOSI, SCLK and CS (MISO is mainly at high level). However, when I connect the lines to my slave part it does not work. I checked the signals on the oscilloscope and they seem fine and the part which I am using as the slave is working well when I set it in parallel mode, so I believe some programming or configuration must be wrong.
This is basically what I do:
config-pin P9.17 spi_cs
config-pin P9.18 spi
config-pin P9.21 spi
config-pin P9.22 spi_sclk
python
from Adafruit_BBIO.SPI import SPI
spi = SPI(1,0) #I would expect SPI(0,0) here, but I get the signal on the above configured ports
Then I set the configurations (already tried in many ways):
spi.mode = 0
spi.cshigh = False
spi.msh = 10500000
spi.bpw = 16
spi.lsbfirst = False
After that I open it and try to send data:
spi.open(1,0)
spi.xfer2([1,254])
If anyone is interested, I am trying to program the LMH6517 as slave and I already tried to ask about this at the TI forum here:
https://e2e.ti.com/support/amplifiers/f/14/t/751415
Oscilloscope images:
CS and SCLK
MOSI and SCLK
MISO and SCLK
Thank you,
JPL
I found dev-USB-PWR-CTL-00A1.dtbo file. (I think this is source code for it).
Using this file I try to expose USB1_DRVVBUS pin as GPIO (GPIO3_13) with commands:
echo dev-USB-PWR-CTL > /sys/devices/platform/bone_capemgr/slots
echo 109 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio109/direction
I see new cape entry in slots and new gpio files tree.
But when I change value with command
echo 0 > /sys/class/gpio/gpio109/value
I see new value in this file but nothing happens with USB VBUS.
What am I missing?
(Before you ask do I really need this: let's leave the consequences on the side for a moment.)
Have you looked at this? question about exactly this on the Beagleboard Google Group
Please note that there are some differences to back then and current images, e.g. by default CapeManager is disabled and overlays are loaded once in U-Boot
If you are using a recent elinux.org Debian image (the necessary device tree overlay was merged in June 2015), it includes a device tree overlay (with the comment "Unless you know what you are doing, do not load this cape!!!"). This uses a hack to expose the usb1_drvvbus signal as a fictitious LED, which can then be controlled using the led interface in /sys.
Firstly, load the dev-USB-PWR-CTL-00A1.dtbo device tree overlay. For recent setups (where all dtbos are loaded by uboot and then passed to the kernel at boot time), this could be done by adding dtb_overlay=/lib/firmware/dev-USB-PWR-CTL-00A1.dtbo to /boot/uEnv.txt and rebooting (older kernels/uboots will need to use the older config mechanisms as described in /boot/uEnv.txt).
You can then do this:
echo 'usb1' > /sys/bus/usb/drivers/usb/unbind
echo 0 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
sleep 1
echo 255 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
echo 'usb1' > /sys/bus/usb/drivers/usb/bind
... to power-cycle the device attached to USB1.
I have run into some problem controlling usb1' power. as I investigated from
"https://e2e.ti.com/support/arm/sitara_arm/f/791/t/270060" It tells me that GPIO3_13 controls usb1_drvvbus pin, which controls the usb power.
I understand that there is software method to change the voltage of this pin.
My question is that where is GPIO3_13 located on P8 or P9 expansion bays? I cannot find it on any diagrams. Is it purposefully not exposed anywhere?
You can control USB1 power from software on the beaglebone, if you are using a recent elinux.org Debian image (the necessary device tree overlay was merged in June 2015). This uses a hack to expose the usb1_drvvbus signal as a fake LED, which can then be controlled using the files in /sys.
Firstly, load the dev-USB-PWR-CTL-00A1.dtbo device tree overlay. For recent setups (where all dtbos are loaded by uboot and then passed to the kernel at boot time), this could be done by adding dtb_overlay=/lib/firmware/dev-USB-PWR-CTL-00A1.dtbo to /boot/uEnv.txt and rebooting (older kernels/uboots will need to use the older config mechanisms as described in /boot/uEnv.txt).
You can then do this:
echo 'usb1' > /sys/bus/usb/drivers/usb/unbind
echo 0 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
sleep 1
echo 255 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
echo 'usb1' > /sys/bus/usb/drivers/usb/bind
I am using a Beaglebone Black with the most recent OS (Debian Jessie, kernel v4.1). I need to be able to use pin P9_19 as a GPIO pin, but pin 19 has already been assigned to I2C_2_SCL.
When I try to use it, I get the error (octalbonescript):
The pin P9_19 is not availble to write. Please make sure it is not used by another cape.
How can I unload the I2C cape to expose pin P9_19 for GPIO access?
There are many ways to do that.
Using device tree overlay: echo cape-universaln dtbo file to slots
or use this link to gernerate overlay file for gpio purpose, compile source dts file using
dtc -O dtb -o /lib/firmware/bspm_P9_19_17-00A0.dtbo -b 0 -# /lib/firmware/bspm_P9_19_17-00A0.dts
and then deploy output dtbo file to /lib/firmware and then echo it to slots.
Also I personally recommend you to use this amazing library Wirigbone for beaglebone, this is by far best for beaglbone.
I have a Zebra GK420d connect to OS X via CUPS. However, when I send files to it that are written in ZPL or EPL they are only printed in plain text.
Am I required to change to mode on the printer?
Contrary to what others said, you don't need to specially add a raw queue.
Instead, you can submit raw files into any queue using -o raw switch:
lpr -P CupsPrinterName -o raw path/to/label.zpl
Printer name can be found over that link in CUPS:
http://localhost:631/printers/
This also works on other platforms that use CUPS, like Linux.
You can create a raw CUPS queue with lpadmin. Here's the command line I used:
lpadmin -p Zebra -E -v usb://Zebra%20Technologies/ZTC%20LP%202824%20Plus?serial=XXXXXX -m raw
You can also set up a raw queue using the CUPS web admin at
http://127.0.0.1:631/
This is a bit more comprehensive answer since I seem to be returning to this question every couple of years. To print with a Zebra or other barcode printers in Linux from command line follow these steps:
List all printer targets and find the printer you want to use:
$ lpinfo -v
network https
serial serial:/dev/ttyS0?baud=115200
serial serial:/dev/ttyS1?baud=115200
network lpd
direct hp
direct usb://GODEX/G500?serial=162203C6
network smb
...
Add new queue:
$ lpadmin -p godex -E -v usb://GODEX/G500?serial=162203C6 -m raw -o usb-unidir-default=true
If your printing is slow (takes long to start), please make sure you added -o usb-unidir-default=true.
Check available queues:
$ lpstat -v
device for godex: usb://GODEX/G500?serial=162203C6
Create a label (text file):
Create a file according to your printer's requirements in EPL (Zebra), ZPL (Zebra), EZPL (Godex).
Warning, certain CUPS versions might have an issue with raw files if they are under 512 bytes of length - longer files will print, while shorter will print once and then stall for a couple of minutes (looks like there is a timeout built in). A workaround is to add comments to extend it over 512 byte limit.
Example Zebra file (test.epl):
N
A20,20,0,2,1,1,N,"text"
B20,40,0,1,1,1,30,N,"aaaa-bbbb-cccc"
P1
Example Godex file (test.ezpl):
;set portrait orientation
^XSET,ROTATION,0
;set height 20mm
^Q20,1
;set width 64mm
^W64
;start label
^L
;AA=print out text with smallest font, x=20dots, y=20dots, magnificationx=0, magnificationy=0, gap=1dot, rotationInverse=0 (no)
AA,20,20,0,0,1,0,Some sample text
;BQ=code128, x=20dots,y=40dots,narrow_bar_width=1,wide_bar_width:2,height=30dots,rotation=0deg,readable=0(no)
BQ,20,40,1,2,30,0,0,1234-1243-43214-432141
;end label
E
Push to printer:
$ lpr -P godex test.ezpl
You would need to avoid any filtering. Print using a RAW filter, as configured in the CUPS interface, or by default in your lpadmin statement. You did not state how the printer was connected, but if IP, your destination would most-likely be socket://ip.addr.ess:9100.
I am a PC guy so I don't know CUPS well, but I have used zpl and epl on PC's and found that they really like to get the raw print files. I always do a :
filecopy "c:\zplfile.txt" "\computername\printershare" type command.
I have used wordpad too, if I just want to do some text. But for labels and barcodes I would see if there is a way for you to send the raw zpl or epl to the printer port. Hope this helps.
Thanks. I have looked at it some more. It seems that while using cups you cannot send raw ZPL commands to the printer. Like what I did was create the printer in cups as a socket and started a netcat listener on 9100 and then issued some sort of command to the printer
nc -l localhost 9100
zpl_mine="^XA ~SD10 ^PW 850 ^MM T ^MN W ^JUS ^XZ,";echo $zpl_mine | nc localhost 9100 -w 1
and this does not send the information to the printer, but I have seen on some forums that you have to use some form of language like C to parse the information