Gp2X Serial Issues - Hardware (Gp2X-Arduino)


cagell

Still Fresh
Joined
Dec 13, 2010
Messages
9
Hi All,

I am new to the GP2x world but have experience coding in C for linux and coding for Arduino.
I just got to program the GP2x and thought it would be great to interface it to an Arduino.

Hardwarewise I connected the Tx from the GP2x (Ext connector) to the Arduino Rx and both grounds together. I used a simple serial example to send serial commands to the Arduino. So far so good. I was able to see the serial commands from the GP2x on the arduino programming a particular message when a button was pressed.

Having only the one way comm (GP2x to Arduino)the whole thing works just fine, and all good. The problem comes when I connect the RX from the GP2X to the TX of the Arduino, then the communication that was working before (GP2X to Arduino) stops working.

I tried to troubleshoot what whas going on and I got two interesting results

a) I made a little program on the arduino sending always a character ('A') and the reciprocal on the GP2X (just reading). Funny enough it did work eventually, but not all the time. My guess is that I had a software error.

B) I tested shortcutting RX and TX on the GP2X and I got a weird error message (Over the serial wire!!!) saying that the remote device did not take the USB address on the network (I cannot copy the whole error because my serial reading software is kind of crappy and has limited buffer).

Based on that I think that there must be some kind of daemon or software artifact that throws an error when connecting the Rx signal. For some reason it thinks it is a USB device, but it is over the serial signal!!!

Again the program communicating GPX2 to arduino works just fine until I hook up the return channel. I thought it could be a hardware (voltage level) issue but really , shorting the TX and RX originated similar issues so, my bet is that it is more of a software issue.

I do not know what version of firmware I am using (again I am a newbie). It could be that I need to update the firmware. I tried googling arround for that but... no success, could anyone let me know what is the most reliable firmware I can get to the GP2X?

Does anybody have similar issues?

Any help will be much appreciated.
 
When you "shortcut" RX and TX on the GP2X, you read whatever is sent from the GP2X. It looks to me like there are log messages from the kernel sent to the serial terminal.
 
Yup, you'll be getting console messages on the serial line, for sure .. you'll need to turn this off somehow, I forget exactly how - its a standard linux question, though, so google is your friend here .. but it has been worked out for GP2X already, I remember running into this issue once before, years ago. I just can't remember the fix, I think echo something somewhere to /proc ..
 
Well the main thing that worries me is not about getting the log on the serial port (which is actually pretty nice) but the fact that when I connect the arduino's TX to the GP2X RX somehow I read the following on the serial port

hub.c: new USB device <NULL>-1, assigned address 14

usb.c: USB device not accepting new address=14 (error=-110)

hub.c: new USB device <NULL>-1, assigned address 15

usb.c: USB device not accepting new address=15 (error=-110)

I am not messing with the USB device but with the serial port.

Any hint??
 
Those messages are going to the serial console .. and these messages are normal, as far as I remember. The GP2X USB Host controller needs some sort of resistor (pull-up?) to function properly in Host mode - these messages are just a side-effect of that issue, which is as far as I know, normal for the GP2X. Its been a few years since I hacked on my GP2X system, for which I built a breakout box with working USB, and those messages went away.
 
torpor said:
Those messages are going to the serial console .. and these messages are normal, as far as I remember. The GP2X USB Host controller needs some sort of resistor (pull-up?) to function properly in Host mode - these messages are just a side-effect of that issue, which is as far as I know, normal for the GP2X. Its been a few years since I hacked on my GP2X system, for which I built a breakout box with working USB, and those messages went away.

The weirdest thing though is that I am not using the USB host at all... I am just using the serial.
So you are saying that if I correctly terminate the USB host my serial problems will go away?

Thanks for your help.
 
Last edited by a moderator:
You've got two problems here, try not to conflate them:

1. The Linux kernel is dumping its dmesg output to the serial port you want to use. You have to turn this off by passing a cmd line parameter to the kernel at boot-time telling it to use some other device instead, so that the serial port is only available to you. I *think* there is something in /proc you can use to turn this off while the system is running, but you have to do some research on this - I forget how I turned it off, way back when I was using the GP2X serial port for MIDI development.

2. The USB Host controller on the GP2X needs a pull-down/(or -up, again, I forget: check the wiki) resistor to put it in the correct 'mode' for use - until then, it will produce these messages on a fairly regular basis, again going to the serial port you want to use. If you want to reduce these messages, build a USB-Host adapter (check the wiki) and, if you have a USB-Serial adapter, use that instead.

