Propeller PDA.....thoughts

Ravenkallen

I am starting to construct a Propeller PDA( Propeller digital assistant, haha). It will use two 64 Kilobyte EEPROM's(One for the boot menu/ BIOS and the other will store the program booted up from the uSD). Both EEPROM's will have the same data/ clock lines and a dip switch that controls power to the EEPROM's. Upon power up (with the first switch on), the system will boot the main control program, which will include a very basic function that will check the whole system for integrity, a function that will allow boot up parameters to be changed( A BIOS setup utility of sorts), and finally a menu that will allow you to do things like, boot up another program, change preferences, reboot the system, check the system for a file...ect. If you chose to run another program, you will simply turn the first switch off and then turn the second one on. You will then type in the name of the file and it will load it into the second EEPROM and then finally, reboot the system...

It will(of course) have a uSD card for storage of data and programs. It will have a PS/2 keyboard input and a 6 button chording keyboard(for portability). It will use a 128x64 graphic lcd( Which uses a sparkfun serial graphic backpack) for it's main display. Because the display uses 6-7 volts i was thinking about using a 9 volt battery(or maybe two), but its low current capacity would make the device use them up fast...

I have the basic hardware setup and am working on the software now. The main programs to be included would be things like, a word processor, a journal, a calculator, maybe a clock(it would need a better power source then), a calender, some games(I am working on a low res side scrolling shooter game), a small programing environment(using a language that i creating) and a few other like features. It's main benefit is portability and ease of use.....Thoughts?


Update: 9/14/10 Here is a picture of the finished propeller PDA protoypte. There are a few changes... Most of the hardware is now hooked up to pins 0-7, so i will change the software to adjust for these changes.... The main software is almost ready for beta test. I just need to make the loading of programs a little faster(Right now it takes like 3 minutes to load a program) i should cut the time down to 45 seconds...

Update 9/23/10 AHHH!!! the beta program is ready for testers. The pdaboot - archive file has all of the necessary objects to get the main program working. It is not commented and any suggestions will be greatly appreciated. You can also change the pin numbers if you like, but i must warn you, future programs will be made using the original scheme...The file sample1.txt is a program that you put on your SD card. Just save it directly to the SD card. It will simply blink a led on and off on prop pin 11...When you are in the main menu press "p" to run a program. Then type in the name(in this case sample1.txt) then press enter. Watch as a number on the screen increments. Once it reaches 32,000 the system will reboot and the new program will load....MAKE SURE to toggle the power switches for the EEPROMS. You don't want to overwrite the main one by accident...This is VERY basic. It is still a work in progress cut me a little slack. The BIOS block of code will be expanded in future versions to allow more customization....ANY Comments? any at all?

Update 10/6/10...
The new display standard will be the 4D systems uOLED-96-G1. I have chosen this display due to cost and ease of use. I am developing a driver for it.
I have also added a percentage system that will indicate the program's loading progress...
I am working on the system's first real "APP"
I am working on support for a new Chording keyboard. The system will support both the chord keyboard and PS/2 keyboard at the same time..
Due to the new display, power requirements will be lowered to about 4 volts, enabling truer portability.


Update 11/6/10...
Well, i am working on a few major upgrades...First off is the increased speed of the loader
The program loader(aka, main control program/ OS) is capable of booting up programs from external memory...FAST
it loads a 32 kilobyte program in a few seconds...
I have finished the OLED driver and the OLED seems to be playing nice with the Prop...
The new standard for human input is a mini ps/2 keyboard(and when i say small i mean small)..

The menu interface is slightly more streamlined. I am adding a function that will enable the user to check the uSD card for program
files then simply type the appropriate number and it will launch it(that is cool because you will not need to remember the name of a program because the system will search the uSD automatically and look for programs)...
The percentage indicator is redundant due to the high speed of the loader...
I am still searching for a good battery... I am thinking rechargeable AA's or AAA's


Here is a link to the new keyboard...I really like it

http://cgi.ebay.com/SUPER-MINI-SIZE-USB-PS2-SLIM-KEYBOARD-W-7-HOT-KEYS-2-/320528390857?pt=PCA_Mice_Trackballs&hash=item4aa0fb1ac9

Duane Degn

I'd also be hesitant about using 9V batteries. I think your PDA would burn them up too fast.

Two LiPos in serial would be around 7.4V. There are lots of different sizes of LiPos so you should be able to find a set (you might need to lay them side by side instead of stacked on top of each other) that would fit you enclosure.

