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)

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

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?

Quote:

Can I use the tuner serial port to receive seeburg commands?

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

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

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.

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.

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.

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?

Quote:
I'm trying to interface a seeburg walllbox http://tomszone.com/3W1.html into an empeg.

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?

Quote:
recieves the button press "G3". the app looks up the 73rd FID entry in the playlist.

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.

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)

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).

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

Quote:

Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?

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 $@

Quote:

I generally just do: arm-empeg-linux-gcc -static file.c

Cheers

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?

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;
}

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?

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 */
   ...

Quote:
There are other ways, but one of the simplest is to use a semaphore:

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+

Quote:
Yes, this is a great project! I want to see a video of this in action!

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+
 

Quote:
As requested, here's a link to the demo of my seeburg wallbox interface.

Quote:
demo of my seeburg wallbox interface.

Quote:
Absolutely fucking brilliant.

Awesome.

Quote:

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?

Quote:

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.

Quote:

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.

Quote:

4. What's the best licence to release under (e.g. BSD)?

Quote:

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?

Quote:

6. How do I pick a "real" device MAJOR number?

Quote:

... DTR seems to have no non-standard (RS232) use.

Quote:

The implementation of "SERIAL=" itself calls hijack_serial_rx_insert(the_string, strlen(the_string, 1))

Quote:

That's weird. down_interruptible() is a kernel inline function, so it doesn't really exist at run/link time.

Quote:

Just release it, and anyone who cares will eventually have a peek at it.

Quote:

Quote:

6. How do I pick a "real" device MAJOR number?

For the empeg kernel, the simplest is to just re-use an existing one that never had meaning on an empeg. [See] Documentation/devices.txt file from the kernel source tree.

Quote:
I noticed that when I write to empeg_notify, I need to send "+" as "%2B". When I call rx_insert directly, Can I send "#FID+\n" or do I still need to send "#FID%2B\n"?

Quote:

How exactly do I release the kernel part?

Quote:
tfabris, you are fined one credit for a violation of the verbal morality statute.

Quote:

Quote:

How exactly do I release the kernel part?

You could start by posting it here as an attachment. Then I can have a look-see and decide how best to incorporate it into Hijack (based mostly on code size, compatbility, etc..).

file:drivers/char/serial_sa1100.c line 2342
.
#ifdef SERIAL_DEBUG_OPEN
        printk("rs_open %s%d, count = %d\n", tty->driver.name, info->line,
               info->state->count);
#endif
+        //hack -- force on DTR because driver doesn't
+        if(line==1)
+           GPDR &= ~EMPEG_SERIALDTR;
+        //hack-end
.
.
.
file /drivers/char/mem.c line 699
.
	extern void empeg_cs4231_init(void);
	extern int empeg_power_init(void);
+	extern int seeburg_init(void);
+	seeburg_init();
#ifdef CONFIG_EMPEG_RAMTEST
.
.
.
file: arch/arm/special/notify.c line 40
.
#define NOTIFY_FIDLINE           2               // index of 'F' in notify_chars[]
+#define NOTIFY_SOUNDLINE        6               // index of 'S' in notify_chars[]
#define NOTIFY_MAX_LENGTH       64
static char notify_data[NOTIFY_MAX_LINES][NOTIFY_MAX_LENGTH] = {{0,},};
.
+const char *notify_sound (void)
+{
+        return &notify_data[NOTIFY_SOUNDLINE][0];
+}

Quote:
Seeburg.c driver attached

Quote:

Could you perhaps just create a proper unified patch instead,
by running this command (below) to differentiate between an original
Hijack kernel tree and your modified kernel treee?

diff -u --recursive --new-file hijack-v477/ seeburg/

Quote:

Do I need to patch to the current v477 or can I do the diff -u on my unmodified v461 tree?

Quote:

A diff against v461 should be new enough for this purpose, so just diff what you've got.

Quote:

A diff against v461 should be new enough for this purpose, so just diff what you've got.

Quote:

As requested... Two of two attachments. This patch is for time.h only. It looks like I ran "indent" on the time.h file after I added my code.

Quote:

Could ya maybe do it again with the -b flag then ?

