|
|
|
CameraWorld
P
a r t O n e:
On 5/22/03 sknaster posted to the Danger Developer wiki
this page:
http://developer.danger.com/wiki/space/internal+methods
which reads in part:
internal methods
Created by
sknaster
. Last edited by
sknaster
All classes in danger.system and their members are
unavailable except the following :
danger.system.CameraDevice
This page was posted about the time the 43619 SDK
(#5 for those counting) was released. There were no docs in
the SDK, so out came the OSX Java Browser. Sure enough, the
API was found in:
library.jar/danger/system/CameraDevice
It seemed simple enough to grab an image from the
camera, so with a quick hack the HelloWorld example became
CameraWorld (verified against SDK #6
44538):
http://homepage.mac.com/eric3/danger/cameraworld.hqx
Note: On 6/10/03, Danger officially documented the Camera
API at:
http://developer.danger.com/wiki/space/(api)danger.system.CameraDevice
The main purpose of this image capture experiment was not to display the image, but rather to grab an image directly from the camera with Java code under direct developer control. With the ability to grab an image on command, the Hiptop now has the ability to become a wireless web cam, a notification system for image changes in scientific or security applications, to become a panorama creation tool, or any number of applications requiring image capture and manipulation.
For the astute reader: You will note that the CameraWorld sample not only displays the image, but also logs a bunch of image related data to the console, including the image bitmap. This data has virtually confirmed research regarding the Hiptop camera hardware itself, and is where the fun really starts.
As we all know, there is no easy way to get external physically wired data into a Hiptop. There is no serial 1-wire, I2C, or SPI API in the current Danger SDK. If you want to attach a GPS, a weather station, or a camera of your own making (IR/UV/whatever), you are just simply out of luck. The Hiptop has USB, but indications are that this is a USB slave and is not capable of initiating transfers as a master. The Hiptop has IR, but the rumor mill claims it is really of no use and will remain undocumented. The Hiptop can, however, read data from the its camera. This is a start, so off to research the camera hardware.
Taking the camera apart and checking the name and part
number of the ASICs, it was quickly determined to be made by
Kyocera. In fact, the Hiptop camera is really just a
slightly higher resolution version of the Kyocera Treva cell
phone camera sold in Japan:
|
|
The next step is to see if the Hiptop camera communicates like a Treva camera. After some fiddling around with an eZ8 Encore! 20MHz development board, the Hiptop camera was chattering up a storm. It was a pleasant surprise to read in camera header/image/footer data and to discover the data was as expected from a Treva type camera as documented on various web sites.
To sum up for those who have managed to get this far:
- We have grabbed a camera image from the Hiptop via the CameraWorld sample app and have analyzed the image information and data.
- The first generation Hiptop camera, with its ever so slightly larger image size, appears to be a newer generation Treva cell phone camera.
- We have decoded and verified the camera communication protocol. We have been able to talk to the camera and see camera data via an eZ8 Encore! development board. Since we now understand the camera protocol, there is little reason why we can't attach a camera of our own design to the Hiptop.
To those for whom this may have escaped: We can send data packets of our choosing to the Hiptop. We can, via Hiptop Java SW under our control, capture these data packets in the form of a bit map onto a Hiptop device. What we do with this data is up to us, like, say, decode the data as GPS information. But, you say, the Hiptop camera is only a 120x90 2 byte per pixel bitmap, which is 21600 bytes of packet data, not really all that much for a single blob of data. Well, we say back to you, with the introduction of the new Color Hiptop, Danger also announced a newer, higher resolution camera. And, we say, the camera data header information contains the width and height of the bitmap. Since we own the data being sent, we can send in as much or little as resources constrain.
Cool huh!
We have uncovered a means to effectively send serial data into the Hiptop for data logging applications. We have the ability to read directly from the camera for image capture and manipulation applications. These abilities open up a huge array of possibilities for new Danger applications. Fly like the wind and go forth creating cool new Hiptop camera like hardware and applications!
Okay, now for the really important bit. We have yet to actually send instrumented data to the Hiptop. Not for lack of trying, but for lack of time. We have simply not tried yet. Give us a break; we just started messing with this eZ8 Encore! Development board. There are still impedance/current matching and signal buffering issues to be worked out.
The important question to be answered is "Is the image bitmap captured by the CameraWorld sample app the same data as sent in by the camera?" Or, put another way "Does the Hiptop OS do any post processing of the data before it is delivered to the API level code?" Indications are that the camera data is the same as the data presented via the API, with the exception of endianness. The Hiptop presents the data byte-swapped from the data sent from the camera hardware.
Part Two: Hiptop Camera Protocol Investigation
- To Do: Part Four - Sending Data to the Hiptop
- Dealing with SPI slave underflow situations
- Determine maximum SPI slave speed of the eZ8 development board
- Buffering clocks and data between the Hiptop and the eZ8 development board
- Determine the Hiptop heuristic for deciding a camera is attached
- Determine if the captured bitmap image is unprocessed camera data
- Data packet management and reverse communication techniques
Last Updated: 6/19/03