This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.
Posted: Wed Nov 16, 2005 3:41 am
Good day,
I've got a question that hopefully someone can help me with:
First, some background: I'm on the verge of purchasing an LCD and controller package from HVWTech located in Calgary, Alberta, Canada. Before making this purchase, I'd like to get a feel for how intensive the code development for this module will be. I'll be programming code in C, and the target uC is a MC68HCS12DP256B. My plan is to use one of the SCIs on-board the uC in order to communicate to/from the LCD and keypad.
I direct my question in this fashion: has anyone implemented some sort of menuing concept for an LCD/keypad combo? I'm thinking of something like a text-based interface whereby a user can enter choices or input data using a keypad, and have those choices and data echoed to the display. In addition of course to having the target uC perform the necessary operations based on what the user has inputted. The menu system can be hierarchical, and ideally should be easy to adapt to other parts of a user's program (no extensive use of global variables, minimal amount of dependency on other blocks of code).
My goal is to add on a human user interface (HUI) to my robotics project. Basically, I've outgrown my ability to use a terminal program for interacting with portions of my code during runtime.
Any help you can provide will be greatly appreciated!!
I've got a question that hopefully someone can help me with:
First, some background: I'm on the verge of purchasing an LCD and controller package from HVWTech located in Calgary, Alberta, Canada. Before making this purchase, I'd like to get a feel for how intensive the code development for this module will be. I'll be programming code in C, and the target uC is a MC68HCS12DP256B. My plan is to use one of the SCIs on-board the uC in order to communicate to/from the LCD and keypad.
I direct my question in this fashion: has anyone implemented some sort of menuing concept for an LCD/keypad combo? I'm thinking of something like a text-based interface whereby a user can enter choices or input data using a keypad, and have those choices and data echoed to the display. In addition of course to having the target uC perform the necessary operations based on what the user has inputted. The menu system can be hierarchical, and ideally should be easy to adapt to other parts of a user's program (no extensive use of global variables, minimal amount of dependency on other blocks of code).
My goal is to add on a human user interface (HUI) to my robotics project. Basically, I've outgrown my ability to use a terminal program for interacting with portions of my code during runtime.
Any help you can provide will be greatly appreciated!!
Posted: Wed Nov 16, 2005 10:41 am
Not exactly but I did see ademo of an S12X driving a 1/4 VGA display recently at one of the FTF events, I will try to get some more info.
Posted: Wed Nov 16, 2005 2:38 pm
Hi,
I used a display in a similar fashion.
As you want to drive it through the SCI you have a smart display.
You just have to send commands and data through the SCI, it's very easy.
You will need to have a map/table of the commands and also of the characters. From these you can write your low level drivers transforming the command "blink-letter" with the write message, like 0x80 0x25.
Also for widely used screen you can find C code on the web of the manufacturers or others. Search for the reference number in Google.
This C code already makes conversions so you just have to execute the functions... Too easy
Cheers,
I used a display in a similar fashion.
As you want to drive it through the SCI you have a smart display.
You just have to send commands and data through the SCI, it's very easy.
You will need to have a map/table of the commands and also of the characters. From these you can write your low level drivers transforming the command "blink-letter" with the write message, like 0x80 0x25.
Also for widely used screen you can find C code on the web of the manufacturers or others. Search for the reference number in Google.
This C code already makes conversions so you just have to execute the functions... Too easy
Cheers,
Posted: Fri Nov 18, 2005 12:32 am
I've done this type of application several times to CRTs and LCD displays, using HC05 and HC11 processors. Alas, I've never done it with C, only assembly.
Basically, just sit down and define all the screen views you want to see on the display as -formated- character strings, paying attention to which lines of the screen you're dealing with. Then make a callable routine that transfers a given string to the display.
Then of course you have to write various functions to deal with key/switch input. Can't help you there.
Basically, just sit down and define all the screen views you want to see on the display as -formated- character strings, paying attention to which lines of the screen you're dealing with. Then make a callable routine that transfers a given string to the display.
Then of course you have to write various functions to deal with key/switch input. Can't help you there.
Posted: Fri Nov 18, 2005 2:30 am
Thanks to everyone for all your help! I'm glad I'm still at the stage of this project whereby I can make changes and not worry too much.
An idea presented to me was to implement a display/input device using Bluetooth coupled with a Pocket PC. I'm somewhat new to Extended Visual C++ (EVC++), how long will it take for someone with modest knowledge in OO (read: Java) to come up to speed?
My initial thoughts on implementing bluetooth (correct me if I'm wrong) are:
1. To keep the concept portable, I'd want to run my "terminal" and other custom apps from a PocketPC or similar device. Doing some quick searching I find that the latest PocketPCs run Windows CE ver 5.0. The download site for EVC++ claims it is written for Windows Mobile 2003. Do you think I'll be able to write apps using EVC++ 4.0 and make them run on a target running CE 5.0?
2. On the subj of custom apps: is it incredibly difficult to code a GUI that has features much like that found when coding in Java? (Listeners, boxes, windows, buttons, text entry fields, etc?) Is the GUI API built into EVC++ (assuming there exsists one) really slick, like can someone write code to display dials and gauges aka LabView (Ok, I admit I'm probably asking for a lot here!!). What sort of support is avail "out there" from open-source developers working on similar projects?
3. Assuming: (a) that I've acquired a PocketPC enabled w/ Bluetooth, (b) I've sucessfully coded an app complete w/ GUI and appropriate interfacing to the right APIs for Bluetooth communication, (c) my uC has a Bluetooth module added onto it, and (d) I have implemented code in my uC that can read, parse, and send code using the Bluetooth module, what else will I need to make this setup work?
Has anyone done a project like this?
I realize this might be a lot to be asking to replace something as simple as "Hyperterminal" and the ole' keyboard. The more features and capability I can get my hands on, the easier it will be to test, program, debug, calibrate, etc my robot in the field (or when I go home for Christmas).
An idea presented to me was to implement a display/input device using Bluetooth coupled with a Pocket PC. I'm somewhat new to Extended Visual C++ (EVC++), how long will it take for someone with modest knowledge in OO (read: Java) to come up to speed?
My initial thoughts on implementing bluetooth (correct me if I'm wrong) are:
1. To keep the concept portable, I'd want to run my "terminal" and other custom apps from a PocketPC or similar device. Doing some quick searching I find that the latest PocketPCs run Windows CE ver 5.0. The download site for EVC++ claims it is written for Windows Mobile 2003. Do you think I'll be able to write apps using EVC++ 4.0 and make them run on a target running CE 5.0?
2. On the subj of custom apps: is it incredibly difficult to code a GUI that has features much like that found when coding in Java? (Listeners, boxes, windows, buttons, text entry fields, etc?) Is the GUI API built into EVC++ (assuming there exsists one) really slick, like can someone write code to display dials and gauges aka LabView (Ok, I admit I'm probably asking for a lot here!!). What sort of support is avail "out there" from open-source developers working on similar projects?
3. Assuming: (a) that I've acquired a PocketPC enabled w/ Bluetooth, (b) I've sucessfully coded an app complete w/ GUI and appropriate interfacing to the right APIs for Bluetooth communication, (c) my uC has a Bluetooth module added onto it, and (d) I have implemented code in my uC that can read, parse, and send code using the Bluetooth module, what else will I need to make this setup work?
Has anyone done a project like this?
I realize this might be a lot to be asking to replace something as simple as "Hyperterminal" and the ole' keyboard. The more features and capability I can get my hands on, the easier it will be to test, program, debug, calibrate, etc my robot in the field (or when I go home for Christmas).