Quote:
Just re-read my post, I think what I am really asking is can you post a copy of the patched kernel and info on how the whole project can together.

I am sure there are few people here who would love to give something similar a try

Quote:
I'm on my way back from vacation, but I'll try to get something out late next week.

Brilliant!

There is no rush of course, my unit is in safe hands in the States until I can figure a cost effective way of shipping it across the pond

Again, cool project

Cheers

Cris.

Quote:
...why don't you try and use a microcontroller like a Picaxe to fit between your box and your empeg, I bet you'd find it much easier.

Quote:
Cris, seeing as hacking kernels isn't your thing, why don't you try and use a microcontroller like a Picaxe to fit between your box and your empeg, I bet you'd find it much easier. The Picaxe is a piece of piss to program.

I like the idea. And I think an ultimate goal may be this solution. I had been looking around at other solutions but hadn't seen this product before.

I'd like to develop something that would interface with my slimserver network in the house, say over WiFi. But for now using the empeg seems like a really good idea, it gets used once every 2 weeks or so at the moment and this will put it back into regular usage.

I guess I will have to wait for my unit to turn up and see if it works first

I am still unsure how you build the seeburg driver into Hijack, is it possible to post a patched version here that I could upload just like anyother hijack update?

Cheers

Cris.

Quote:
I'd like to develop something that would interface with my slimserver network in the house, say over WiFi

Is the empeg capable of sending commands to the slimserver via TCP/IP?

This could be the solution I am looking for! That was I could just hook up to the empeg for local output, or configure it to control any one of the slimserver devices, that would be an awesome end goal, and possibly the cheapest as no extra hardware would be needed

Cheers

Cris.

Quote:
However, if you're going to end up using a slimserver, why don't you just build something that runs on the server instead?

Quote:

Quote:
However, if you're going to end up using a slimserver, why don't you just build something that runs on the server instead?

Maybe because (at least for me) the server is in the boiler room, and the Wallbox (and speakers) will be 2 floors and half a house away...

Wonder if the code cold be run on a Rio Receiver - hmm, wonder if it can do the serial I/O...

Quote:
The reason I mentioned it is because I know the layout of Cris' house. A rio reciever did cross my mind, I seem to remember reading somewhere that there is a serial port in there somewhere, and the built-in amp would probably come in very useful.

I think the best solution for my layout would be WiFi/wired TCP/IP control of a streaming device such as the Squeezebox. I say this because the system in my font room is hidden under the stairs, and a wireless platform would be perfect as I could place the wallbox where I like without worrying about getting the audio feed to the amp.

For the moment getting it to work with the empeg would be great

Cheers

Cris.

Quote:
So, to my question. I am still no closer to understanding where I need to start with the empeg side of things, the lead can be made up no probs, but the drivers is still a real puzzle to me, can someone lend a hand here and build up a kernel for me?

Quote:
Which serial port are you using Tom, the one on the back of the empeg itself or the sled?

Quote:

60Hz transformers are quite expensive I think, at least I haven't seen any readily available,

Quote:

...I'm going to try it at 50Hz 25v AC and see how I go on.

Starting bash.
empeg:/empeg/bin# rw
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
empeg:/empeg/bin# /empeg/bin/wallbox 83b0 &
[1] 103
empeg:/empeg/bin#
Seeburg Wallbox Application Version 1.0 by Scott Swazey
Read 200 items from playlist 83b0

player
Timezone: Atlantic/South_Georgia
Hijack: intercepting config.ini

  player.cpp        : 564:empeg-car 3.00-alpha7 2004/02/13.
Prolux 4 empeg car - 2.1490 Feb 13 2004
Vcb: 0x4070e000
bad state 778, button 0, letter 0, ticks 18
Logged 256 samples to /bad_state_778.bin

Quote:
Shouldn't it debounce?

Quote:
Yes, it does. But this not a debounce problem. The waveform is wrong.

Ah, *that* makes perfect sense. Carry on!

Quote:
Your current wallbox is clearly broken... Sorry

Quote:

Quote:
Your current wallbox is clearly broken... Sorry

Well I don't find that hard to believe, I will get some contact cleaner etc... and give it another go. That was for button A1.

