#227125 - 15/07/2004 02:14
Remote display (ASCII)
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
Hypothetically let's say I have a remote display device which can display 3 lines of 8 characters each. It has a microcontroller and an RS-232 port. Let's say it also has some input device like joystick and/or a few buttons.
How much glue do I need to write to get a basic remote player display working with this?
As I recall (it's been a while and they're packed away) the empeg player software can be configured to print out the current track, and accept commands to control playback. But can the menus (playlists, etc.) be navigated via the serial console?
I looked around a bit but it looks like the other remote display projects involve a bitmapped remote display. Has anyone tried an ASCII remote display?
Any comments will be appreciated.
|
|
Top
|
|
|
|
|
#227126 - 15/07/2004 04:19
Re: Remote display (ASCII)
[Re: kday]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
That is, in fact, the very limitation of the serial port control; you can't navigate the menus with it. All that gets put out the serial port is the track titles, not the on-screen responses to your command inputs.
And don't think about just extending the wires either...
|
|
Top
|
|
|
|
|
#227127 - 15/07/2004 11:10
Re: Remote display (ASCII)
[Re: kday]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
This should be doable. You'll have to write your own input/output processing for the serial connection to it, as the default empeg interface is probably not the best for this specific part. With your own userland app controlling it, the sky is the limit here. /proc/empeg_notify (from Hijack) provides much of the player status info (track titles etc..) that could be relayed out to the display. Or you could get much fancier and more complex by digging into the dynamic data partition..
Cheers
|
|
Top
|
|
|
|
|
#227128 - 15/07/2004 11:23
Re: Remote display (ASCII)
[Re: tfabris]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
tfabris - Okay, thanks.
Now, how to fix this? I can think of two approaches off the top of my head: screen-scraping and patching or otherwise screwing around with the player binary.
It would be tedious, but it seems to me that screen-scraping could be made to work reliably and across different player versions. Are the player fonts stored somewhere on disk separate from the player binary? That would make implementing this at least somewhat less tedious.
It's hard to say what would be possible by patching and/or snooping on the binary without doing a bit of disassembly first. I don't suppose the player binary still has the debugging symbols in it...?
Thoughts?
If I can get this working without too much effort I'll be able to put the empeg back in my car.
Looking forward to that. I thought 10 discs would be enough but I was wrong.
Edited by kday (15/07/2004 11:29)
|
|
Top
|
|
|
|
|
#227129 - 15/07/2004 11:28
Re: Remote display (ASCII)
[Re: mlord]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
mlord - please tell me more about this dynamic data partition. Can it provide hooks into the player menu system?
|
|
Top
|
|
|
|
|
#227130 - 15/07/2004 14:19
Re: Remote display (ASCII)
[Re: kday]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
yn0t_ (Tony) is really the expert on that part. He has a 3rd party app that basically replaces the player UI with a skin of his own making -- probe him for details, or even build on his code base perhaps.
Cheers
|
|
Top
|
|
|
|
|
#227131 - 10/08/2004 02:31
Re: Remote display (ASCII)
[Re: kday]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
Continuing from this thread Quote:
It seems like what you want is basically a representation of the player menu on some external display, and the ability to navigate that reliably with an external input device. I don't think emphatic is going to be the ticket to that. Unless I came up with some way of screen-scraping the player menu itself, which is way too tedious for something that wouldn't really help many other people out.
Okay, oh well. Thanks anyway. Screen-scraping seems like the obvious way to go. In my copious free time I may try to prototype something using the .png file that hijack publishes of the framebuffer. Anyone know if the fonts are available somewhere?
Quote:
Have you found the external display threads in the Projects forum yet? A few people were working on a microcontroller of some type that would drive a graphical external display, and show an *actual* copy of the player screen on it (or some subset of it.) Do some searches, that seems more like what you want. But if you're dead set on using your character-based display, I'm not sure what the solution is.
I don't really have room for a big graphical display. A picture is worth at least a few hundred words on what I'm after...
|
|
Top
|
|
|
|
|
#227132 - 10/08/2004 02:59
Re: Remote display (ASCII)
[Re: kday]
|
carpal tunnel
Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
|
Quote:
Anyone know if the fonts are available somewhere?
Yes, in /empeg/lib/fonts. You should be able to reverse-engineer the format from vfdlib.c which is included in the emphatic source.
8 characters, huh? So you're just going to scroll the title by on that tiny display? I'm all about minimalism and all that, but aren't you going to have to be staring at the dash for several seconds before you get a whole artist/title spit out on there? I can't even begin to think of navigating the player menu on an 8 character display. Or am I missing something?
|
|
Top
|
|
|
|
|
#227133 - 10/08/2004 12:47
Re: Remote display (ASCII)
[Re: tonyc]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
Quote:
Yes, in /empeg/lib/fonts. You should be able to reverse-engineer the format from vfdlib.c which is included in the emphatic source.
Cool. That will take at least some of the tedium out of it.
Quote:
8 characters, huh?
I only have one display at the moment, but there is room for 2 or 3 of them. I'm getting a PCB fabbed which will hold 2 and some LEDs. (This is intended to be more than just an empeg display.) Additionally, there is the built-in computer (seen here) which currently displays the radio station / cd track from the stock head unit. There's another 40 x 40 pixels or so there, if I get around to reverse-engineering the display protocol. It looks as if it may just be a big shift register, but I haven't hooked it up to a logic analyzer yet.
But in any event, I actually think 8 characters could be made to work. As long as I can navigate the menus (specifically the playlist tree) well enough I don't care if I can view all of the information on the empeg display. I didn't tend to look at it much when it was in the dash of my previous car, just enough to select the playlist I wanted.
I could rename all playlists to be 8 characters or less. Track title and artist are only occasionally needed, I think -- in most cases I already know what I'm listening to.
|
|
Top
|
|
|
|
|
#227134 - 10/08/2004 20:08
Re: Remote display (ASCII)
[Re: kday]
|
pooh-bah
Registered: 12/02/2002
Posts: 2298
Loc: Berkeley, California
|
Quote:
I don't really have room for a big graphical display.
Maybe you have room for a little graphical display?
Matthew
|
|
Top
|
|
|
|
|
#227135 - 10/08/2004 21:24
Re: Remote display (ASCII)
[Re: matthew_k]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
That would be nice!
I've looked long and hard for a small red or amber dot matrix display that would fit there, without much luck. The display above that location is a transmissive LCD with orange and red bulbs behind it, and another one of those would work just fine, but I haven't been able to find any suitable LCD modules.
Another idea I had was replacing one of the small gauges (probably the analog clock) with a 2.5" LCD, but I found that generating the video signal becomes either too complicated (microcontroller + FPGA + video encoder) or too bulky (mini-ITX motherboard, power supply, etc.). I pursued both of those ideas to some degree, but ended up deciding to keep it relatively simple in the interest of actually finishing the project. It's easy to overestimate how many evenings and weekends will be available for tinkering on this kind of thing!
|
|
Top
|
|
|
|
|
#227136 - 12/08/2004 13:03
brute force framebuffer parser
[Re: tonyc]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
Last night I wrote a quick and dirty parser for the display and it mostly works. Given a framebuffer image it will return a string corresponding to the currently selected menu item, if any.
There are a few unresolved issues. One is that capital i and lower-case L are drawn identically, at least in the medium font. Another is that the player uses a smaller font for long strings than it does for short strings and the current parser only loads the medium font. And finally, doing a naive search character by character is probably too slow for the strongarm. I have some ideas to address that.
To address the i/L thing, I need to add a pixel to one of the two characters. I don't suppose anyone has written a font editor for the empeg, have they?
I don't know if this will be useful to anyone else or not. Let me know if there's interest.
|
|
Top
|
|
|
|
|
#227137 - 12/08/2004 14:45
Re: brute force framebuffer parser
[Re: kday]
|
Master Boot Logo(er)
Registered: 26/08/2003
Posts: 525
Loc: California
|
Quote:
I don't suppose anyone has written a font editor for the empeg, have they?
Here you go.
_________________________
aka: [color:"blue"]Boot Logo Master[/color] PayPal Contributions for Custom Boot Logos are gladly accepted. <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> itirado[@]adobe[.]com
|
|
Top
|
|
|
|
|
#227138 - 12/08/2004 15:06
Re: brute force framebuffer parser
[Re: Skunk]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
Just remember that the font editor only works with v2 player fonts. v3 fonts aren't the same.
|
|
Top
|
|
|
|
|
#227139 - 12/08/2004 15:06
Re: brute force framebuffer parser
[Re: Skunk]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
That's a nice surprise -- thanks...
|
|
Top
|
|
|
|
|
#227140 - 12/08/2004 15:46
Re: brute force framebuffer parser
[Re: kday]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
Quote:
To address the i/L thing, I need to add a pixel to one of the two characters.
It appears that the number of pixels you have to work with in the display you pictured are no more than the empeg uses to display a single letter. If it's not a real issue on the empeg, why would it be an issue on your display? Pick one glyph and use it for both letters on your display in the same way the empeg uses the same glyph for the two letters.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#227141 - 12/08/2004 15:54
Re: brute force framebuffer parser
[Re: kday]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31597
Loc: Seattle, WA
|
Quote:
To address the i/L thing, I need to add a pixel to one of the two characters. I don't suppose anyone has written a font editor for the empeg, have they?
Why not just design your parser to accept i/l as fuzzy and check against a table of "known" menu item names?
Or better yet, just choose to not care. Won't they look the same on an ASCII display anyway?
Edit: yeah, what Bitt said.
|
|
Top
|
|
|
|
|
#227142 - 12/08/2004 17:12
Re: brute force framebuffer parser
[Re: wfaulk]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
The main difference between the display I'll likely use (the one linked earlier) and the empeg display is that although the small display is bitmapped, it only lends itself to fixed-width fonts. The inter-character spacing is enforced by lack of pixels between each 5x7 character cell. That doesn't prevent me from making I and l appear the same, but the current font I'm using does display the two differently. It was a while ago, but I seem to recall that finding a suitable font and converting it (for the microcontroller sw) was annoying, and since I already did it I don't want to do it again.
In any event, changing one bit in the font file is trivial. (Determining which bit should be only slightly less trivial...)
|
|
Top
|
|
|
|
|
#227143 - 12/08/2004 17:13
Re: brute force framebuffer parser
[Re: tfabris]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
Quote:
Why not just design your parser to accept i/l as fuzzy and check against a table of "known" menu item names?
Because the set of playlist titles isn't known.
|
|
Top
|
|
|
|
|
#227144 - 12/08/2004 18:39
Re: brute force framebuffer parser
[Re: kday]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
I don't think you're following me. If you detect a letter that's either an I or an l, then just print on your display the one that looks closest to both. That is, just display a lower-case L in both cases. It'll look just as much like a capital I as it did on the empeg, unless both the capital I and the lowercase L on your display are serifed.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#227145 - 15/08/2004 15:36
Re: Remote display (ASCII)
[Re: kday]
|
carpal tunnel
Registered: 17/01/2002
Posts: 3996
Loc: Manchester UK
|
Where did you get that little ASCII VFD from?
_________________________
Cheers,
Andy M
|
|
Top
|
|
|
|
|
#227146 - 19/08/2004 19:22
Re: Remote display (ASCII)
[Re: andym]
|
new poster
Registered: 05/01/2002
Posts: 40
Loc: Boston, MA
|
Assuming you mean this one, that particular display came with a radar detector wrapped around it.
It's an Agilent HCMS-2912 . Digikey carries them. It's a LED dot matrix, not a VFD.
It's not an ASCII display per se. There is no character generator in it.
Edited by kday (19/08/2004 19:23)
|
|
Top
|
|
|
|
|
#227147 - 19/08/2004 20:14
Re: Remote display (ASCII)
[Re: kday]
|
carpal tunnel
Registered: 17/01/2002
Posts: 3996
Loc: Manchester UK
|
That's great, thanks for the info.
_________________________
Cheers,
Andy M
|
|
Top
|
|
|
|
|
|
Previous Topic
Index