Do you have a menu program? I've been working on a menu program for Rayman's Propeller Touchscreen Platform (PTP). I posted my recent attempt in the thread "Trying to understand using colors!"

I like the idea of having complete control over a PDA and the ability to easily write my own programs for it.

I think some of the database programs would take a bit of work to get them to work with a Prop. How far out to have calendar item?

I'd be very interested in seeing what you come up with.

Duane

jazzed

I've also been thinking about a PDA-like device in the background. Using an LCD with graphic RAM built-in is attractive to move the graphic buffer out of the Propeller. That would not be too compatible with current Propeller games, but I'm more interested in a rich graphic interface than retro games anyway. There are some 3" or so LCDs which have the graphic RAM option and I have a sample coming tomorrow - it's expensive one at a time, but it provides a number of interface types. I'm attracted to the SPI interface because I always run out of pins No idea if I'll be able to stand the update speed though ... we'll see.

HollyMinkowski

I really love the Propeller but
I would use an ARM uC running Linux for
something like this.

Here is a suitable board design.
http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm

Using Linux means the software you need
will all be available for free. You would not
have to do much coding at all to get a PDA
up and running.

You could also place a sm Prop onto an ARM
board and use it for custom tasks...best of
everything that way.

Heater.

Holly:" professionals find ways to consistently create high-quality software on time and on budget."

You know, I'm not totally convinced that is true.

HollyMinkowski

Heater

I always try really hard to come in on or below
budget and get the job done ahead of schedule.
I failed a few times but lately I'm not doing too
bad. I hate when I get almost finished on the code
and they ask for some new features !@#$%

I code alone, I can't get anything done working
in a group. On my current project I write the code
and 4 people inspect my code looking for errors.
This is working out really well, it's sort of like working
in a group but better because I'm coding alone
and meet with the group every day to discuss what
they might have found that needs more attention.

This code has to be bug free because if it fails
the result can be injury or even worse. You can
break out in a cold sweat just thinking about what
the result of a serious bug could be. The cost per
line of code has to be pretty high for this project
but cost is secondary in this case to quality and
meeting the deadline.

Humanoido

Ravenkallen wrote: »

I am starting to construct a Propeller PDA

Ravenkallen, I like your ideas for this project and think it's very useful and worthwhile doing. I think there would be a lot of uses for it especially if the screen font size is big enough to see over cel phones. I like the idea of the word processor and a small keyboard with large keys. You could have some hobby extras on it, like a special pin expansion port, with some LEDs already on it for programmers. For programmers, this would be sensational to have a portable prop computer in a coat-pocket and work with it anywhere. Use SPIN programming with some PASM if necessary so it will be understandable and modifiable. I can see it having great potential and utility and numerous wonderful applications with great spinoff technology. Do you have a pic showing the hardware so far?

Humanoido

Ravenkallen

Thanks all for the feedback

@Duane....Yeah, i thought 9 volts might be a bad idea. Especially seeing as the LCD can pull 220 mA's at full backlit duty cycle. are these LIPO batteries expensive?
uh. for some of the other questions. The calendar would probably be one of the last features i would implement. And for a menu system. I have a menu system that eliminates all recursive calling. so the stack should be very small. i can show you a small demo of it if you would like...

@Jazzed....Uh the LCD i am using is going to be a monochrome lcd, so the graphics are not going to be that good...But the display does have its own RAM so i will not need a internal display buffer


@Humanido...The programming environment that i am creating would include a very simple, almost cryptic language and it would be stored on the SD card. If the program was run, it would load it from the SD into the hub ram and run it from there. I did a basic speed test on a similar program and i don't thnk that 4,000 instructions per second is unreasonable. I will upload a pic today sometime


Thanks guys

Ravenkallen

Here is a pic of the basic breadboard setup. I will eventually hop to fit it all on this protoboard
http://www.mouser.com/Search/include/LargeProductImage.aspx?path=busboardprototypesystems/lrg/BPS-IMG-BR1.jpg

Duane Degn

@Ravenkallen, LiPos aren't nearly as expensive as they were a few years ago. Someone on the forum suggested HobbyKing.com. I have an order in for a couple of helicopter batteries. The smaller sized packs are around $10. The have lots of choices so you could find a pack size in you'd like.

They require special chargers but there is a chip made exclusively for charging LiPos (only one cell at a time though).

You said . . .

I have a menu system that eliminates all recursive calling.

