Would you use a GUI at all to interact with Propeller ?
jazzed
Posts: 11,803
I'm considering designing a GUI (Windows application or some other means) as an interface to a small Propeller configuration database and would like to know if it would be a fair use of my time.
In·vampyr's Standards for hardware ... O/S ... thread. There is a discussion for providing a small database for a run-time hardware configuration spec in addition to a compile-time hardware configuration spec.
The database would allow precompiled binaries to get the user's hardware configuration for interacting with external elements without requiring a reboot of the system as would most likely be the case for the compile-time spec.
One of the difficulties to overcome is how the user would configure the database. Having basic I/O performed by the Propeller would be necessary in this scenario.
An application can be launched on Propeller to provide full programming ability at some point. I guess one question is whether a Propeller application is launchable today.
Some users might prefer a GUI for configuring the database. I would like to know how much interest is in such a GUI before spending much·time on it.
A GUI is attractive for several reasons:
If you think a GUI would be useful for interacting with Propeller for programming a configuration database the please let me know. All code should be made available under MIT liscense.
Being able to define requirements in the design process is very important. A requirement is a usage aspect that affects design decisions.
All requirements any user may have that is interested in a GUI should be submitted in this thread by users along with their GUI interest level. If there is no interest, then wasting time on a Saturday is not so bad.
It is possible that a similar GUI might be designed in various languages ... that's what developers do [noparse]:)[/noparse] If that happens, having a good list of requirements could help in getting minimum features in them all.
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
In·vampyr's Standards for hardware ... O/S ... thread. There is a discussion for providing a small database for a run-time hardware configuration spec in addition to a compile-time hardware configuration spec.
The database would allow precompiled binaries to get the user's hardware configuration for interacting with external elements without requiring a reboot of the system as would most likely be the case for the compile-time spec.
One of the difficulties to overcome is how the user would configure the database. Having basic I/O performed by the Propeller would be necessary in this scenario.
An application can be launched on Propeller to provide full programming ability at some point. I guess one question is whether a Propeller application is launchable today.
Some users might prefer a GUI for configuring the database. I would like to know how much interest is in such a GUI before spending much·time on it.
A GUI is attractive for several reasons:
- Visual data organization.
- Context sensitive help.
- Easy input range validation.
- Capability for getting automatic updates of common data.
- Front end off-loads the uC (less memory used).
- Program in the uC could be very simple and less subject to change.
- Other advantages.
If you think a GUI would be useful for interacting with Propeller for programming a configuration database the please let me know. All code should be made available under MIT liscense.
Being able to define requirements in the design process is very important. A requirement is a usage aspect that affects design decisions.
All requirements any user may have that is interested in a GUI should be submitted in this thread by users along with their GUI interest level. If there is no interest, then wasting time on a Saturday is not so bad.
It is possible that a similar GUI might be designed in various languages ... that's what developers do [noparse]:)[/noparse] If that happens, having a good list of requirements could help in getting minimum features in them all.
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Comments
Very few of my apps have needed such integration to the real world by this means though. The one app which did used a PC as a http bridge to create a SitePlayer type setup for a micro which had no ethernet controller, only serial in and out.
Mainly for machines gathering QC data - reading/writing to/from network based databases - calculating SD,CP and CPK for production - creating html files to display on internal website and pdf's of batch data emailed to specific locations on request.
Years back I had Visual studio 6 apps with stamp based controllers .. here was one (old visual studio 6) with the operator trying it out before it was tweaked ..
Barracuda
Most machines I make are purely micro based - doing away with the need for the 'bloatware' and licensing issues.
There is another option - have a HMI unit as the front end - they are simple to setup/program.
www.beijerelectronics.com/web/beijer_electronics.nsf/AllDocuments/748165FB7E8F0FA0C12573320028DA56
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 6/29/2008 2:39:08 PM GMT