Searching \ for 'User interface for PIC model aricraft controller' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'User interface for PIC model aricraft controller'.

Truncated match.
PICList Thread
'User interface for PIC model aricraft controller'
2000\05\16@165915 by Rock Thompson

picon face
I've nearly finished a remote control in which a PIC
monitors pots manipulated by a user, does the AD
conversions and mixes the inputs as the user has
programmed.  This mix is then transmitted to an
aircraft or other vehicle.

The most difficult aspect is proving to be coming up
with an easy-to-use user interface. At the moment I'm
reprogramming the PIC everytime I want to make an
adjustment - this is a very effective form of torture.
I would be very appreciative to learn what others
have done when needing extensive user input.

The particulars are:
The user interface must allow assigning various
controls to different channels on the aircraft. The
effect of the control must also be specified, such as
direction and travel distance. The interface needs to
show a field to fill out and then check to be sure the
input number is within range.

An Excel spreadsheet or simple database program with
simple programming would be fine, but my application
needs to be portable for field use and the cost must
be low (less than a lap top computer).

I see three possibilities:
1) Use a big (40x4) charactor LCD or one of the
graphic LCDs, install the needed key switches and have
the PIC, or its slave, do everything.

2) Have a Palm (or the new Visor) PDA be the
interface, communicating the user input to the PIC and
receiving current status from the PIC and displaying
it.

3) I just thought if this. What about a graphing
calculator, such as the HP-49G?  It has a serial
interface, can be programmed in several languages and
would allow graphing of the control functions, which
would be nice. These calculators are supposed to have
advanced list handling abilities - would this be
practical?

All three solutions cost about the same. Any opinions
or better ideas?  Thanks!

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

2000\05\16@171533 by Quitt, Walter

flavicon
face
On completely embedded devices we typically write a front
end and down load new stuff.

On stuff with and LCD we do the above and add similiar
functions to the keypad and LCD.  Just that this code
takes up a LOT of code.  One new product has 14K lines
of PIC code.  Over half is the UI.  :( :(

I like the download feature of serial.
The LCD and keypad are good because you don't have
to have an external device.
All our stuff uses a similar protocol so changing
our VisulBasic Userinterfaces is easy enough.
It is ASCII so you can even use a terminal to
talk to a device.

Using some PDA like device would be real slick.

Oh ya, we use serial EE Proms to store our "screens"
for the LCD.

GL,
Walt...

{Original Message removed}

2000\05\16@175708 by l.allen

picon face
Rock Wrote

>  I would be very appreciative to learn what others
> have done when needing extensive user input.
>

For a DDS based system with frequencies assigned to
keys, we used a separate hand held unit that the
frequencies were entered into, viewed on an LCD and
loaded onto an 8 pin EEPROM.
This IC was then plugged into the DDS unit and this was
read at power up by the unit and new freq's were
assigned to the keys.
This also had the advantage that the field research unit
(the target application) was NOT programmable and
removed one more idiot factor.
A power switch and 10 keys, one for each freq was more
than enough trouble.

If there was a screw up, the old IC was put back in and it
worked again.


_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\05\16@182217 by Don Hyde

flavicon
face
I'd go for the Palm.  I've been doing a little programming on one for a
project, and it's not too bad, if you have ever programmed a GUI, especially
if you're experience is with a Mac.  The Metrowerks tools are, if you can
believe it, much buggier than MPLAB, but usable in between crashes, just as
MPLAB is.

There is a serial port, and software to support it, which is not too
horrible to figure out (easier than Windoze, for instance).

You could do yourself a really cute GUI, with little sliders and all sorts
of stuff.

> {Original Message removed}

2000\05\16@210935 by Scott Dattalo

face
flavicon
face
On Tue, 16 May 2000, Don Hyde wrote:

> I'd go for the Palm.  I've been doing a little programming on one for a
> project, and it's not too bad, if you have ever programmed a GUI, especially
> if you're experience is with a Mac.  The Metrowerks tools are, if you can
> believe it, much buggier than MPLAB, but usable in between crashes, just as
> MPLAB is.

And to carry the analogy a little further (although MPLAB has seldom crashed on
me)... just as there are a full suite of developement tools under Linux for
PICs, there are also a full suite of development tools for the Palm under
Linux. I guess the only difference is that the Palm tools have been ported to
windows too (but the pic ones haven't).

Scott

2000\05\17@071133 by Andrew Kunz

flavicon
face
Use an interface similar to the one in the Futaba 3PDF.  The transmitter I
developed for FMA Direct used the same concept (before Futaba shipped it).

It was a PIC-based device, used serial EEPROM for messages, mixing parameters,
and state machine (permitting multi-lingual setup).  I had 20 channels which
were mixed down to 8.  It counted trims as channels at a low level, but the user
never knew the difference.

Andy

2000\05\18@012159 by Don Hyde

flavicon
face
Actually there are two different toolsets.  I have experience only with the
Metrowerks tools, which are supported by Palm, Inc.  That toolset was
originally written for the Mac, and ported to Windoze.  Supposedly, many of
the crashes are due to the port from the Mac, though on the Palm developer's
list, I see plenty of complaints from Mac-using developers.

The other toolset is GNU-based, and native to *nix, and (I think) ported to
Windoze.  I don't know much about it, though it is supposed to be fairly
good and is free.

I had a project deadline and didn't have much time to shop around, so I
chose the commercial, vendor-supported set in order to get to work as
quickly as possible.  I suspect that I was right in that Metrowerks comes
with an installer that takes care of that particular set of hassles with
Windoze.  I see quite a few questions about installing the other set.

In either case, there is an emulator that works amazingly well.  You get a
Palm on your PC screen (you can choose 'skins' for various Palm models), and
it actually runs your programs -- in fact you have to download the actual OS
ROMs from a real Palm (or from the Palm website) into it before it will run
anything.  On my 350 MHz Pentium, it's almost as fast as a real (16 MHz, I
think) Palm.  The serial and IR ports are even well simulated with PC ports!
It is absolutely in another league from MPSIM.

> {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...