Is this what you mean by recursive calling?
(You can skip the code an see my English discription of "recursive calling" under it.)

 
PUB Init
 
  {Setup variables etc.}
  repeat
    MainMenu
 
PUB MainMenu | localChoice
 
  Print(Menu Item 1)
  Print(Menu Item 2)
  Print(Menu Item 3)
 
  case localChoice
    menu1:
      Menu1Method
    menu2:
      Menu2Method
    menu3:
      Menu3Method
 
PUB Menu1Method | localChoice
 
  Print(SubMenu Item 1A)
  Print(SubMenu Item 1B)
  Print(SubMenu Item 1B)
 
  case localChoice
    menu1:
      Menu1AMethod
    menu2:
      Menu1BMethod
    menu3:
      Menu1CMethod
 
PUB Menu1AMethod
 
  {Do something basesd on choice of sub menu A of menu 1.} 
 
PUB Menu1BMethod
 
  {Do something basesd on choice of sub menu B of menu 1.} 
 
  {Continue with Menu 1 sub menus and Menu 2 and Menu3 }
  {with all of their submenus.}
 

Where each menu calls its own submenus? Which means the program can easily be several methods deep.

Is this non-recursive?
(Again you can skip the code and read my discription under it.)

CON
  {Give each of these constants a unique number starting with zero.}
  #0 _ChoiceMain, _Choice1, _Choice2, {
  }  _Choice3, _Choice1A, _Choice1B, {
  }  _Choice1C, _Choice2A, _Choice2B, {
  }  _Choice2C, _Choice3A, _Choice3B, {
  }  _Choice3C 
 
PUB Init | localChoice 
 
  {Setup variables etc.}
  localChoice := _ChoiceMain  {Start out at main menu}
  repeat
  {All menu methods return here}
    case localChoice
      _ChoiceMain:
        localChoice := MainMenu
      _Choice1:
        localChoice := Menu1Method
      _Choice2:
        localChoice := Menu2Method
      _Choice3:
        localChoice := Menu3Method
      _Choice1A:
        localChoice := Menu1AMethod
      _Choice1B:
        localChoice := Menu1BMethod
      _Choice1C:
        localChoice := Menu1CMethod
      _Choice2A:
        localChoice := Menu2AMethod
      _Choice2B:
        localChoice := Menu2Method
      _Choice2C:
        localChoice := Menu2CMethod
      _Choice3A:
        localChoice := Menu3AMethod
      _Choice3B:
        localChoice := Menu3BMethod
      _Choice3C:
        localChoice := Menu3CMethod
 
PUB MainMenu | localChoice
 
  Print(Menu Item 1)
  Print(Menu Item 2)
  Print(Menu Item 3)
  { user makes choice resulting in localChoice being set equal to }
  {one of these: _Choice1, _Choice2, _Choice3} 
  case localChoice
    menu1:
      return _Choice1
    menu2:
      return _Choice2 
    menu3:
      return _Choice3 
 
PUB Menu1Method | localChoice
 
  Print(SubMenu Item 1A)
  Print(SubMenu Item 1B)
  Print(SubMenu Item 1B)
  { user makes choice resulting in localChoice being set equal to }
  {one of these: _Choice1A, _Choice1B, _Choice1C} 
 
  return localChoice
 
{similar methods for Menu2Method  and Menu2Method } 
 
PUB Menu1AMethod
 
  {Do something based on choice of sub menu A of menu 1.} 
 
  return _Choice1 {go back to menu1 when done with submenu}
 
PUB Menu1BMethod
 
  {Do something based on choice of sub menu B of menu 1.}
 
  return _Choice1 {go back to menu1 when done with submenu} 
 
{Continue with Menu 1 sub menus and sub menus for Menu2 and Menu3.}
 

Where all menus and submenus are called from one method. Instead of a menu method calling the method holding the submenu directly if returns to the top method with the instruction to call the submenu method.

The link I gave earlier in this thread has my attempt at "non recursive" menus. I would like to see an example of how you do it.

I'm not totally pleased with my program. What I really need are pointers to methods. I don't think Spin has such a thing. I remember reading about pointers to subroutines (is that what they are called in C?) and wondering why anyone would ever want such a thing. Now that I could use them they're not available (are they?).

In my menu program I have a data structure holding the location of the menu button, its color, the action it triggers and its text. I think it's pretty neat myself. I also keep the list of all the buttons in each menu in the DAT section. I find it makes changing menus around a lot easier.

