However, every now and then, some gibberish appears. Could these be kernel messages that are being sent to /dev/ttyS0 perhaps? If so, is there a way to turn that off?
However, every now and then, some gibberish appears. Could these be kernel messages that are being sent to /dev/ttyS0 perhaps? If so, is there a way to turn that off?
This is really helpful. First thing I thought was "How could I have missed that?", then I saw the date the page was modified. Thanks!
I disabled both the kernel messages (autoboot.txt) and the attached terminal (/etc/inittab). Still not getting any uart-love on the loopback. I'll try some more later. Didn't run out of all options yet.
Also, never underestimate the probability of me doing it wrong.
@panik: I'm watching You Though I haven't time to hacking HW I like to see some nice Pandora EXT board. I think that reasonable is:
- Keep UART3 for serial communication. Add configurable (jumpers, wire shorts, trace scratch) level shifting
- Convert UART2 lines as galvanically separated 4 inputs/outputs - on board clamps that allow attach button or switched device (LED, motor...)
Code:
(GPIO 145..147) ___
^---[optocoupler]===+--o o----------< (GND/Vcc - whatever is need to get button works)
|
| ,----------< (external pover for device)
+--|<
`-(device)-> (GND)
The biggest problem is interfacing the 1.8V on the PGIO's on the ext-connector. Most IC's and microcontrollers expect input and output to be 5V. That's 'standard' TTL-level.
My current setup is like this (except the 1.8V is coming from the voltage regulator that is powered by 5V, in stead of the Pandora):
The nice thing about the TXB0106 is that it's bi-directional. You don't have to think beforehand if a GPIO is going to be an input or an output. Simply put 1.8V on a pin on the Pandora-side, and out comes 5V on the other side. Put 5V on an 'outside circuit'-pin, and out comes 1.8V on the Pandora-side. The TXB0106 figures out what to do with it. The rest can be handled in software. By comparison, an opto-coupler is 'one-way' only (typically an output).
There are 'reasonable' solutions to think of, but then the converter-board would contain a lot of components and jumper-pins. But yes, that would probably work
An opto-coupler can't switch fast enough to do serial communication over it though, and the UART3 needs voltage-level-shifting to 5V (or 3.3V) anyway, to be able to talk to a microcontroller or (non-SMD) MAX232 chip to convert it further up and down to +/- 12V (or +/-20V, what is it?).
I'm also eager to try bit-banging IC's from the Pandora in software. Shift-registers for example, are pretty neat to play with (serial in -> parallel out or parallel in -> serial out). This would be more educational than functional (or useful) though... It's all about fun and learning, as far as I'm concerned...
I didn't have an real play with electronic about 20 25 - 30 years (yeah NAND and NOR logic was everything we was have in those days, even LEDs just starts and was amazingly expensive )... So I place my idea more as a sketch than real design. If this TXB0106 makes all work for as, it will be fine.
I think that UART3 could be keep separated and only level shifted. AFAIK - RS232 is +/- 12 V, but it could be fine if 3.3 V and 5 V will be possible just by jumpers. I mean - if somebody like attach some MCU (AVR, PIC,...) it could comunicate on TTL or CMOS levels and not need double shift (to 12 V and from 12 V). But possibility of standard DB9 connector will be cute
If possible to design board in such way that it could carry 4 buttons together with 4 LEDs which works only from Pandora's power source (we could borrow some from USB port at worst - dirty trick but up to 0.5 A / 5 V) and as option could carry clamps for strong external power and 4 outputs for stepper motors it will be neat.
----
I don't know You skill but if You need help I can contact some HW hackers that I'm in touch with. I am out of play due to out of spare time.
I think that UART3 could be keep separated and only level shifted. AFAIK - RS232 is +/- 12 V, but it could be fine if 3.3 V and 5 V will be possible just by jumpers. I mean - if somebody like attach some MCU (AVR, PIC,...) it could comunicate on TTL or CMOS levels and not need double shift (to 12 V and from 12 V). But possibility of standard DB9 connector will be cute
On the "official" breakoutboard, it's a MAX3381E that handles the level shifting on the UARTs. Some of it bypasses the TXB0104 on the board. The MAX3381E is an SMD-part that can handle lower voltages (according to the datasheet from +2.35V to 5.5V, my guess is it uses 2.8V). But I don't *fully* understand the schematics. There are a lot of jumpers that complicate things, and I'm easily distracted.
I'm mostly after communicating with a microcontroller over UART and having the ability to use them as a 'normal' GPIO for direct access. If we want to use any standard DIP-package RS232 chip to translate it from 5V to compatible levels for a DB9 connector it would need shifting again, yes. I don't know how bad this is. But bypassing it completely seems like a loss too great to me. It could be jumpered, as you say. Interesting...
I stumble as I go along. Learning from failures made by wrong assumptions and stupidity in general. I hope much smarter people than me will tell me when I'm wrong. This is, after all, the internet. Thanks for the offer, I know where to find you! I'm definitely going to need help, but don't know where yet.
Also, Exophase explained here how to get the built-in pull-up resistors working on the GPIO's. I wouldn't know where to start.
And in other (awesome) news: WizardStan's ext-connectors arrived! Yay!
"Mr. Negative Blinky" (UART2_CTS/GPIO_144/PWM9) is really acting up. Whenever I run the blinky-script on GPIO 144, it blinks from -1.8V to 0V. But the power-pin ALSO "blinks" from 0 to 2.8V. When I stop the script, there's 1.0V on the power-pin, until I reboot. Then it's back to normal (2.8V). I'm staying away from it for now, but something seems really wrong. I'd appreciate it if someone can confirm this behavior of GPIO 144.
This might have been what was making the 1.8V regulator act up, while I was trying to power it from the pandora. That would be the good news. Needs double-checking though.
I've drawn up a pinout of the TinyBoB's, as seen from the top, when plugged into a Pandora. More of a note to myself: It's the same pin-out as the IDC-pins, seen from the top. Board horizontal, pins on the right.
Disclaimer: Always assume that what you read on the internet is WRONG.
EDIT: Guess what? It IS wrong! See peca's post below. I better hide it.
Code:
| |
| Pandora |
+---------------------------------------------------+
| EXT |
++-|||||||-++
LINE OUT R |o o| LINE OUT L
UART2_RX / 147 | o o | 144 / UART2_CTS
UART2_RTS / 145 |o o| 166 / UART3_TX
UART2_TX / 146 | o o | 165 / UART3_RX
LINE IN L |o o| LINE IN R
+2.8V | o o | GND
TV OUT 2 (C) |o___|^|___o| TV OUT 1 (Y)
TinyBoB
I think you're right peca, about wanting the option of bypassing the TXB0106 for the UART(s). Having a better look at the data-sheet of the MAX3381 on the official breakout board, it takes voltages from +1.65 to +5.5V. I better try to get that one working first, by communicating with it at 1.8V. Things are probably also easier to debug that way. We could also use something like an FTDI, and plug in a USB-cable, in stead of a DB9 connector.
Is there a way to "trigger" kernel messages that are being sent to ttyS0? Then I would at least know for sure the feedback loop is working. I may have seen gibberish a couple of times, I can't replicate it.
| |
| Pandora |
+---------------------------------------------------+
| EXT |
++-|||||||-++
LINE OUT R |o o| LINE OUT L
UART2_RX / 147 | o o | 144 / UART2_CTS
UART2_RTS / 145 |o o| 166 / UART3_TX
UART2_TX / 146 | o o | 165 / UART3_RX
LINE IN L |o o| LINE IN R
+2.8V | o o | GND
TV OUT 2 (C) |o___|^|___o| TV OUT 1 (Y)
TinyBoB
It is WRONG - or my cables work by miracle because I'm using different pinout...
EDIT: ...as seen from the top, when plugged into a Pandora:
Code:
| |
| Pandora |
+---------------------------------------------------+
| EXT |
++-|||||||-++
LINE OUT R |o o| TV OUT 1 (Y)
UART2_RX / 147 | o o | GND
UART2_RTS / 145 |o o| LINE IN R
UART2_TX / 146 | o o | 165 / UART3_RX
LINE IN L |o o| 166 / UART3_TX
+2.8V | o o | 144 / UART2_CTS
TV OUT 2 (C) |o___|^|___o| LINE OUT L
TinyBoB
You swap order on right side. This should explain why You have such issue with GPIO 144
Err... You mean that we have an USB port ([mini/micro]B socket) attached to EXT port and it could be connected to any USB host and provide serial communication (with serial/USB conversion out of the box)?
It is WRONG - or my cables work by miracle because I'm using different pinout...
EDIT: ...as seen from the top, when plugged into a Pandora:
Code:
| |
| Pandora |
+---------------------------------------------------+
| EXT |
++-|||||||-++
LINE OUT R |o o| TV OUT 1 (Y)
UART2_RX / 147 | o o | GND
UART2_RTS / 145 |o o| LINE IN R
UART2_TX / 146 | o o | 165 / UART3_RX
LINE IN L |o o| 166 / UART3_TX
+2.8V | o o | 144 / UART2_CTS
TV OUT 2 (C) |o___|^|___o| LINE OUT L
TinyBoB
You swap order on right side. This should explain why You have such issue with GPIO 144
Err... You mean that we have an USB port ([mini/micro]B socket) attached to EXT port and it could be connected to any USB host and provide serial communication (with serial/USB conversion out of the box)?
Err... You mean that we have an USB port ([mini/micro]B socket) attached to EXT port and it could be connected to any USB host and provide serial communication (with serial/USB conversion out of the box)?
So, it will be good for Pandora - PC communication. Heh it could be useful for emulating serial device which I don't have but need debug client SW on PC But for communication with other serial device (ie Arduino) it be better to have only level shifting, isn't it?
My laptop also doesn't have a serial port (PC does). Then the only option is USB.
And for Arduino we need the 1.8V <-> 5.0V conversion, yes. Other microcontrollers might run on anything from 1.8V to 5.5V usually. It would be possible to run a microcontroller on 1.8V and not need any conversion. That's another reason to want the ability to bypass the TXB0106.
I'm able to remotely login on my Pandora using a MAX232N (on 5.0V) and a DB9 connector in the serial port on my PC. There's still some 'gibberish' characters, so it's obviously not 100%. This could be the 'double-shifting' (1.8V to 5V to +/- 12V). Either that, or wrong/missing capacitors. The 1.8V regulator has the 1uF caps now.
I'll try to get the MAX3381 going, bypassing the TXB0106. See if that works better. Hopefully some more SSOP-DIP converter boards are coming early next week.
However, every now and then, some gibberish appears. Could these be kernel messages that are being sent to /dev/ttyS0 perhaps? If so, is there a way to turn that off?
This documentation seems to do the job. I can happily enable and disable the kernel messages (autoboot.txt), as well as the 'attached terminal' (/etc/inittab). Both at the same time, or individualy. It just works as expected. Rebooting inbetween of course.
However, my Pandora doesn't boot up (from cold start) when both the kernel messages are disabled AND the terminal is detached. When I turn the Pandora on, I have to remove the SD-card to disable autoboot.txt and reset the Pandora. Once it's booted, rebooting is not a problem. I waited 5 minutes staring at a Pandora-logo on a black screen, then gave up. I triple-checked.
With everything disabled, I can talk to my PC in minicom from the pandora in minicom. This works really well. No gibberish. "Hellollo PC". "Oh, hellollo pandora!".
With the terminal attached, I can also login from the PC. There's gibberish inbetween though. See below.
From minicom on my PC during boot-up of Pandora (terminal detached, kernel messages enabled (iirc)):
Code:
Welcome to minicom 2.4
OPTIONS: I18n
Compiled on Jan 25 2010, 06:49:09.
Port /dev/ttyS0
Press CTRL-A Z for help on special keys
Texas0Ins|rumentsLoading u-Starting St
U-ready
NAND: 512 *** Warning -5In: Die ID #281Hit anymmc1 is reading
** UnaLoadingFailed to mount ext2ѕ5Creating UBI: UBI: attacUBIF e
## Boot͕OK
Loading KernelVOK
OK 1
[21039.K[2[2103
INIT:version 2 ]
Starting kernelUncompress....................................................
[21040.2[21040.2[21 p1
Loading /eStarting udev
[21047.[21+Սy5[21051.783325]5[210[21051.848114] F s
ձ
[21054.[21054.665130] UѕALSA: RStarting OpenPcat: /etc/usage: [2105 .
Configuringdone.
net.ipv4.conf.de
INIT: EnteringٕStartingdbus.
StartingConfigurin pan pandor pandora:>ke pandora::power:[ pandor.
Starting\nOP_STAStartingStarting Starting PVR
[21071.7
Edit: while waiting on a non-booting Pandora, the word 'Syntax' is the last word I see.
It is reasonable. Some "standard" Pandora's keys are just GPIOs (shoulder buttons, D-Pad, ABXY, Select, Start and Pandora key at least). So - it is reasonable that other GPIOs could be recognized as other keys... It is just my guessing - Notaz, MWeston, EvilDragon or some other Pandora developer could confirm this.
It is reasonable. Some "standard" Pandora's keys are just GPIOs (shoulder buttons, D-Pad, ABXY, Select, Start and Pandora key at least). So - it is reasonable that other GPIOs could be recognized as other keys... It is just my guessing - Notaz, MWeston, EvilDragon or some other Pandora developer could confirm this.
The TXB0106 needed two 0.1uF decoupling capacitors. It couldn't handle the noise. It's perfect now:
Code:
Welcome to minicom 2.4
OPTIONS: I18n
Compiled on Jan 25 2010, 06:49:09.
Port /dev/ttyS0
Press CTRL-A Z for help on special keys
Texas Instruments X-Loader 1.4.2 (Dec 13 2009 - 16:05:26)
OpenPandora System
Loading u-boot.bin from NAND
Starting Stage 2 Bootloader...
U-Boot 2010.03-dirty (Jan 17 2011 - 15:11:42)
OMAP3530-GP ES2.1, CPU-OPP2 L3-165MHz
OMAP3 Pandora + LPDDR/NAND
I2C: ready
DRAM: 256 MB
NAND: 512 MiB
*** Warning - bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
Die ID #281a00020000000004031anonymous
Hit any key to stop autoboot: 0
mmc1 is available
reading autoboot.txt
93 bytes read
## Executing plain script at 82000000
Creating 1 MTD partitions on "nand0":
0x000000280000-0x000000c80000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=3"
UBI: MTD device size: 10 MiB
UBI: number of good PEBs: 80
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 80
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 89/52
UBIFS: mounted UBI device 0, volume 0, name "boot"
UBIFS: mounted read-only
UBIFS: file system size: 8386560 bytes (8190 KiB, 7 MiB, 65 LEBs)
UBIFS: journal size: 1032193 bytes (1008 KiB, 0 MiB, 6 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root: 414470 bytes (404 KiB)
Loading file 'uImage' to addr 0x82000000 with size 2329224 (0x00238a88)...
Done
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Angstrom/2.6.27-pandora+r24+git4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2329160 Bytes = 2.2 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................
.-------.
| | .-.
| | |-----.-----.-----.| | .----..-----.-----.
| | | __ | ---'| '--.| .-'| | |
| | | | | |--- || --'| | | ' | | | |
'---'---'--'--'--. |-----''----''--' '-----'-'-'-'
-' |
'---'
The Angstrom Distribution pandora ttyS0
Angstrom 2010.4-test-20100627 pandora ttyS0
pandora login: panik
Password:
pandora:~$ cd /
pandora:/$ ls -la
total 0
drwxr-xr-x 16 root root 1184 Apr 23 20:30 .
drwxr-xr-x 16 root root 1184 Apr 23 20:30 ..
drwxr-xr-x 2 root root 9104 Apr 23 02:28 bin
drwxr-xr-x 2 root root 304 Mar 4 14:46 boot
drwxr-xr-x 11 root root 3300 Jul 25 23:01 dev
drwxr-xr-x 55 root root 8592 Jul 24 14:42 etc
drwxr-xr-x 4 root root 288 Apr 24 23:22 home
drwxr-xr-x 5 root root 3768 Mar 25 2010 lib
lrwxrwxrwx 1 root root 12 Mar 4 11:37 linuxrc -> /bin/busybox
drwxr-xr-x 12 root root 896 Jul 25 23:01 media
drwxr-xr-x 5 root root 608 Apr 23 01:37 mnt
drwxr-xr-x 3 root root 224 Apr 23 20:30 pandora
dr-xr-xr-x 71 root root 0 Jan 1 1970 proc
drwxr-xr-x 2 root root 11576 May 13 01:52 sbin
drwxr-xr-x 11 root root 0 Jan 1 1970 sys
lrwxrwxrwx 1 root root 8 Apr 23 03:27 tmp -> /var/tmp
drwxr-xr-x 14 root root 952 Apr 23 2009 usr
drwxr-xr-x 8 root root 952 May 13 01:50 var
pandora:/$
Having the option of bypassing the TXB0106 is still a good idea and I will definitely do that, but I'm happy as it is with a MAX232N (DIP-package) board and the 'double-shifting' to talk to the PC. I'll try the FTDI/USB route in a while, bypassing the TXB0106.
I've been reading some analog data from an AVR (@5.0V) as well. Neat!
I'm sorry. Triple-checking isn't enough when I do it. After quadruple-checking, I think the problem is only in the autoboot.txt while cold-booting. It doesn't matter if the terminal is attached or not. Rebooting is never a problem. Also easily worked around:
- remove SD card
- turn on Pandora
- wait for Pandora-logo to disappear
- plug in SD card
- reboot (edit: added for clarity)
The last part of the sequence in minicom when it's not booting:
Code:
Hit any key to stop autoboot: 0
mmc1 is available
reading autoboot.txt
93 bytes read
## Executing plain script at 82000000
syntax error
In case anyone's interested, here's what happens when you hold the right shoulderbutton and choose the bootoption 'Serial prompt'. I typed 3 commands: 'help', 'printenv' and 'reset'. You can find more on this by reading Beagleboard related material.
Code:
Texas Instruments X-Loader 1.4.2 (Dec 13 2009 - 16:05:26)
OpenPandora System
Loading u-boot.bin from NAND
Starting Stage 2 Bootloader...
U-Boot 2010.03-dirty (Jan 17 2011 - 15:11:42)
OMAP3530-GP ES2.1, CPU-OPP2 L3-165MHz
OMAP3 Pandora + LPDDR/NAND
I2C: ready
DRAM: 256 MB
NAND: 512 MiB
*** Warning - bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
Die ID #281a00020000000004031anonymous
No MMC card found
Pandora # help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
chpart - change active partition
cls - clear screen
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
editenv - edit environment variable
exit - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
false - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
go - start application at address 'addr'
help - print command description/usage
i2c - I2C sub-system
imxtract- extract a part of a multi-image
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mmc - MMC sub-system
mtdparts- define flash/nand partitions
mtest - simple RAM read/write test
mw - memory write (fill)
nand - NAND sub-system
nandecc - switch OMAP3 NAND ECC calculation algorithm
nboot - boot from NAND device
nm - memory modify (constant address)
pmenu - show pandora's boot menu
printenv- print environment variables
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
showvar - print local hushshell variables
sleep - delay execution for some time
source - run script from memory
ssource - run script from memory (no header)
test - minimal test like /bin/sh
true - do nothing, successfully
ubi - ubi commands
ubifsload- load file from an UBIFS filesystem
ubifsls - list files in a directory
ubifsmount- mount UBIFS volume
usbinit - initialize USB
version - print monitor version
Pandora # printenv
bootdelay=0
baudrate=115200
usbtty=cdc_acm
loadaddr=0x82000000
bootargs=ubi.mtd=4 ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw rootflags=bulK
mtdparts=mtdparts=nand:512k(xloader),1920k(uboot),128k(uboot-env),10m(boot),-(r)
dieid#=281a00020000000004031anonymous
preboot=pmenu
stdout=serial
Environment size: 357/131068 bytes
Pandora # reset
resetting ...
Make sure you backup anything important that's in your home directory on the NAND before you mess things up here. If you're an idiot (like me) it's easy to reflash, but... well, you know. I *did* have that back-up though. I may be an idiot, I'm not stupid. That's what I'm telling myself anyway...
But that's enough about that UART3 for now. More testing needs to be done of the TXB0106 itself in a stand-alone environment. I'd rather damage a couple of $3,- ATmega's than my ext-port (Run it on 1.8V and pretend it's a Pandora).
I came across this topic on AVR-freaks, where user monkeytech links to this article, which seems above my level of understanding. I better start soldering and see it with my own eyes.
It might affect what we want going on in between the ext-connector and the TXB0106. Do we want the option of plugging in external pullup/pulldown resistors there?
If this gets too complicated (with a lot of jumpers that nobody understands/remembers), it might be easier to have the boards made that MWeston posted somewhere. I can't seem to find the post back, but here's a screenshot. I'm not sure if I am in the position to redistribute the files. It is the ultimate in flexibility though.
I much prefer this pinout to the ones on the TinyBoB's (as much as I love them). I *really* wanted the pinout to be more like the ext-connector itself. That's probably why I messed up so bad, I only looked at the ext-connector (OK, that was stupid).
This topic is also a must-read, with comments from the man himself.
Some other questions:
It's probably beyond my level of expertise to set up the GPIO's as interrupts, but it would be nice to know if that is even possible. Is it? The reference manual (warning: 26MB) is going over my head. I can barely understand the Atmel-series of datasheets. Microcontrollers are a lot easier to handle when there's not an OS that "gets in the way".
Also, from the Hacker's Manual:
- UART3 can also be configured for IrDA (Infrared Data Association) or CIR (Consumer Infrared Modes)
It's probably beyond my level of expertise to set up the GPIO's as interrupts, but it would be nice to know if that is even possible. Is it? The reference manual (warning: 26MB) is going over my head. I can barely understand the Atmel-series of datasheets. Microcontrollers are a lot easier to handle when there's not an OS that "gets in the way".
Yeah it's possible, and instead of fighting the OS you could write a kernel module to handle those interrupts (some C skills required). Otherwise you'd need to patch the bootloader or write your own OS..
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.