#300599 - 15/07/2007 07:46
Interface Seeburg wall box to empeg
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
I'm trying to interface a seeburg walllbox http://tomszone.com/3W1.html into an empeg. I think I pretty much figured out the logic but I had a few questions: I plan on compling an arm app to run on the player. How do I add it to the start up script? (e.g. rcS) I plan on sending the hxxp://empeg/?NODATA&SERIAL=%23FID%2b command to quenue songs. Is there and easier way? I would prefer just to dump the command to a /proc file I can use empeg_notify to determine the state of the player. But is there and easier way to find out if the empeg has finished the playlist? Can I use the tuner serial port to receive seeburg commands? Ideally, It would be nice if I could insert my app as a shim between the serial port and the player app. ideas? Thanks, -Techtom
|
Top
|
|
|
|
#300600 - 15/07/2007 11:42
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote: I plan on compling an arm app to run on the player. How do I add it to the start up script? (e.g. rcS)
Add it to /empeg/var/config.ini as follows:
[hijack] ;@EXEC_ONCE some command of yours
Quote:
I plan on sending the <a href="hxxp://empeg/?NODATA&SERIAL=%23FID%2b" target="_blank">hxxp://empeg/?NODATA&SERIAL=%23FID%2b</a> command to quenue songs. Is there and easier way? I would prefer just to dump the command to a /proc file
I think the same thing is doable as follows, or something very close to this:
echo 'SERIAL=#FID+' >/proc/empeg_notify
Quote:
I can use empeg_notify to determine the state of the player. But is there and easier way to find out if the empeg has finished the playlist?
Define, programmatically, "finished the playlist". Note that the empeg merely pauses at the end of a playlist. Pressing "Play" starts it up again. You could screen scrape the "end of playlist" message, though.
Quote:
Can I use the tuner serial port to receive seeburg commands?
Possibly. But I think there's actually a *third* serial port on that connector(?) also. Use it instead.
Cheers
|
Top
|
|
|
|
#300601 - 15/07/2007 12:03
Re: Interface Seeburg wall box to empeg
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
Quote:
Can I use the tuner serial port to receive seeburg commands?
Possibly. But I think there's actually a *third* serial port on that connector(?) also. Use it instead
Mmmm... Pin-7 at the tuner connector is an (unused) I2S signal line. Which means it's a serial line of some kind. I dunno where it terminates on the mainboard, though.
Cheers
|
Top
|
|
|
|
#300602 - 15/07/2007 12:15
Re: Interface Seeburg wall box to empeg
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
Quote: I plan on sending the <a href="hxxp://empeg/?NODATA&SERIAL=%23FID%2b" target="_blank">hxxp://empeg/?NODATA&SERIAL=%23FID%2b</a> command to quenue songs. Is there and easier way? I would prefer just to dump the command to a /proc file
I think the same thing is doable as follows, or something very close to this:
echo 'SERIAL=#FID+' >/proc/empeg_notify
Yup, that works, as in:
echo 'SERIAL=#211+' >/proc/empeg_notify
|
Top
|
|
|
|
#300603 - 15/07/2007 17:24
Re: Interface Seeburg wall box to empeg
[Re: mlord]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Quote:
Quote:
I can use empeg_notify to determine the state of the player. But is there and easier way to find out if the empeg has finished the playlist?
Define, programmatically, "finished the playlist". Note that the empeg merely pauses at the end of a playlist. Pressing "Play" starts it up again. You could screen scrape the "end of playlist" message, though.
The problem is that if you send #FID+ to a player that is at the end of the playlist, it will not play. You'd need to send <space>. but then the player will replay the whole playlist with the added song at the end. For "jukebox" like opperation, you need to perform the following test:
read empeg_notify: if notify_FidTime = "0:00:00"; // empeg might be starting a new tune/playlist or paused wait 2 seconds and read empeg_notify again if notify_FidTime = "0:00:00"; // empeg is paused send #NewFID else (from first if) ;// empeg is playing send #NewFID+
The above logic should work fine, but It has to wait at least one second to see if the player is paused.
Thanks for your help,
-Techtom
|
Top
|
|
|
|
#300604 - 15/07/2007 17:29
Re: Interface Seeburg wall box to empeg
[Re: mlord]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Quote:
Mmmm... Pin-7 at the tuner connector is an (unused) I2S signal line. Which means it's a serial line of some kind. I dunno where it terminates on the mainboard, though.
I don't think I can use pin-7 because I2S is a serial audio bus format (the format CD players send to the D/A converter). It probably terminates in the DSP. Does your kernel support/initialize three uarts?
-Techtom
Edited by techtom (15/07/2007 17:37)
|
Top
|
|
|
|
#300605 - 15/07/2007 19:47
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
The problem is that if you send #FID+ to a player that is at the end of the playlist, it will not play. You'd need to send <space>. but then the player will replay the whole playlist with the added song at the end. For "jukebox" like opperation, you need to perform the following test:
read empeg_notify: if notify_FidTime = "0:00:00"; // empeg might be starting a new tune/playlist or paused wait 2 seconds and read empeg_notify again if notify_FidTime = "0:00:00"; // empeg is paused send #NewFID else (from first if) ;// empeg is playing send #NewFID+
The above logic should work fine, but It has to wait at least one second to see if the player is paused.
There is a field in /proc/empeg_notify that is a simple 0/1 value for paused/playing. I think it's called "sound" or something like that.
Cheers
|
Top
|
|
|
|
#300606 - 15/07/2007 19:49
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
Quote:
Mmmm... Pin-7 at the tuner connector is an (unused) I2S signal line. Which means it's a serial line of some kind. I dunno where it terminates on the mainboard, though.
I don't think I can use pin-7 because I2S is a serial audio bus format (the format CD players send to the D/A converter). It probably terminates in the DSP. Does your kernel support/initialize three uarts?
Yeah, it must go to the DSP then. The main SA1100 CPU has three serial ports configured: one for the back panel, one for the tuner, and another for the I/R transceiver (not the remote control, the *other* I/R that's unused).
To use the tuner serial port, some extra hackery will be needed inside the kernel to isolate your use of it from that of the player software and Hijack. Perfectly doable, and as you surmised it's likely the only solution that can be done without hardware hackery.
Cheers
|
Top
|
|
|
|
#300607 - 15/07/2007 22:02
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31600
Loc: Seattle, WA
|
Quote: I'm trying to interface a seeburg walllbox http://tomszone.com/3W1.html into an empeg.
Absolutely brilliant idea. Wow.
Since the keypad has letters A-F, you could even just do four-digit FIDs directly... was that your plan?
|
Top
|
|
|
|
#300608 - 16/07/2007 00:20
Re: Interface Seeburg wall box to empeg
[Re: tfabris]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Quote:
Absolutely brilliant idea. Wow. Since the keypad has letters A-F, you could even just do four-digit FIDs directly... was that your plan?
No. To keep it simple the Wallbox works as is. The wall box sends pulses to indicate the buttons pressed. They are always a letter number pair. I plan on using an off the shelf $99 pulse to rs232 converter from http://www.cdadapter.com/pcplay.htm I don't have it yet so I don't have all the interface details worked out.
The emplayer app is very simple. Start it with a playlist fid (e.g. Seeburg 0x1151). The app listens on the tuner rs-232 port and recieves the button press "G3". the app looks up the 73rd FID entry in the playlist. The app checks notify_Sound value, if zero send #FID else send #FID+
The FID entry in the play list can be a tune or another playlist. So the Seeburg can start either one from a single button press.
I figure i can keep it simple if I just use an rs232 interface...
However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)
-Techtom
Here's a ethernet version of the same thing... http://www.bengtson.org/seeburg/ He also has more details on the pulse interface
Edited by techtom (16/07/2007 00:43)
|
Top
|
|
|
|
#300609 - 16/07/2007 01:07
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31600
Loc: Seattle, WA
|
Quote: recieves the button press "G3". the app looks up the 73rd FID entry in the playlist.
Aha. That'd work, too, and wouldn't require updating some kind of second list on an intermediary device. All you'd need to do is make sure the playlist is ordered correctly. OK, I'm with ya.
Quote: However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)
I seem to recall that the PCA version of the tuner module deliberately included some general purpose I/O lines that you might be able to mess with. If you happened to have one of those. If not, then you're not really saving the 99.00 because then you'd have to buy a PCA tuner.
|
Top
|
|
|
|
#300610 - 16/07/2007 01:37
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)
There are several GPIO lines attached to the rear-panel DB-9 connector (serial port). The "headlight sense" line is a good candidate, as it is not normally used for anything when operating on AC power.
That's serial port pin-8 (CTS). Also possible, is the telephone mute input, on serial port pin-1 (CD).
Cheers
|
Top
|
|
|
|
#300611 - 16/07/2007 02:25
Re: Interface Seeburg wall box to empeg
[Re: mlord]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Quote:
Quote:
However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)
There are several GPIO lines attached to the rear-panel DB-9 connector (serial port). The "headlight sense" line is a good candidate, as it is not normally used for anything when operating on AC power.
That's serial port pin-8 (CTS).
Great! I assume that there is no memory manager on the empeg. So I should be able to read it from a Volatile char pointer right? What's the address & Bit #?
Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?
Thanks,
Techtom
|
Top
|
|
|
|
#300612 - 16/07/2007 09:31
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
Quote:
Quote:
However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)
There are several GPIO lines attached to the rear-panel DB-9 connector (serial port). The "headlight sense" line is a good candidate, as it is not normally used for anything when operating on AC power.
That's serial port pin-8 (CTS).
Great! I assume that there is no memory manager on the empeg. So I should be able to read it from a Volatile char pointer right? What's the address & Bit #?
Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?
The empeg uses Linux as the O/S, which is a protected memory operating system. So, yes, it has a memory manager.
Use the source.
Cheers
|
Top
|
|
|
|
#300613 - 16/07/2007 20:01
Re: Interface Seeburg wall box to empeg
[Re: techtom]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Quote:
Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?
arm-empeg-linux-gcc object1.o object2.o -Wl,-Bstatic $(STATIC_LIBS) -Wl,-Bdynamic $(DYNAMIC_LIBS) -o $@
|
Top
|
|
|
|
#300614 - 16/07/2007 20:29
Re: Interface Seeburg wall box to empeg
[Re: tonyc]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
Quote:
Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?
arm-empeg-linux-gcc object1.o object2.o -Wl,-Bstatic $(STATIC_LIBS) -Wl,-Bdynamic $(DYNAMIC_LIBS) -o $@
I generally just do: arm-empeg-linux-gcc -static file.c
Cheers
|
Top
|
|
|
|
#300615 - 19/07/2007 22:34
Next steps (was Re: Interface Seeburg wall box to empeg)
[Re: mlord]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Quote:
I generally just do: arm-empeg-linux-gcc -static file.c
Cheers
I've looked at the kernel and analyzed the seeburg pulse train. It looks like I can use the system timer to sample the CTS/headlight line and "read" the seeburg pulses.
I'll add a small/fast amount of code to the reset_timer (SA1100/time.h) routine. every tick I'll check to set if the seeburg line (CTS) has gone low. if it has, I'll have the code log the OSCR register and CTS bit for the next 250 ticks into a small buffer(250*4). Once 250 ticks have been collected, the buffer is flagged as ready and the code returns to waiting for the seeburg line to go low.
A simple charater driver will retrive the OSCR tick buffer and make it available in userspace. The userspace app will parse the time stamps, determine the button press, index the playlist and queue the FID.
w.r.t building the kernel, I noticed in menuconfig that loadable module support is not enabled. Does the Hijack kernel support loadable modules? Can I just turn it on and recomple the kernel? When I build a new kernel, can I boot it without burning it to flash? If I have to burn it to flash, what's the de-brick proceedure?
Thanks,
-Techtom
|
Top
|
|
|
|
#300616 - 20/07/2007 00:00
Re: Next steps (was Re: Interface Seeburg wall box to empeg)
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote:
w.r.t building the kernel, I noticed in menuconfig that loadable module support is not enabled. Does the Hijack kernel support loadable modules? Can I just turn it on and recomple the kernel? When I build a new kernel, can I boot it without burning it to flash? If I have to burn it to flash, what's the de-brick proceedure?
Loadable modules should work, but we don't have them enabled by default -- no need, and module support takes up precious memory (DRAM).
We don't have a proper software bootloader setup, so testing kernels currently requires burning them to flash. The de-brick procedure is simple: just burn another kernel over top of the failed one! Zero risk.
Cheers
|
Top
|
|
|
|
#300617 - 21/07/2007 01:11
Re: Next steps (was Re: Interface Seeburg wall box to empeg)
[Re: mlord]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Status: Installed tools, built kernel, flashed via ftp empeg +50 times, seeburg driver working, /dev/wallbox returns 256 samples. The driver seems to be working and I'm getting the timestamps. But I had a question about blocking reads in a device... What is the correct way to block (wait for input) in a device? The interrupt routine increments "samples_collected", but the driver needs to wait until 256 samples have been collected. Is there some sort of kernel mutex I set in the interrupt routine and wait on in the driver? Thanks, -Techtom here's the read part of the driver: Code:
ssize_t seeburg_read (struct file * filep, char *buff, size_t count, loff_t * offp) { /* function to copy kernel space buffer to user space */ if (samples_collected == MAX_SAMPLES && tick_tock==0) { if (copy_to_user (buff, pulse_samples, sizeof (pulse_samples)) != 0) { printk ("Kernel -> userspace copy failed!\n"); } printk ("samples collected %d\n", samples_collected); samples_collected == 0; tick_tock = 1; return sizeof (pulse_samples); } return 0; }
Edited by techtom (21/07/2007 01:18)
|
Top
|
|
|
|
#300618 - 21/07/2007 09:02
Re: Next steps (was Re: Interface Seeburg wall box to empeg)
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Quote: What is the correct way to block (wait for input) in a device?
The interrupt routine increments "samples_collected", but the driver needs to wait until 256 samples have been collected.
Is there some sort of kernel mutex I set in the interrupt routine and wait on in the driver?
There are other ways, but one of the simplest is to use a semaphore:
Code:
struct semaphore mysem = MUTEX_LOCKED;
...
// Interrupt handler:
if (++count == desired_number) up(&mysem); /* signal that data is available */
...
// mainline driver's read() or ioctl() routines: ... down(&mysem); /* wait for data */ ...
Note that these are "counting" semaphores, so you could even get clever with them if you want, but the simple form above will work.
Cheers
|
Top
|
|
|
|
#300619 - 22/07/2007 04:52
Re: Next steps (was Re: Interface Seeburg wall box to empeg)
[Re: mlord]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Quote: There are other ways, but one of the simplest is to use a semaphore:
Got it. thanks for the tip.
Next question. I was planning to use the DTR output as the pullup resistor +5V source. But it looks like it's deasserted (-5V). Most rs-232 DTEs assert DTR. I can turn it on in my driver, but is it used for something else?
Thanks,
-Techtom
Status: the driver and the ISR are returning good samples. So the kernel work is finished. I've parsed/plotted the samples collected on my empeg by the driver in excel (see attached). Now the hard part... need to write the user program to parse the samples and extract the button codes...
Attachments
301830-Wallboxdata.PNG (1342 downloads)
|
Top
|
|
|
|
#300620 - 24/07/2007 00:11
Re: Next steps (was Re: Interface Seeburg wall box to empeg)
[Re: techtom]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14495
Loc: Canada
|
Cool.
I'm on holiday (beaches) for the next couple of weeks.. offline and all of that.
Cheers!
|
Top
|
|
|
|
#300621 - 25/07/2007 06:51
It works!
[Re: techtom]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Thank's to Mark's help, I've succeeded, it works!!! The seeburg is connected to pin 8 (CTS) of the empeg serial port. A kernel driver (/dev/wallbox) and a user app (wallbox) convert the pulses to a fid in the "seeburg" playlist. The selected fid is added to the currently playing list. Here's a sample output from the serial port: Code:
empeg:/empeg/bin# /wallbox 1ad0 &
seeburg open: state 1 Read 100 items from playlist 1ad0 . empeg:/empeg/bin# player Timezone: PRC Hijack: intercepting config.ini player.cpp : 385:empeg-car 2.00-beta13 2002/07/24. Prolux 4 empeg car - 2.1434 Jul 24 2002 Vcb: 0x4086d000 . Selection E3 is fid 2a0 #2a0 . Selection H6 is fid 2b70 #2b70+ . Selection K6 is fid 690 #690+ . Selection J9 is fid 45a0 #45a0+
I need to clean up the code and I've got some questions that hopefully someone can answer in Mark's absence... 1. I was planning to use the DTR output as the pullup resistor +5V source. But it looks like it's deasserted (-5V). Most rs-232 DTEs assert DTR. I can turn it on in my driver, but is it used for something else? 2. I'm currenly using fprintf(empeg_notify_fp,"SERIAL=#fid\n") to queue the song. But I was thinking of using the "write" portion of my driver to "notify" the Hijack kernel directly. I've looked at notify.c, but I'm not sure which function to call. 3. I'm using down(&sem) but I'd like to use down_interrruptable. When I do, I get an unresolved external. I #include <asm-arm/semaphore.h> but it doesn't help. 4. What's the best licence to release under (e.g. BSD)? 5. I'd like to release the code, but I probably need some sort of "code review" for my kernel / driver changes. Can anyone help out? 6. How do I pick a "real" device MAJOR number? Thanks, -Techtom
|
Top
|
|
|
|
#300622 - 25/07/2007 15:30
Re: It works!
[Re: techtom]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
Just in case you weren't fully aware of the fact, this is exceptionally cool! Do we get a photo gallery somewhere about it?
I once had a coffee (but no cherry pie) at a diner in Philadelphia that still had an installation of those things. Though I think theirs was original, not Empeg-powered...
Peter
|
Top
|
|
|
|
#300623 - 25/07/2007 19:09
Re: It works!
[Re: peter]
|
addict
Registered: 02/08/2004
Posts: 434
Loc: Helsinki, Finland
|
Yes, this is a great project! Hell, I want to see a video of this in action!
|
Top
|
|
|
|
#300624 - 26/07/2007 04:16
Seeburg Wallbox -- Video Demo
[Re: petteri]
|
journeyman
Registered: 30/12/2002
Posts: 51
Loc: Southern California
|
Quote: Yes, this is a great project! I want to see a video of this in action!
As requested, here's a link to the demo of my seeburg wallbox interface.
http://www.youtube.com/v/f3Z31FvUHMo
Code:
This is a demonstration of a program I wrote to interface a Seebug 3W-100 wallbox to an empeg mp3 player. Below is the text that was on the computer screen. It shows the wallbox app startup and the button selections. . empeg:/empeg/bin# /wallbox & [1] 147 empeg:/empeg/bin# seeburg open: state 1 Read 100 items from playlist a7d0 . empeg:/empeg/bin# player Timezone: PRC Hijack: intercepting config.ini . player.cpp : 385:empeg-car 2.00-beta13 2002/07/24. Prolux 4 empeg car - 2.1434 Jul 24 2002 Vcb: 0x4086d000 . . samples collected 256 state is 4 empeg_sound is 0 . . Selection F10 is fid 31f0 #31f0 samples collected 256 state is 4 empeg_sound is 1 . . Selection C4 is fid 2a70 #2a70+
-Techtom
|
Top
|
|
|
|
#300625 - 26/07/2007 06:43
Re: Seeburg Wallbox -- Video Demo
[Re: techtom]
|
carpal tunnel
Registered: 18/01/2000
Posts: 5683
Loc: London, UK
|
Quote: As requested, here's a link to the demo of my seeburg wallbox interface.
Sweet.
_________________________
-- roger
|
Top
|
|
|
|
#300627 - 26/07/2007 13:27
Re: Seeburg Wallbox -- Video Demo
[Re: techtom]
|
addict
Registered: 11/01/2002
Posts: 612
Loc: Reading, UK
|
Fantastic!!!! It's going to look funny on the dash though Maybe in a pink cadillac?
_________________________
LittleBlueThing
Running twin 30's
|
Top
|
|
|
|
#300628 - 26/07/2007 16:23
Re: Seeburg Wallbox -- Video Demo
[Re: techtom]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31600
Loc: Seattle, WA
|
Absolutely fucking brilliant.
Awesome.
|
Top
|
|
|
|
|
|