I've been banging my head over getting my little circuit to
work with a RioCar while in the car. My uC is set to talk
at 4800 baud. After finally hooking up a laptop to my Rio
(2.0b7 developer image) I've discovered that even in car,
the serial port is still running at 115,200 baud not 4800 and
[serial]
car_rate=4800
won't push it back down.

Is the default now 115200 all around? And who ever changed it
to 4800, the kernel (at seeing in-car power) or the player (looking
at power and config.ini)?

I was considering changing the kernel (since I've already made some
other changes) to hard code the rate I want but I don't want to be
fighting with some other code to set the rate.

Brett

Are you sure that your empeg thinks it's in the car? The rate should not have been changed.

Check for the presence of a "Dimmer" under "Settings". If it's not there, then your empeg thinks it's at home. Contact [email protected]

Oops, forgot to mention that.

Yes, it thinks its in the car.
/proc/empeg_power shows "1" for "Battery Power"
and my EQ had all the settings I use in the car
(the home settings are all flat right now)

Brett

Actually, when "in-car" the serial port starts out at 115200, and then switches to 4800 when the player application starts up, after kernel initialization completes.

That's probably the source of confusion here.

Cheers

Actually, it stays at 115200. i.e. My daemon and the player
start and its still 115200. I quit the player and fall out to shell
and its still 115200. That's my difficulty.

Exactly where is it _supposed_ to switch to 4800?

Brett

And what "daemon" would that be?

Perhaps you have added software (the daemon) that uses the serial port? And perhaps this daemon is starting up before the player switches the baud rate, and since the daemon is using the port then the player is unable to switch the baud rate to 4800..

The player switches the baud rate on startup of the player application, after it reads config.ini. On my machines, the last message I see on the serial port (at 115200) is something link "switching to .." and it gets cut off as the rate changes.

-ml

Aie.

That's the info I was looking for: it's the player that switches baud rate.

Yes, I fake out the player to take over the serial port, communicating
with the player via a pseudo-tty (my website will be updated later
with more up to date info).

Can I use setserial to change the baud rate of a StrongARM serial
port? Or is there a different method?

Brett

If you just need a way to inject player commands into the serial input stream, then that capability will be in Hijack soon. Right now, you can read player status from /proc/empeg_notify, and write "button" commands back to the same place to control the player, without mucking about on the serial link.

Cheers

From looking at the serial driver, I would guess that "setserial" ought to function on it. Try it and see..

Actually, my program wants to both send control information AND watch
player serial port output as well as push the player off the serial port to
reserve it for communicating with my own hardware.

As for setserial, I've already tried it last night (the Debian ARM version)
but "setserial -g" reports an 8520 UART with a speed of 230400 and
trying to set it to anything else doesn't seem to change much except
a multiple character bug seems to show up. Maybe I'll do it the direct
ioctl way and just see what I can figure out, at least I have the source
code to look at .

Brett

Okay.

The info in /proc/empeg_notify is the player status that is captured from monitoring the serial port output.. like pause/play status, current FID, current playlist, current track position, artist, album, etc..

If that's not what you need, then fine.

Cheers

I agree having the /proc/empeg_status is a very useful thing but for my
case I wanted to minimize CPU time polling but have a fast response to
changes in the Environment (like song changes) and while watchining
the serial output I get the song change as soon as it happens (generally).

I also wanted complete control of the external serial port data stream
as I will also be sending commands eventually to my uC via the sport
in addition to getting input from it (which the player liked to steal ).

I have found what I'm looking for though. Setserial doesn't work properly
(incidently PORT_SA1100_UART == PORT_8250 == 1 hence the report
of an 8250) but then I realised that this is also a console on a serial port
making things a little different in which case, stty does work properly and
its programming counterparts tcgetattr/tcsetattr. My daemon can now
do the baud rate change as it sees fit based on power info from empeg_power.

Thanks for your help though.

On to the next thing...

Brett