---------- > From: James Cameron > To: PICLIST@MITVMA.MIT.EDU > Subject: [Q] 16F84 Ultimeter 100 Wind Speed Recording > Date: Thursday, June 11, 1998 5:51 AM > > I'm checking the feasibility of a task and I'd appreciate comments on > how to implement it. > > I will shortly have a weather monitoring instrument, an Ultimeter 100, > which will provide a 2400 baud data stream containing a wind speed value > calibrated in 0.1kph notches. The specifications say that it > will be in the form of four ASCII hex bytes; e.g. 30 30 31 30 should > mean 1.0kph. The samples will arrive at 1.5Hz. > > I want to accumulate a histogram in a 16F84's 64 byte EEPROM that > represents the number of samples received from the instrument at each of > 17 notches calibrated in metres per second. Each notch should be three > bytes wide, to allow 2^24 counts per notch. > > Looking at this from a software engineering standpoint, I'll need > the following bits of code, which I haven't yet done in PIC, hence the > question ... > > - receive those four bytes and hold them as a number that > will range from 0 to about 700 (site isn't very windy), > > - divide that number by 36 to get metres per second, > Why bother dividing by 36? What you really want is 17 notches, right? So, let's say that one of these notches is at 0123, and the next is at 0258 (just so's we got something concrete to talk about here...) You compare the value you just received against each of the notch values. Once you find a notch set that is HIGHER than your current value, you know you have actually got the PREVIOUS notch value. Update the appropriate 24 bit counter/ram. Use your RAM, not your EEPROM, as you will soon kill the EEPROM by excessive writes! Do you need a 24 bit counter for each, or will 20 bits do? You can store 20 bits in 2.5 bytes. Yep, you heard right, 2.5 bytes. ODD counters would be stored 1-1-.5, and EVEN counters would be stored as .5-1-1. Thus every TWO 20 bit counter set would use 5 bytes. You could get all 17 notches stored in 43 bytes. Each 20 bit counter can contain a number between 0 and 1,048,575. Need 21 bits per counter? No problem. You store the first 20 bits as mentioned above. When the result of your incrementing the 20 bit counter causes a carry out, then set a single bit of a "21st" bit register that is 17 bits wide. Yep, this makes the programming a bit more interesting and difficult, but it allows you to maximize how many large counters you can store in system RAM. If you can get by with 16 notches instead of 17, then you can simplify things even further. You can use "vertical" registers. Their use was mentioned on this list recently in another context. The concept is quite simple. Let's assume you want sixteen 21 bit counters in RAM. We can do that in exactly 42 registers. We ORGANIZE them vertically instead of horizontally. That is, Counter NOTCH1 through Counter Notch8 would ALL keep BIT 1 in Register NotchBit1A, and Counter Notch9 through Counter Notch16 would ALL keep their BIT 1 in Register NotchBit1B. Within the NotchBit1A Notch1 would go at Bit 1 position, Notch2 at Bit 2 position, etc. (I am here numbering starting with 1 instead of zero... you get the idea, hopefully). The technique is especially useful when the number of bits is a multiple of 8 and the number of counters is NOT a multiple of 8. This really cuts down on wasted register bits! Incrementing a vertical register is very easy. Go to the first bit position. Replace it with its complement. If the new bit is a one, then you are ALL DONE. (Really!) If the new bit is a zero, then move to the next bit register and do the same. Anytime you end up with a 1, you is DONE! Anytime you end up with a zero, move to the next bit register (same bit position within the register) and continue. Obviously you stop when you reach the last register. The process is easy to automate, especially if you use the FSR register and indirect addressing. It helps if vertical registers are physically in order, as this facilitates moving from bit register to bit register. Use one register to keep track of which bit position is being acted upon. Even if you decide not to use any of these admittedly weird techniques for this particular project, file the idea away... there may come a time when you will HAVE to use such a technique to squeeze that maximim out of your PIC (or other microprocessor). Also, all you bit boffers out there, if you are using something like a 7 bit register, remember that you can always use that extra bit somewhere else in your program. Neophytes often waste many bits because they choose inefficient storage systems or inefficient ways of representing data. For example, although we often use packed BCD for storing decimal numbers, the maximum storage efficiency is gained by storing the number in pure binary. Of course you do have the overhead of eventually converting it for output. If you have your PIC communicating with a PC and you are also writing the program for the PC, then let the PIC store and even transmit its data in the most compact form possible. Then send it to the PC and let the PC do the dumb old conversions. Sometimes we forget that the PIC is often communicating with a machine that has more resources and computing power than the PIC. Hope this helps. Fr. Tom McGahee > - increment a specific 24 bit counter in EEPROM. > > Hmm. > Hold the number in BCD and do the division in BCD? > Use a lookup table to do the division? > Anyone done anything similar? > Is fetching the EEPROM data via a programmer practical or do I > code a dump-to-serial function too? > > ps; I'm new to this list, but not lists in general. > > -- > James Cameron (james.cameron@digital.com) > Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800