As I mentioned previously (at least I think I did), I'm using Rayman's PTP with his 3.5" touchscreen. I'm trying to make an input device for my lab data gathering equipment. I think it's a little too big to use as a PDA.

I'm sure Holly is right about other platforms being better matches for PDA hardware but I don't want to learn how to program other chips. I've spent a lot of time learning the Propeller and if making a PDA required a different chip, I wouldn't be interested in it. I am interested in a Propeller PDA.

Duane Degn

@Ravenkallen, You posted as I was still writting my long post.

I think space will be a premium in a PDA. You might want to consider surface mount. I've used this board many times. By slicing the pads on the back in half, I can use a SOIC EEPROM and keep the whole thing small.

Duane

Leon

FWIW, my old Palm Zire 31 PDA used a 200 MHz Intel Xscale chip (ARM v5TE core). My current "PDA" uses a 1 GHz Qualcomm Snapdragon chip which includes an ARM core and a DSP.

localroger

One of the reasons I recently bought out mctrivia's remaining stock of propmod-us modules was for a project like this. When using batteries you absolutely need to use buck-boost power supplies to convert voltages, as conventional regulators turn expensive battery life into heat.

I am actually looking at a couple of projects, one long-term which has shifted gears several times involving the regutting of a NEC PC8201A (Tandy Model 100 clone from back in the day); the other I recently thought of when I got the propmod-us's with the bonus touch display and driver. Both will probably be awhile coming because I only have time to work on them intermittently, though :-(

Sigma X

this is an interesting project I really hope that this is open source

Ravenkallen

@Daune... The menu system is like the one last you described. Every method gets returned back to the original method which calls all of them. This seemed like the simplest way and it works, so that is good....now, about the boards. I am not to good at surface mount soldering, so i don't think i will try it yet... The protoboard is perfect for my application. I hope to fit it all on and cut off any extra that is not needed. I mean a PDA is something that will fit in your pocket, right? This should fit in your pocket(Or cargo shorts, haha). it should be a little bigger than a PSP, but smaller than a netbook. For power i am thinking a DC power jack and maybe 5 AA rechargeable batteries wired in series to produce 5x 1.2 volts(6 volts)....I might be going to radio shack tonight to pick up some stuff for my robot, but i will keep a eye out for LIPO cells to.....

@Local roger. I would need a pretty hefty(and expensive) converter. It would need to be able to supply at least 500mA's.

@All... i might make a basic schematic when i get some time

Sigma X

@Ravenkallen why not go to www.4dsystems.com.au
i'm sure they would have a good selection of screens there to choose from

Dr_Acula

Re power supplies, I'm a big fan of the LM2574 simple switcher. $1.70 from futurlec, up to 500mA (5 pin T0220, or DIP8. I tend to buy the TO220 for 5V and DIP8 for 3V so I don't get confused). Runs about body temperature running a propeller, sd card, vga display and LCD with backlight. Re the LCD with backlight, I'm using a 1k resistor so that would only be about 20mA and it seems plenty bright enough inside. Maybe not outside in the sun, but then you probably don't need the backlight outdoors anyway.

Switchers don't really care what input volts you use (within reason!). The only catch is the inductor is a little hard to find - 330uH at 500mA. I got a whole lot for $2 each and they are about the same size as the DIP8 chip.

localroger

RavenKallen, the PropMod PS can supply 750 mA of 3v3 to external circuitry. When buck-boost supplies are built with mosfets they can be incredibly small too because the low voltage drops mean they don't dissipate a lot of power or need heat sinks. It's so well built I am planning to feed the 3v3 from the PropMod to the input of a bodhilabs 5V converter (which only does up, not down conversion) since I might want to power the whole thing from a 4 cell 6 vdc pack.

Ravenkallen

@sigma x... I could use a color OLED display, but i don't have a bunch of money to spend right now. This system is going to be made on the cheap so that others(and myself) can easily construct their own....Perhaps i might add one in the future or you could develop your own that uses the same software, but has an OLED for a display.


@Dr_acula/ Local roger.... I feel kinda of sheepish but, I have never even heard of a "switcher". I thought you guys were talking about DC to DC converters. Does a switcher do the same thing? I am going to go look it up on google, haha

Sigma X

well hey while we're talking about powersupplies can a LM2574 power a propeller smt version because I was attempting a modular attachment system
but keeping on topic Ravenkallen the supplies are fairly cheap ... atleast I think so

Ravenkallen

Update:

