#359040 - 25/06/2013 16:33
Re: Empeg player software, a new generation
[Re: jbrinkerhoff]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
Over thye next week I will try and write up what has been done to date and what options are available. At the moment the RPI will drive an O-LED display using a board from PCA and myself. It has an O-LED module, 4 buttons and consumer IR. With software on the RPI board the display can either act as a remote for an existing empeg player (via ethernet) or work as a stand alone player itself. I have parts for 10 display boards on order and will solder this lot together when it all arrives, I have 25 PCBs available. The front panel PIC microcontroller code is finised, all buttons and the IR works as it should. The display board has a pinout that matches the RPI : http://www.jonshouse.co.uk/rpi_displayboard_pinout.pngThe board uses SPI to drive the display. The button presses are sent to the Pi via serial, the serial from the RPI to the display is just used to toggle the front panel LED on/off :-) At the moment remote control of the existing empeg from the RPI display board is pretty simple, as it is from the larger LED units i've built. All these units with buttons can run Centro and/OR act as a remote display for an existing empeg. http://www.youtube.com/watch?v=zHSGtInrsDYUsing a RPI board + display board as a head unit for the existing empeg is pretty easy (but not documented yet, I will do that !). It would be possible to produce a shim board that goes between the RPI display board and existing empeg to duplicate the functionality of the front panel - it was not designed for this, but it would be possible. It would be better done as a new project though as board holes are not designed to lign up with the empeg metal work. The RPI disply board was designed to fit into a custom case PCA designed and laser cut from perspex, thanks Patrick - nice job :-) http://www.jonshouse.co.uk/centro/This page has some (not great) pictures. Words pictures and video to follow soon. The prototype has been running on my desk here for days, all seems stable (well as stable as anything using the Raspberry Pi ... ho hum). http://www.youtube.com/watch?v=a6VpvDC5Cs4&feature=youtu.beAssembled Raspberry Pi player. Cheers, Jon
Edited by jonshouse (25/06/2013 19:34)
|
Top
|
|
|
|
#359044 - 25/06/2013 23:49
Re: Empeg player software, a new generation
[Re: jonshouse]
|
member
Registered: 02/04/2002
Posts: 148
|
Assuming this means what I think it does, basically what we were postulating would be a great idea for a display extender for an existing empeg, has in fact already been done. Cool.
From the pics I see, the display board looks to be pretty thin, and roughly single-DIN sized. This would likely fit well where my clock currently is, which is where I would mount my empeg if I had the depth.
I assume that the raspi can be some reasonable distance from the board (10cm)? and the empeg itself can be Ethernet distance away, so that works (trunk mount).
Silly question, but can you show remote control of a standard (hijack'ed obviously) player? What does the boot sequence look like? What power dependencies are there (thinking "key on" in the car - does boot order matter? etc...)
What other specific hardware (ras pi, etc) is needed? I know, I know, you said you were writing it up... OK. Ill wait. Heck Im going on vacation for 2 weeks anyway. :-)
But please count me in line....
_________________________
Empeg Mk2a 60G
|
Top
|
|
|
|
#359047 - 26/06/2013 13:14
Re: Empeg player software, a new generation
[Re: jbrinkerhoff]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
I assume that the raspi can be some reasonable distance from the board (10cm)? and the empeg itself can be Ethernet distance away, so that works (trunk mount).
Yes, should work ok - its not screened cable so I would not push it with the length but 10cm is about the cable length I am using. It will suffer with a longer cable as the SPI data is running at about 30Mhz. Silly question, but can you show remote control of a standard (hijack'ed obviously) player? What does the boot sequence look like? What power dependencies are there (thinking "key on" in the car - does boot order matter? etc...) I had to find the original player hard disk and put it back in, but here you go :-) http://www.youtube.com/watch?v=JRC3K52T3N8&feature=youtu.beWhat does the boot sequence look like?
Empeg end looks unchanged, the RPI board end is very very boring - nothing happens until the process "display_on_oled" is started. The Pi is not aware of the SPI display at all, only the process I wrote is drving it. In theory it could be made a linux framebuffer device but I have no plans to do that. Not in the sligtest. You need to give the RPI and player a static IP address you also need to tell the RPI end the IP of the EMPEG unit, after that you can power on/off each end at will, order does not matter. A hub is not required, I have tested with a crossover ethernet cable and it seems to work fine. What other specific hardware (ras pi, etc) is needed? I know, I know, you said you were writing it up... OK. Ill wait. Heck Im going on vacation for 2 weeks anyway. :-) You need this lot : 1) Raspberry Pi (B) board (either revision, not included) 2) The O-LED display and button board (included in kit) 3) 12v to 5v Buck converter (included in kit) 4) Ribbon cable to connect Pi to display board (included in kit) 5) 4GB or bigger SD card for Pi board (not included) 6) Case (not decided yet !) 7) Cross over ethernet cable (not included) 8) Some software (not all released yet, but will be soon) :-) So far I have yet to test the Pi kit in a car. I will do this but I want to wait until I have put a few more units together before I start trying to blow one up ! I also need to make the IR proxy work with the original player. The decoded IR codes match so in theory this should be simple enough.... cant seem to make this work at the moment though. Writing 4 byte IR codes to /proc/empeg_ir is ignored by the original player ? Cheers, Jon
Edited by jonshouse (26/06/2013 14:02)
|
Top
|
|
|
|
#359048 - 26/06/2013 16:28
Re: Empeg player software, a new generation
[Re: jonshouse]
|
member
Registered: 02/04/2002
Posts: 148
|
Excellent. Thanks for the video - clearly it works exactly as you described. I can't wait to order one when you feel comfortable releasing it. Like I said, Im not rushing at all, since I'll be gone for 2 weeks, but I really do look forward to dusting off the old empeg and having it back in my car. Pretty sure my brother and cousin will eventually want to do so with theirs as well...
Thanks for allthe work!
JEff
_________________________
Empeg Mk2a 60G
|
Top
|
|
|
|
#359049 - 26/06/2013 21:08
Re: Empeg player software, a new generation
[Re: jonshouse]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I also need to make the IR proxy work with the original player. The decoded IR codes match so in theory this should be simple enough.... cant seem to make this work at the moment though. Writing 4 byte IR codes to /proc/empeg_ir is ignored by the original player ? I forget how that works, but Hijack has interfaces for "cooked" button press/release events. Eg. the weblite interface has a fully functional empeg remote control and front-panel, done with a bit of javascript in one's web browser. Something like this via http to Hijack: http://empeg.ip.addr/?NODATA&BUTTON=TopOr locally: echo "BUTTON=Top" > /proc/empeg_notify Front panel buttons are Top, Bottom, Left, Right, KnobLeft, KnobRight, and Knob There's a way to send "raw" events as well (BUTTONRAW=) but I forget the syntax. Press/Release can also be distinguished. Cheers
|
Top
|
|
|
|
#359051 - 26/06/2013 22:07
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
I forget how that works, but Hijack has interfaces for "cooked" button press/release events.
I have that working, at the moment I decode the key/IR code and translate it into a string before passing it back to the player, my code on the player writes it to /proc/empeg_notify. This code is on the originating machine, the string is written to the destination machine. convert_ir_to_name(void *st,long ircode) { switch (ircode) { case 0x00000000: sprintf(st,"BUTTON=Top"); break; case 0x00000002: sprintf(st,"BUTTON=Right"); break; case 0x00000004: sprintf(st,"BUTTON=Left"); break; case 0x00000006: sprintf(st,"BUTTON=Bottom"); break; case 0x0000000B: sprintf(st,"BUTTON=KnobLeft"); break; case 0x0000000A: sprintf(st,"BUTTON=KnobRight"); break; case 0x00000009: sprintf(st,"BUTTON=Knob"); break; } }
What I really want to do is the pass the raw 32 bit value back to the player, that way consumer IR itself can be proxied. I've not found a way so far. IE The "Menu" key on the IR remote gives me 0x0020DF12, I pass this to the empeg player - my code on the player side needs to fake this as the reception of IR ? With my own centro software if it sees text that is 10 bytes long and starts 0x then it processes it as an IR sequence. IE 0x00000000 will be interpreted as a key up event, 0x0020DF12 as a menu key etc, this means Centro will proxy the IR and key codes player to player with no problems but this doesn't help me with the original player software much :-) I can see what I need to do but I need a raw interface I can write the IR code to, not sure if one exists. If not I will have to write a complete table for IR values to names :-( Would be nice if I could avoid that though, also would be good to go through the hijack IR translation on the destination device rather than the device receiving the IR ? Thanks, Jon
Edited by jonshouse (26/06/2013 22:43)
|
Top
|
|
|
|
#359052 - 27/06/2013 10:16
Re: Empeg player software, a new generation
[Re: jonshouse]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
The /proc/empeg_notify interface accepts 32-bit (well, actually 24-bits -- the high byte is "reserved" for internal use) hex codes for press and release events. They don't have to be "names".
Then, Hijack's built-in IR-translation mechanism can convert those internally to standard empeg action buttons.
So if you can reduce that 32-bit raw value down to 24-bits, nothing new is needed and it can fully leverage the existing feature set.
|
Top
|
|
|
|
#359053 - 27/06/2013 10:18
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
// How button press/release events are handled:
//
// button -> interrupt -> input_append_code() -> inputq -> hijack_handle_button() -> playerq -> real_input_append_code()
//
// hijack.c::input_append_code() performs raw IR translations
// hijack.c::inputq[] holds translated buttons with timing information queued for hijack to examine
// hijack.c::hijack_handle_button() interprets buttons for hijack/menu functions
// hijack.c::playerq[] holds translated buttons with timing information queued for the Empeg player software
// empeg_input.c::real_input_append_code() feeds buttons to userland
//
|
Top
|
|
|
|
#359054 - 27/06/2013 13:37
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
The /proc/empeg_notify interface accepts 32-bit (well, actually 24-bits -- the high byte is "reserved" for internal use) hex codes for press and release events. They don't have to be "names". Last attempt I had looks like this. The buffer "ubuffer" is a string, either in the form "Button=right" or hex in the form "0x12345678", I convert that to a long and write it. Tried writing 3 or 4 bytes cant make it play, see code around "Note, doesn't work" http://www.jonshouse.co.uk/broadcastfb_proc.cOutput looks like this: empeg:/empeg/bin# /broadcastfb_proc Listening on UDP port 5050 Sending packets on UDP port 4040 Got 10 bytes from receiving UDP socket [0x0020DF12] sent 0020DF12 to /proc/empeg_ir, got -1 Got 10 bytes from receiving UDP socket [0x0020DF12] sent 0020DF12 to /proc/empeg_ir, got -1 Got 10 bytes from receiving UDP socket [0x0020DF12] sent 0020DF12 to /proc/empeg_ir, got -1 Got 10 bytes from receiving UDP socket [0x0020DF12] sent 0020DF12 to /proc/empeg_ir, got -1 Thanks, Jon
|
Top
|
|
|
|
#359055 - 27/06/2013 18:02
Re: Empeg player software, a new generation
[Re: jonshouse]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Try it from the command line first, and once you get the syntax worked out there, move it into your code.
My apologies.. the 24-bit value is actually done with ASCII hex, as in:
echo "BUTTONRAW=0x123456" > /proc/empeg_notify echo "BUTTONRAW=0x123456.R" > /proc/empeg_notify
I think. No empeg in front of me at the moment.
|
Top
|
|
|
|
#359056 - 27/06/2013 18:27
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
This feature confuses the hell out of me ! I googled for examples, I can't find any. The only reference I found with anything useful is on the this board and uses names rather than hex. http://empegbbs.com/ubbthreads.php/topics/321953/Remote_control_shell_script#Post321953The ".R" also makes zero sense to me. For example when the Top button is pushed the /dev/ir device generates a 32 bit word with the value 0x00000000 when the button is releases it generates 0x00000001 - If buttonraw is raw then I simply dont understand how it could have usefully have a ".R" suffix or what that would do ? I've tried sending my best guess strings at it but so far everything I send just sends the player to sleep. For example I would expect this to pop up the menu as it is a 24 bit version of the remote control menu button, doesnt work though. echo "BUTTONRAW=0x20DF03" >/proc/empeg_notify Anyone any ideas ? Thanks, Jon
|
Top
|
|
|
|
#359057 - 28/06/2013 13:29
Re: Empeg player software, a new generation
[Re: jonshouse]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Okay, I'm in my home office, and have an empeg in front of me. I'll refresh my own memory first, and then post here how to use it.
Cheers
|
Top
|
|
|
|
#359058 - 28/06/2013 13:32
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
Many thanks for that :-)
I had a quick look at the hijack source but I dont really know way around it :-)
Jon
|
Top
|
|
|
|
#359059 - 28/06/2013 13:41
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Okay. Using button names, I can do variable length presses, like this: echo 'BUTTONRAW=Bottom' > /proc/empeg_notify # wait a second or so, then release it: echo 'BUTTONRAW=Bottom.R' > /proc/empeg_notifyGetting that far required me to realize I named the "down" button "Bottom", not "Down". I'll try hex next.
|
Top
|
|
|
|
#359060 - 28/06/2013 13:50
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Okay, same thing for hex. It appears that the code wants it spelled out completely, as in "0x00000006" rather than "0x6" or simply "6". Pity it's so pedantic about it, but that's how it works.
Here's the "Bottom" button again, using hex:
echo 'BUTTONRAW=0x00000006' > /proc/empeg_notify # wait a second or so, then release it: echo 'BUTTONRAW=0x00000006.R' > /proc/empeg_notify
And next, using the button you were trying (0x20df03), which is actually the SOURCE button, not MENU:
echo 'BUTTONRAW=0x0020df03' > /proc/empeg_notify echo 'BUTTONRAW=0x0020df03.R' > /proc/empeg_notify
Note that using BUTTONRAW requires real-time approximation, as buttons do change function depending upon the interval between press and release.
Hope this helps!
-ml
|
Top
|
|
|
|
#359061 - 28/06/2013 13:53
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Button hex values are in include/asm-arm/arch-sa1100/hijack.hThe same syntax works over http, prefixing the "BUTTON.." command with " http://empeg.ip.addr/?NODATA&". Edit: and the same commands can be done from within an FTP client, prefixing with " site". Eg. site BUTTON=Menu
Edited by mlord (28/06/2013 14:03)
|
Top
|
|
|
|
#359062 - 28/06/2013 14:10
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I don't know if you've tried weblite on a "stock" empeg with Hijack. If not, give it a go. Just untar the contents of the attachment to the root (/) directory on the empeg. Then point a web browser at the empeg's IP address. Click on show/hide remote for some fun with BUTTONRAW.
[attachment deleted -- the BBS seems incapable of attaching it without corrupting it. New issue?]
Edited by mlord (28/06/2013 15:32)
|
Top
|
|
|
|
#359063 - 28/06/2013 14:32
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
echo 'BUTTONRAW=0x00000006' > /proc/empeg_notify # wait a second or so, then release it: echo 'BUTTONRAW=0x00000006.R' > /proc/empeg_notify Oh, OK .... I assumed (incorrectly) that as 0x000006 (push in) is followed by 0x000007 (release) that the application itself timed the perioud inbetween ! And next, using the button you were trying (0x20df03), which is actually the SOURCE button, not MENU:
Me bad, I cut&pasted the wrong line :-) should have been 0x0020DF12, sorry echo 'BUTTONRAW=0x0020df03' > /proc/empeg_notify
Ah, so 32 bits then :-) Doesnt seem to work properly though. If I send right button push: echo "BUTTONRAW=0x0020df11" >/proc/empeg_notify The player sits and skips tracks forever! I tried this just in case, didnt help: echo "BUTTONRAW=0x0020df11.R" >/proc/empeg_notify Can you try skipping ahead one track and let me know what I am doing wrong. To proxy the IR I assume I just write the string and forget but that does not seem to behave ? http://www.jonshouse.co.uk/broadcastfb_proc.cI modified the code to do this : Got 10 bytes from receiving UDP socket [0x0020DF11] sent BUTTONRAW=0x0020DF11 to /proc/empeg_ir, got 20 sent BUTTONRAW=0x0020DF11.R to /proc/empeg_ir, got 22 Player goes nuts processing the same key over and over, with or without the the extra .R line? Thanks, Jon
Edited by jonshouse (28/06/2013 15:15)
|
Top
|
|
|
|
#359064 - 28/06/2013 14:53
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
jon@jonspc:~/x$ file weblite-0.95.tgz weblite-0.95.tgz: gzip compressed data, from Unix jon@jonspc:~/x$ gunzip weblite-0.95.tgz
gzip: weblite-0.95.tgz: unexpected end of file
jon@jonspc:~/x$ ls -l weblite-0.95.tgz -rw-r--r-- 1 jon jon 1096338 Jun 28 17:48 weblite-0.95.tgz
I googled for the file but cant see another source.
|
Top
|
|
|
|
#359065 - 28/06/2013 15:35
Re: Empeg player software, a new generation
[Re: jonshouse]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
echo 'BUTTONRAW=0x00000006' > /proc/empeg_notify # wait a second or so, then release it: echo 'BUTTONRAW=0x00000006.R' > /proc/empeg_notify Oh, OK .... I assumed (incorrectly) that as 0x000006 (push in) is followed by 0x000007 (release) that the application itself timed the perioud inbetween ! Eh? YES, the application DOES have to time the period between. So press the button (BUTTONRAW=0x00000006), delay for however long you want to keep it pressed, and then release the button (BUTTONRAW=0x00000006.R). If you just want a regular short-press (tap, single click) of a button, then let Hijack do it for you: echo 'BUTTON=0x00000006' > /proc/empeg_notify ## combined press/release
|
Top
|
|
|
|
#359066 - 28/06/2013 15:36
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Can you try skipping ahead one track and let me know what I am doing wrong. Yeah, you're holding the button down. Gotta press/release once quickly to skip a single track, just like on the real hardware.
|
Top
|
|
|
|
#359067 - 28/06/2013 15:42
Re: Empeg player software, a new generation
[Re: jonshouse]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I modified the code to do this : Got 10 bytes from receiving UDP socket [0x0020DF11] sent BUTTONRAW=0x0020DF11 to /proc/empeg_ir, got 20 sent BUTTONRAW=0x0020DF11.R to /proc/empeg_ir, got 22
I have no idea at all how to talk to /proc/empeg_ir (is there even such a file?). Hijack implements /proc/empeg_notify for this stuff. Cheers
|
Top
|
|
|
|
#359068 - 28/06/2013 15:48
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
So.. to spell it out completely, here's how to skip one track (assuming no menu is active on the display):
echo 'BUTTON=0x0020DF11' > /proc/empeg_notify
Or like this:
## press/hold the NextTrack button: echo 'BUTTONRAW=0x0020DF11' > /proc/empeg_notify ## delay for, say, 1/4 second .. ## Now release release the NextTrack button: echo 'BUTTONRAW=0x0020DF11.R' > /proc/empeg_notify
Personally, I prefer using names rather than numbers:
## press/hold the NextTrack button: echo 'BUTTONRAW=NextTrack' > /proc/empeg_notify ## delay for, say, 1/4 second .. ## Now release release the NextTrack button: echo 'BUTTONRAW=NextTrack.R' > /proc/empeg_notify
Edited by mlord (28/06/2013 15:52)
|
Top
|
|
|
|
#359069 - 28/06/2013 15:50
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Here's a temporary link to a copy of the http://rtr.ca/weblite-0.95.tgz file. For whatever reason the BBS corrupts the file when I try to attach it directly here.
Edited by mlord (28/06/2013 15:50)
|
Top
|
|
|
|
#359070 - 28/06/2013 18:59
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
## press/hold the NextTrack button: echo 'BUTTONRAW=0x0020DF11' > /proc/empeg_notify ## delay for, say, 1/4 second .. ## Now release release the NextTrack button: echo 'BUTTONRAW=0x0020DF11.R' > /proc/empeg_notify
Ok, this sends the strings - complete with delay but the player software still continues to skip ahead like the button is held down ! Code is here (ps I am updating this code as I go, sorry for any confusion) http://www.jonshouse.co.uk/broadcastfb_proc.cCode output Got 10 bytes from receiving UDP socket [0x0020DF11] sent BUTTONRAW=0x0020DF11, got 20 sent BUTTONRAW=0x0020DF11.R, got 22 Player seems to ignore the .R ? I have inserted a 250ms delay in between the 20DF11 and the 20DF11.R line. Personally, I prefer using names rather than numbers:
Understood, but in this application a non empeg is decoding the infra-red and sending it to the empeg for decode. have no idea at all how to talk to /proc/empeg_ir (is there even such a file?). Hijack implements /proc/empeg_notify for this stuff.
Sorry, this is me adding confusion - the name /proc/empeg_ir was from an older experiment and was still in the printf - my code has always been talking to /proc/empeg_notify. My code now does : A write - sent BUTTONRAW=0x0020DF11, got 20 A delay - usleep(250000); Appends ".R" to the string - strcat(st,".R"); A second write - sent BUTTONRAW=0x0020DF11.R, got 22 Player skips ahead forever ? Note the second write got the string length back from the write (22) so I have no idea what I am doing wrong ! Tried writing a bit of shell script to run on the player, I cant generate a 250ms dielay with ease so I used "echo Hello >/dev/null" 30 times. I cut&pasted your script example but that does exactly the same as my C code - it seems to ignore the.R and acts as if the button is held down. I've made it work - but with a hack. I write 0xFFFFFFFF to cancel the key, that sems to work ! Odd ! Got 10 bytes from receiving UDP socket [0x0020DF11] sent BUTTONRAW=0x0020DF11, result 20 sent BUTTONRAW=0xFFFFFFFF, result 20 Sorry for the effort involved, I am not going to mad but this box just does not seem to act as described - it ignores the .R ? Tried .R in lower and upper case, same result Thanks for the help :-) , if you have any ideas why I need the hack then let me know and and I will clean up my code. Good news is it seems to proxy IR now - pretty cool. Jon
Edited by jonshouse (28/06/2013 19:15)
|
Top
|
|
|
|
#359071 - 28/06/2013 20:10
Re: Empeg player software, a new generation
[Re: jonshouse]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Well, I don't see the bug, where ever it is hiding. But I did write a simple little program, basically a stripped down version of yours, to test with: #include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
static void sendButton (int fd, const char *st)
{
int ret = write(fd, st, strlen(st));
if (ret != strlen(st)) {
fprintf(stderr, "write() returned %d instead of %d\n", ret, strlen(st));
exit(-1);
}
}
int main(int argc, char *argv[])
{
char st[64];
int fd;
if (argc != 2) {
fprintf(stderr, "Error: expected button name/value as only parameter\n");
exit(-1);
}
fd = open("/proc/empeg_notify",O_RDWR);
if (fd < 0) {
perror("Failed to open /proc/empeg_notify for RDWR\n");
exit(1);
}
sprintf(st, "BUTTONRAW=%s", argv[1]);
sendButton(fd, st);
usleep(250000);
strcat(st, ".R");
sendButton(fd, st);
return 0;
}
I just compiled that, renamed it to junk and put it in / on the empeg. Once in place, I ran it many times like this: /junk NextTrackEach time, it skipped forward exactly one track -- I used the "Now&Next" track info display to monitor it. So.. something's not quite right at your end. Maybe the real-time priority is preventing the keys from being processed at the desired time spacing?
|
Top
|
|
|
|
#359072 - 28/06/2013 20:20
Re: Empeg player software, a new generation
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
I also now took your broadcastfb_proc.c program, changed it only very slightly, to simply send the NextTrack hexcode pairs once every five seconds, and this also works:
// broadcastfb.c
//
// Hiijack kernel adds /proc/empeg_screen.raw file. Try reading this instead
//
// Verson 3.1
// Jonathan Andrews ( j o n @ j o n s h o u s e . c o . u k )
//
// Last Changed 28 Jun 2013
//
// Always seems to send 38 frames per second, I think the empeg display is refreshed faster
// but its tricky to find a way to read it without corruption.
//
// Version 2 adds support for remote button presses via UDP port.
//
// Version 3 adds support for messages in the form 0x12345678, these are key press or
// consumer IR 4 byte (long int) represented as hex.
// These messages are sent to /proc/empeg_ir to proxy infra-red sequences or just button
// push/release events
//
#define PORT 4040
#define RXPORT 5050
#define DEST_ADDR "255.255.255.255"
unsigned char fbdata[32*64]; // 32 Rows of 64 Bytes = 2048 Bytes (2K)
#define TRUE 1
#define FALSE 0
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <sys/resource.h>
#include <errno.h>
// sockets related
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
int sockfd;
int rxsockfd;
int proc_buttonfd;
int proc_irfd;
#include <sched.h>
void set_realtime(void)
{
struct sched_param sparam;
sparam.sched_priority = sched_get_priority_max(SCHED_RR);
sched_setscheduler(0, SCHED_FIFO, &sparam);
}
// Received UDP packet.
unsigned char ubuffer[512];
int main(int argc, char *argv[])
{
struct sockaddr_in sendaddr;
struct sockaddr_in recvaddr;
int numbytes;
int broadcast=1;
int allon;
int allblack;
int limit;
int flags;
int j,i,fd;
int res;
caddr_t dmap;
int addr_len;
long ircode=0;
char st[1024];
set_realtime(); // Marking as realtime gives more FPS but some clashing with player
// nice myself to higher priority
setpriority(PRIO_PROCESS,0,-20); // Give this process a CPU boost, same nice as pulse
// Setup receiving UDP socket
if((rxsockfd = socket(PF_INET,SOCK_DGRAM,0)) == -1)
{
perror("rx sockfd");
exit(1);
}
// Setuop socket, specify listening interfaces etc
recvaddr.sin_family = AF_INET;
recvaddr.sin_port = htons(RXPORT);
recvaddr.sin_addr.s_addr = INADDR_ANY;
memset(recvaddr.sin_zero,'\0',sizeof (recvaddr.sin_zero));
// Put socket in non blcoking mode
flags = fcntl(rxsockfd, F_GETFL); // Get the sockets flags
flags |= O_NONBLOCK; // Set NONBLOCK flag
if (fcntl(rxsockfd, F_SETFL, flags) == -1) // Write flags back
{
perror("error,fcnctl failed - could not set socket to nonblocking");
exit(1);
}
if(bind(rxsockfd, (struct sockaddr*) &recvaddr, sizeof recvaddr) == -1)
{
perror("bind");
exit(1);
}
printf("Listening on UDP port %d\n",RXPORT);
fflush(stdout);
// Setup sending UDP socket
if((sockfd = socket(PF_INET,SOCK_DGRAM,0)) == -1)
{
perror("sockfd");
exit(1);
}
if((setsockopt(sockfd,SOL_SOCKET,SO_BROADCAST,&broadcast,sizeof broadcast)) == -1)
{
perror("setsockopt - SO_SOCKET ");
exit(1);
}
sendaddr.sin_family = AF_INET;
sendaddr.sin_port = htons(PORT);
sendaddr.sin_addr.s_addr = inet_addr(DEST_ADDR);
memset(sendaddr.sin_zero,'\0',sizeof(sendaddr.sin_zero));
printf("Sending packets on UDP port %d\n",PORT);
fflush(stdout);
// Open hijack kernel version of framebuffer
fd = open("/proc/empeg_screen.raw", O_RDWR);
if (fd == -1)
perror("open /proc/empeg_screen.raw failed");
// Open /proc/empeg_notify so we can push button presses into it
proc_buttonfd=open("/proc/empeg_notify",O_RDWR);
if (proc_buttonfd < 2)
{
perror("Failed to open /proc/empeg_notify for RDWR\n");
exit(1);
}
//proc_irfd=open("/proc/empeg_ir",O_WRONLY);
//if (proc_irfd < 2)
//{
//perror("Failed to open /proc/empeg_ir\n");
//exit(1);
//}
while (1)
{
if (0) {
lseek(fd,0,SEEK_SET);
read(fd,fbdata,sizeof(fbdata)); // Read data from framebuffer
numbytes = sendto(sockfd, &fbdata, sizeof(fbdata), 0, (struct sockaddr *)&sendaddr, sizeof(sendaddr));
//numbytes = sendto(sockfd, dmap, 2048, 0, (struct sockaddr *)&sendaddr, sizeof(sendaddr)); // direct from FB data
if (numbytes<=0)
{
perror("sendto error");
exit(1);
}
else
{
//printf("Sent %d bytes\n",numbytes);
//fflush(stdout);
}
// Receive text and send it to empeg player to process.
addr_len=sizeof(recvaddr);
numbytes = recvfrom (rxsockfd, (char*)ubuffer, sizeof(ubuffer)-2, 0, (struct sockaddr *) &recvaddr, &addr_len);
ubuffer[numbytes]=0; // terminate actual string
ubuffer[sizeof(ubuffer)-1]=0; // ensure buffer is always 0 terminated
} else {
sleep(5);
strcpy(ubuffer, "0x0020DF11");
numbytes = strlen(ubuffer);
}
if (numbytes > 0)
{
printf("Got %d bytes from receiving UDP socket [%s]\n",numbytes,ubuffer);
fflush(stdout);
// If message starts 0x and is 0x12345678 long then its an IR code
if ( (ubuffer[0]=='0') & (ubuffer[1]=='x') )
{
if (strlen(ubuffer)==10) // sequence is 0x12345678
{
sprintf(st,"BUTTONRAW=%s",ubuffer);
res=write(proc_buttonfd,st,strlen(st)); // write text to /proc/empeg_notify file
printf("sent %s, result %d\n",st,res);
fflush(stdout);
usleep(250000);
strcat(st,".R");
res=write(proc_buttonfd,st,strlen(st)); // write text to /proc/empeg_notify file
printf("sent %s, result %d\n",st,res);
fflush(stdout);
}
}
else
write(proc_buttonfd,ubuffer,strlen(ubuffer)); // write text to /proc/empeg_notify file
}
usleep(5000); // works well, 38 frames/second
}
close(fd);
}
|
Top
|
|
|
|
#359073 - 28/06/2013 20:25
Re: Empeg player software, a new generation
[Re: mlord]
|
journeyman
Registered: 18/09/2012
Posts: 55
Loc: Somerset UK
|
Nice one :-) I compiled your code and put in root with the same name: empeg:/# /junk NextTrack /junk NextTrack Works fine empeg:/# /junk 0x0020DF11 /junk 0x0020DF11 Skips Skips Skips forever ....... Remember the sender is not running Hijack and has only the IR code, I don't want to translate all the IR codes into names if I can avoid it - I just want to send it to the empeg and have it process it. PS How do you post code in forum :-) I am not offered a code tag in the posting form and it would be nice to see correct formatting for things I post :-) ? Thanks again for the help :-) Just in case its compiler related or some other odd problem: Source http://www.jonshouse.co.uk/junk.cBinary http://www.jonshouse.co.uk/junkempeg:/empeg/bin# cat /proc/version Linux version 2.2.17-rmk5-np17-empeg55-hijack-v515 (hijack@rtr.ca) (gcc version 2.95.3 20010315 (release)) #2 Wed Jul 20 09:24:02 EDT 2011 Jon
Edited by jonshouse (28/06/2013 21:01)
|
Top
|
|
|
|
|
|