Quote:

I have dropped the data into the Excel document and it looks much better, I am getting some strange results with the other selctions, but I think I have a few more adjustments to make.

Does this look more like it?

bad state 778, button 0, letter 0, ticks 16
Logged 256 samples to /bad_state_778.bin
bad state 778, button 0, letter 0, ticks 18
Logged 256 samples to /bad_state_778.bin

Quote:
I am finding that 2 lots of samples are being taken for J10 and K10

Any ideas what's going on? I was thinking that the sample period may not be long enough so it starts the process again.

Quote:
Can you measure the AC voltage at the imput terminals when the motor is running?

Quote:
or try a slighly higer voltage, say 28-30V

Ok this is interesting.

I timed the pulse arm at 25v to be just over 4 seconds, at 30v it's 5.4 seconds !!! Weird !!!

The light also look overly bright at 30v, so I don't think that it a very good idea. Worth a try though

Cheers

Cris.

Quote:
Not really sure what you are asking.

It's just a normal transformer, not in a case or anything, I am not sure what it is rated at but it seems to hold up just fine under the load of the seeburg.

Quote:

Ok this is interesting. I timed the pulse arm at 25v to be just over 4 seconds, at 30v it's 5.4 seconds !!! Weird !!!

Hmm, try 20V then... I'haven't timed my pulse arm, but I Timed it just now using my youtube video http://www.youtube.com/watch?v=f3Z31FvUHMo It's about 2 seconds from the time I press F10 to the "click" at the end of the selection. This is consistent with my earlier analysis that the 2.56sec should be more than enough to sample the pulses.

To extend the sample time I would need to rewrite the driver code to add an IOCTRL to expand the sample buffer. I never done IOCTL, but it should be possible. For 50Hz the wallbox app state machine will need to be completely rewritten.

It's probably easier for me to send you a $24 110V@60Hz inverter and a $20 radioshack transformer, assuming you''l cover the cost+shipping.

-Techtom

Quote:
It's probably easier for me to send you a $24 [Email]110V@60Hz[/Email] inverter and a $20 radioshack transformer, assuming you''l cover the cost+shipping.

Thanks for the offer

Before I take that option I will wait for my other box to turn up, or even try to get the other 3W1 I have here to power up. I also have a PC PlayBox 2 on it's way which is said to support 50Hz operation. I figured I could use it to figure out if it's my Seeburg that is faulty or the fact the arm is supposed to take that long on 50Hz.

For some reason I don't like the idea of the 230v AC 50Hz > 12 DC > 110v AC 60Hz > 25v AC 60Hz sequence. Too many boxes

Thanks for all your help with this, I know I am such a pain in the ass

Is anyone else giving this a try ?

Cheers

Cris.

Edit - Just noticed this transformer I have here has a 110v input! Cool!

Quote:
Is anyone else giving this a try ?

Quote:
Edit - Just noticed this transformer I have here has a 110v input! Cool!

What is not so cool is that the mains in my area seems to have gone up to 250v. This means the output of the transformer is not 27.5v and I think this explains the problems I am seeing. If the higher the input voltage the slower the arm, then I have found my Gremlin.

Funny, when I first tested this transformer all the voltages checked out ok, but now I am using it the input voltage has jumped a little. Bugger!

What sparked this retesting off is the fact that the PC Playbox2 doesn't work either! (even at 50Hz setting).

Anyone good as PSU design ?

Cheers

Cris.

Quote:

What is not so cool is that the mains in my area seems to have gone up to 250v.

Quote:

Quote:

What is not so cool is that the mains in my area seems to have gone up to 250v.

Mine has been up above 250v for most of this year, regularly triggering my UPS's trim feature. As of last week it now is down near 220v, regularly triggering my USP's boost feature. A series of big droops this week as well, enough to take the ADSL line down.

Quote:
Waiting for the hardware to arrive...

1. How do I detect that hijack has blanked the screen
2. If the screen is blanked, how do I wake up the display?
3. curently, I send '#'<FID><newline><space><newline> e.i. "#fid\n \n" to the hijack serial insert routine. Should I break this up into two calls to serial_insert? The second call would just be <space><newline>.