The beta release of the main program should be ready in a few days. I will also release a small program that can be launched from the SD card... For hardware, you will need...

A keyboard on prop pins 6 and 5, pulled up by resistors...

2 64KB EEPROMs on pin 29(For data) and pin 28 (for clock). This is the same hookup as the normal boot EEPROM. I have pullups on both lines. You will need to have a switch on each one of the positive power lines. so when the first switch is on, the main program will boot. Then, once you want to load another program, you simply turn off the first switch and turn on the second( Which is connected to the second EEPROM). After the data is transferred from the SD card to the second EEPROM, the whole system will reboot and load up the new program. Although this method uses 2 EEPROMs, it will keep the main program safe....

You will need a SD card on Prop pins 0(DO), 1(CLK), 2(DI) and 3(CS). I didn't use any pullups and it has worked fine(so far)

And lastly, you will need the Sparkfun 128x64 display on Prop pin 4. If you want to modify the code to work on Parallax Serial terminal you could(Put i guess that would kinda defeat the whole purpose of it being portable).....

And this project is completely open source, so feel free to modify it to your liking.....

Ravenkallen

Check out the first post!!

mpark

I'm intrigued by the chord keyboard, but I don't see it in the picture. Do you have it working?

Ravenkallen

@ Mpark...I have a chord keyboard(That i made myself). I have yet to interface it with the Propeller PDA...I might make a seperate version of the software that uses such a keyboard instead of the ps/2 keyboard.

Ravenkallen

Check out the first post...

jaeg

This is a neat project. Have you thought about using rayman's touch screen? Kind of do something similar to the iTouch with the on screen display? The 4.3" screen is bigger than the itouch screen so a keyboard should be able to fit on it. I'm trying something like this combined with a simplified Windows 1.0 style gui for my propheld project.

Ravenkallen

Hey, Jaeg...I am actually in the middle of a massive modification of it. I am working on a new concept/ future product, that involves the OLED-96-G1, 1 64KB EEPROM, Chording keyboard and uSD support...It will mainly be used as a miniature programming environment, meaning that one can literately bring it anywhere and program it in system, without a PC. It will also include a full tutorial that can be accessed in system and displayed...It will use a new programming langauge that i am designing called HOLL-E, or Highly Objective Learning Language for Electronics. It will emphasize a bunch of preset commands(like flashing a LED on and OFF using one line of code)...

jaeg

That sounds like a neat idea. Will you be storing the on-the-go code on the sd? Kind of writing your own interpreter and pulling the code off the card as needed. Or are you tokenizing it somehow and loading it into the top half of the 64k EEPROM?

If you can get a good speed pulling the instructions off the card as you need them your programs could be larger. Make a simple command set for the graphics set for displaying the results like an old Commodore 64 or TI-99/4A. The only issue with pulling straight from the card (besides possible speed problems) would probably be making some sort of variable system it wouldn't be very practical to keep writing a variable to the sd card and I don't think you can dynamically create variables in the Prop's code so it'll have to be a bunch of premade variables maybe a large array.

Yah I'm just rambling at this point...

Ravenkallen

@Jaeg...Glad you asked...The initial system will use the internal ram of the Prop for program space and ram needed for the program. I hope to have 4 kilobytes of program space and 1 kilobyte of ram...While this might not seem like a whole lot, the language i am creating is going to be very high level( using only one line of code to flash and LED and one line of code to read the temperature from a thermistor) The language is going to be designed to be easy to pick up for a beginner, but will be appreciated by veteran programmers for its efficiency. I will include a lot of premade screen functions. I hope to really simply debugging, by using a optional graphical command that will display all of the variables in a easy to understand way...I hope the 32K of a Prop is enough to fit all of this. I will eventually port everything over to the C3(When it comes out)...The megabyte of flash will be especially useful.

jaeg

Sounds like a neat idea. I'll be sure to keep my eye on this project it sounds interesting.

Granz

Has anyone done any experimenting with hooking up an IPAQ LCD/Touchscreen to the Prop? I have a couple of IPAQs which are dead, but the screen and case are just fine.

It would be pretty cool if we could get a dead IPAQ from Ebay and resurrect it with a brain transplant :idea:.

Just think...
“I can’t hold her; she’s breaking up! She’s breaking—”
"Gentlemen, we can rebuild him. We have the technology. We have the capability to build the world's first bionic PDA. The PropPAQ will be that man; better than he was before. Better, stronger, faster."

Art