h a l f b a k e r yGuitar Hero: 4'33"
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
There's lots of companies that sell USB components that can handle sensors and control I/O. Phidgets Inc from Calgary are one example whose products I've used to build some lab equipment, and these devices all need a host PC to run it.
What I'd like to do is untether the lab equipment from the PC
host, and have an ARM cpu with touch screen for process control, SD card for data logging, and a USB connection. Once programmed the device is able to run standalone if required.
Sure, I could use an iPhone/iPad/Android tablet, but there's two big problems here: the knowledge gap and the complexity or/and cost of the development tools. Apple have a minimum standard for add-on devices and there's quite a set of hoops to jump through, plus costs. Last year I learned how to write iPhone and Android apps, and it's like pulling teeth. Moreover, as I've found over the last 18 months, developing an embedded application in C is not like
writing for Windows, as the hardware setup has to be thoroughly understood. Fun, sure, but not for the technically challenged or faint of heart.
In any case, iPhone/iPad/Android devices are diffcult to integrate into another piece of hardware if they are already packaged. My idea is that the Touch Screen/SDcard/USB/sensor+control gadget is a component intended to be built into something else.
On the software side, only the simplest RTOS is required, with a powerful interpreter built on top of it. The interpreted language (called PiXCLe, derived from PiXCL 10) provides file and directory management, full graphics and touch regions for the UI, and most importantly, commands for sensor and control I/O.
The embedded app is generated as a simulation using the Windows version of PiXCL, and then downloaded to the gadget's SD card, where it is read and executed by the interpreter. The primary point here is that most of the complexity of USB_TouchScreen_I/O is hidden away and the user NEVER needs to see it.
Updates to the interpreter can be done in the field using Device Firmware Upgrade (DFU).
The result is a USB component device that works out of the box, and can be simply programmed or reprogrammed by relatively unsophistsicated users.
All comments appreciated. If you would like to discuss this idea in more detail, please contact me directly.
http://www.pixcl.com
Smart USB Screens, Sensors, Controls, Imaging [rallysjd, Dec 02 2011]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
isn't this what Java is all about? Develop on a PC run on an
embedded device. If J2SE is too much than get happy with a
micro vm. |
|
| |
and yep ... been there, done that, messed up java versions
while porting to android. |
|
| |
Thanks for the feedback. Actually, no. Java and a micro vm by themselves, still requires all the underlying UI functions (graphics, touch regions, fonts and so on) to be present and callable. PiXCLe is a very high level language (written in C) that's mostly self-documenting. For example, drawing a string in a selected font and color is done by |
|
| |
UseFont(FontName$,flags, r,g,b)
DrawText(x,y,String$) |
|
| |
The USB gadget I'm proposing could be used as an input device and external controller to any host (PC, iPhone, Android). |
|
| |
Could you perhaps say what the thing is and what it does: I can't figure out if it's supposed to be a dedicated device for programming chips, or entire devices, or a simulator for other devices... or the brains for a device. |
|
| |
Rather vague, all in all. A suitably streamlined Windows PC can simulate a RT environment if you're not too picky about response time and don't mind that it's sure to crap out at some point for no apparent reason. |
|
| |
(I've done a bit of ladder programming on RT controllers... but that was in assembler.) |
|
| |
'Arduino' seems to be a name that crops up quite a bit. |
|
| |
[reedit: I streamlined the anno while rallysjd was answering it: I said that it seemed he/she wanted a real-time pod/pad] |
|
| |
Yes, that's close. The pod/pad (nice term) also has digital inputs for switches, and outputs for, say, relays or control circuits, plus some analog inputs for sensors such as pressure, temperature, humidity, light level. |
|
| |
The PiXCLe language includes all the commands to create the UI including touch regions, handle the sensors and control I/O, and log data to the SD card. Since its a USB device, touch events can also be sent to a host PC if required, and the host PC can also send UI and control commands to the gadget. |
|
| |
PiXCLe hides all the complexity of how the hardware works, letting you concentrate just on solving the interaction of the UI and the process being monitored and controlled. |
|
| |
oy, an uncomfortable percentage of mine are serious. I usually trim them out eventually. |
|
| |
I'm thinking there has to be something on the market already that can come close to [rallysjd]'s wish-list. Maybe not since I think M$ and Apple have boosted the art of touch-screen UI far past what anybody else did previously... and they're both pretty closed shops. |
|
| |
//plus some analog inputs// yeah, at this point it's just a wishlist though. Might as well 'fess up to what you're trying to build. |
|
| |
" ... just a wishlist". Hmmm, maybe. |
|
| |
Contact me directly (see the profile) and we can talk. |
|
| |
I'm a hermit, sorry. If you wanted to discuss serious product development privately, either by or for yourself, perhaps somebody else will take the opportunity. |
|
| |
Meanwhile, rest assured that there's always some bored git or ten who will happily inform you, in varying degrees of reality, of how to go about doing whatever it is you want to do. |
|
| |
If, or even if not, that's your intent. |
|
| |
Sounds like you want a RT pod/pad for the lab or hobby experiments, and an OS to go along with it. Cool. |
|
| |