Out of variable space

Scott4

The mega-project I'm working on "Flight Instrument" has lots of variables and I am running·out of variable space... and that's just displaying the·data.··I am considering using the scratch pad memory in the BS2px or some other on-board RAM. The attached picture shows·the 2 LCD screens on the product. The lower screen cycles through the various data screens shown.

1. Are there good ways of handling these types of memory limitation·issues?
2. I'm thinking of storing the values as BCD to make outputting to the LCD easier any comment on this?
3. Anyone have a subroutine to convert a value to BCD?

-Scott

sam_sam_sam

Can you post· your code and leet what can be done

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any··that you may have and all of your time finding them

·
·
·
·
Sam

Mikerocontroller

Is this for Flight Simulator or general aviation? Just curious. Can you recycle any of your variables?

Scott4

I have an ultralight trike and am an electronics hobbiest. So... I thought what better than to combine the two. My "Flight Instrument" has:
·· BS2px
·· Micromega Floating Point Processor chip
·· 32k byte EEPROM
·· Two CrystalFontz 4x20 LCD displays
·· Two barometric pressure sensors (airspeed, altitude)
·· Polstar GPS module
·· Gravitech analog to digital converter (read joystick position)
·· Gravitech real time clock
·· Gravitech air temperature
·· Tachometer circuit
·· Gravitech joystick with pushbutton switch
·· Power supply

and a remote unit that has:
·· Two thermocouple chips for exhaust gas temperature
·· An analog to digital converter for reading the engine water temperature thermistor
·· Power supply

Mikerocontroller

You can always declare a set of general-purpose variables (bit, nib, byte, and word sized).
Being single-threaded the Stamp can only process one command at a time anyway. Are you using the -40 version? It looks like you will be processing 24 channels of data so, of course, hardware concerns will arise if you have the 16 I/O pin Stamp. From a software standpoint there is enough variable RAM storage for this project but some channels will have to share memory. The display headers and waypoint identifiers can be stored in EEPROM memory. Draw the headers once (or each time a new screen is requested) and just update the data windows. See if you get an acceptable update rate by processing each of the 24 channels in sequence. If the update is too slow maybe you can poll the TT, AIR or DATE channels( or any lower priority channel) less often. Can you provide a diagram of your planned system?· A bigger concern would be running out of pins or program space.

Post Edited (Mikerocontroller) : 1/28/2010 12:14:43 AM GMT

Scott4

The number of pins on the BS2px is not a problem as I am using both I2C and SPI busses to interface to the various chips.

I don't believe processing time will be a problem as I have run some pretty big programs on this BS2px and it has performed adequately. A lot of the number crunching like the Steinhart-Hart curve fit for the water temperature sensor and the NMEA string handling for the GPS will be handled by the math co-processor (which is much faster than even the BS2px as you know).

You are correct many of the data do not need to be computed in every cycle. Those I plan to store in scratch pad ram so the value is available for the next screen in rotation whether I recalculate it or not.·And yes, when I "GET" those values for display purposes, they do not need anything but generic names.

Thanks for your help, just needed some help getting off top-dead-center, I appreciate it. -Scott

Mikerocontroller

Scott, you're ahead of me on this one.· This would be a great project to follow. Please keep us posted on your project and· have fun with the ultralight.· You can try the HEX formatter if you are going to be dealing ·with displaying BCD on the LCD's since 0-9 in hex is the same as BCD.· You can convert decimal to BCD by dividing by different powers of 10 and assigning the results to nib variables.