Traditionally, the first serial port in a Linux system is used as the kernel boot-message (console) device. You have to either add another serial port for your needs (using USB-Serial and the appropriate circuitry), or disable kernel messages to /dev/ttyS0 with a kernel boot-up cmd-line option.
 
It also is worth pointing out that the quality of the serial output hardware of the GP2X breakout box is highly suspect. I can only get it to work right on certain computers, other computers hate it. Same is true of the GP2X's mini-USB connection, though that is not relevant here.

If you have one, you might consider trying a serial USB adapter and kill two birds with one stone. Question is: is there a driver for it in the older 2.4 kernel the GP2X uses? Probably a generic that'll work with at least some of the adapters out there.
 
torpor said:
The Linux kernel is dumping its dmesg output to the serial port you want to use. You have to turn this off by passing a cmd line parameter to the kernel at boot-time telling it to use some other device instead, so that the serial port is only available to you. I *think* there is something in /proc you can use to turn this off while the system is running, but you have to do some research on this - I forget how I turned it off, way back when I was using the GP2X serial port for MIDI development.

I did some research on how to prevent the system from sending commands over the ttyS0 but I was unable to find anything that worked.
I experimented a little bit more with my software and interestingly enough I can send stuff over the serial port with no problems but, as torpor said, there is some other process using the ttyS0. I say that because when I send stuff over to the ttyS0 I eventually get a response but not from my program but from some echo deal.

Please let me know if anyone was able to avoid this 'dmesg' over serial.

Thanks for your help
 
Last edited by a moderator:
Tried editing /etc/syslog.conf and turned off all the lines going to /dev/console? Maybe thats the trick ..

Edit, there's also /proc/sys/kernel/printk .. I think this should be "3 4 1 7" to turn off kernel messages, but you should dig deeper.
 
torpor said:
Tried editing /etc/syslog.conf and turned off all the lines going to /dev/console? Maybe thats the trick ..

Edit, there's also /proc/sys/kernel/printk .. I think this should be "3 4 1 7" to turn off kernel messages, but you should dig deeper.


I tried your alternatives but

a) I did not find /etc/syslog.conf on the GP2X
B) I tried editing printk but it said I cannot edit it. I created a copy and tried to substitute the original for the copy and I was not able.

Any other ideas?

Thanks in advance for your help
 
Last edited by a moderator:
torpor said:
Code:
$ echo "3 4 1 7" > /proc/sys/kernel/printk

Hey Torpor,

Thanks for your help. I tried your approach but it did not work/made no difference.
On the other hand I did some research and I commented a line on the /etc/inittab file so that now it is (pay attention to the bold section).

---------------------------------------------------

# /etc/inittab
#
# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>
#
# Note: BusyBox init doesn't support runlevels. The runlevels field is
# completely ignored by BusyBox init. If you want runlevels, use
# sysvinit.
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# id == tty to run on, or empty for /dev/console
# runlevels == ignored
# action == one of sysinit, respawn, askfirst, wait, and once
# process == program to run

# Startup the system
null::sysinit:/bin/mount -o remount,rw /dev/root /
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -a
null::sysinit:/bin/hostname -F /etc/hostname
null::sysinit:/sbin/ifconfig lo 127.0.0.1 up
null::sysinit:/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
# now run any rc scripts
::sysinit:/etc/init.d/rcS

# Put a getty on the serial port
#ttyS0::respawn:/bin/sh <---- I commented this line

# Stuff to do for the 3-finger salute
::ctrlaltdel:/sbin/reboot


----------------------------------------

So that partially solved the issue

On the plus side
- I am able to read and write the serial port (read it for the first time ever!!!)
- I just realized the gp2x code I wrote needs xon-xoff, but I guess I can work to avoid that.

On the minus side
- I still get messages on the serial port (outgoing) that look like this

------------------
hub.c: new USB device <NULL>-3, assigned address 6
usb.c: USB device not accepting new address=6 (error=-110)
-------------------

So the thing is that I get Kernel messages displayed on the output of the serial port. Now that printk deal should have worked but it did not. Any documentation on printk or other alternative?

I guess I can implement a workarround on that so that whatever reads the serial port (which I will also be programming) will filter based on characters or something. I would work but kind of ..... not elegant.

Any other suggestions are more than welcome, but I am pretty satisfied with that.


Thanks torpor for your help, let me know if you have any other thoughts about the remaining issues.
 
Last edited by a moderator:
Back
Top