Behave like a SD- card?
Christof Eb.
Posts: 1,200
Hi, this is just an idea and I am wondering, if it would be possible:
Photo- Frames are quite affordable these days. They have slots for SD- Cards and can change to the next picture after some time.
Would it be possible for the Prop to emulate a SD Card and possibly create new pictures and feed it to the reader each time it asks for a new picture?
Christof
Photo- Frames are quite affordable these days. They have slots for SD- Cards and can change to the next picture after some time.
Would it be possible for the Prop to emulate a SD Card and possibly create new pictures and feed it to the reader each time it asks for a new picture?
Christof
Comments
-Phil
The interface to the photo frame knows nothing of a file system, it is only exchanging numbered blocks with the Propeller, which it thinks is an SD. The Propeller would get those blocks from that real SD and send them to the photo frame.
The problem here is that now we have a Propeller with a live file system talking to an SD. At the same time the photo frame has it's own file system software maintaining a live file system on the same SD.
I can see this going awfully wrong and all kinds of corruption happening.
Might possibly be made to work if the Prop closes down that interface to the photo frame, mounts the SD card file system, opens a file, writes the image, closes the file and un-mounts the SD card.
Meanwhile, if the photo frame wants to read files it will error out until the Prop has finished, and hopefully try again.
The idea is of course that only one device has SD access at a time.
All sounds like too much hard work to me. Even if you can make a fast enough SD interface.
In the scenario you present, there would be no point in involving the Propeller at all. Why not just plug in a real SD card, and be done with it? I think what the OP is after is a way for the Prop to generate its own images on the fly and use the photoframe as its display. In that case it would have not only to convert raw images to a format the photoframe understands (.bmp, .jpg, etc.) but emulate a file system with a directory so the photoframe could retrieve said images as if the Prop were a real, FAT-formatted SD card. That's not to say, of course that Kye's FAT32 object could not be changed to emulate a virtual filesystem for the on-demand images, but I don't think a real SD card attached to the Prop is necessary.
-Phil
A couple of reasons for using a real SD card:
1) Caching:
The Prop does not have to generate images on the fly as they are requested. Rather it could save them to SD and serve them up super quick from there. In the data logging example you might have ten different sensors and want 10 separate graphs. Log the data, create the bmps, at your leisure, swap them into files the photo frame sees when done.
2) Convenience.
We already have FAT file systems for SD that work fine.
All we need here is to create the SD interface for the photo frame and give raw blocks from the real SD to it when requested.
As long as we can stop them fighting over the FS structure on that SD we are good to go.
-Phil
My next test would be to yank the SD out of the photo frame for a while and see if it recovers nicely when I put it back. Thus simulating the Prop taking over card access for it's own business.
-Phil
Hello!
Whose photo frame are you thinking of? I've seen plenty available as viewers on keychains, and seen people reuse them because their screens are better then some of the individual displays that are also available. Then I've seen several actual frames, and as it happens the big sticking point is in fact a classic, the backlight. Typically they use CCFL means to light them and typically the management electronics typically fails. The user gets stuck using one from the company, unless he knows how the thing can be wired and has made a third party one work.
And also gotten Linux for that processor to run on it unassisted. Typically it already is, but its only purpose is in managing the display of pictures. But he wanted to display his pictures properly, and without the assistance of bloat from the original vendor......
So your idea is a good one.
No, the SD card's "processor" requires the clocks but typically when you issue a read command you must keep clocking until you receive a read token to indicate that the data follows. So by leaving the data line high the host will continue to clock for a system dependant timeout period until it finds a response (non $FF).
As for the OPs request I would find it more practical to hack the actual display and drive it directly as otherwise you can only provide information in jpg format, not something you can create dynamically.
It is possible to hack some of the 7 inch portable DVD players and photo frames to use them as displays; I demonstrated such a photo frame hack at the 2010 UPEW. This is possible if the LCD is being driven by analog RGB signals, and the hack requires the original hardware to generate the very complex timing for the LCD (generally thinking it's displaying a screen saver or slide show) which is read by the Propeller, and letting the Propeller inject the RGB signals to form an image.