Display motor RPM with large digits and graph on VGA demo
Peter Jakacki
Posts: 10,193
A few days ago I was playing with drawing large fonts on a VGA display. Well I used that to create a display for measuring RPM on a motor by attaching a small magnet to the shaft and positioning a sub-miniature reed switch next to it. A small PASM routine measures the interval and this is then processed and displayed on a VGA monitor. The RPM is presented with very large digits and a percentage of the relative range is displayed on a vertical bar graph as well as recorded on a strip chart.
Some parameter settings may be adjusted from a serial console and automatically saved into EEPROM.
If you find this useful then fine, but as this is setup for my hardware you may need to adjust the pin number for the tacho input while the VGA is on pins 16...23.
Some parameter settings may be adjusted from a serial console and automatically saved into EEPROM.
If you find this useful then fine, but as this is setup for my hardware you may need to adjust the pin number for the tacho input while the VGA is on pins 16...23.
800 x 459 - 179K
Comments
I am totally in lust with your strip chart recorder. Is that something you did yourself, or did you adapt that from something on the OBEX? Does that strip charter suck up a lot of cogs and memory or is that a fairly lean operation? Thanks for sharing this!
thank you for sharing this. I unzipped the archive and tried to compile it but it did not work
FDX, I2C and synth, VGA_512x384_Bitmap, have 0kB and are empty.
I copied them from other folders to the folder where I stored RPM_VGA-DIsplay and tried to compile
the compiler complaint about "expected a subroutine name at Synth.Hz(
This means I don't have a version of synth.spin that includes a method "Hz".
Something went wrong with the archive.
Can you please update the archive?
keep the questions coming
best regards
Stefan
Yes, that's why I allow certain parameters to be modified at runtime, such as the number of sensors etc. The medium sized DC motor I tested this on is geared down and I have an old panel knob screwed onto the shaft and a small 5mm supermagnet pushed into the knob's screw well, I'm testing out some micro-steppers at present so I can view the ramping profiles and performance with this setup as well (more magnets of course).
The strip recorder is fairly basic but does what I need it to do. Ideally I would have the recording "pen" down one end and scroll the whole graph just like a strip. However that takes too much time so I just move the "pen"
every working code that is published in the forum or the OBEX is welcome and I appreciate it.
To be not misunderstood I thank all contributors for sharing it and I'm always aware they all are doing it for free. So the others have to take the quality that is served as it is. Complaining about the quality of the code or the comments goes to far. Nethertheless I want not to complain but make a suggestion.
My former experience with most of the OBEX-code is, that it is hard to understand because of not selfexplaining labels and names and short comments.
I wanted to understand your PASM-code measuring the rpm.
For understanding it really - I changed the variable-names and added more comments on how it works.
Here it is and I would like to have your opinion if you would mind - before publishing code - to re-read the code and improve variable-names, labels to be selfexplaining and adding more comments to make it easy to understand for others (and yourself if you want to change the code after months)
Again this is just a suggestion and not a rough call for it.
DAT org MeasureRPM 'the SPIN-part executes cognew(@MeasureRPM,@interval) 'which means the register "par" contains HUB-RAM-adress of SPIN-variable "interval" mov ptr_Status, par 'store HUB-RAM-adress of variable "interval" add ptr_Status, #4 'add 4 to change to adress of variable "status" mov last_lo_hi, cnt 'initialise last_lo_hi with actual cnt-value rpmloop waitpeq rpmpin, rpmpin ' wait for lo hi transition mov act_lo_hi, cnt 'capture the cnt on the lo to hi transition 'PASM has nothing like a single-line command in SPIN tick_diff := act_lo_hi - last_lo_hi 'which is a command-line that has three variables in a single line 'PASM-commands have always only two "variables in a single line source and destination 'the calculation tick_diff := act_lo_hi - last_lo_hi 'must be divided into '1.) tick_diff := act_lo_hi '2.) tick_diff := tick_diff - last_lo_hi mov tick_diff, act_lo_hi 'equivalent to 1.) tick_diff := act_lo_hi sub tick_diff, last_lo_hi 'equivalent to 2.) tick_diff := tick_diff - last_lo_hi mov last_lo_hi, act_lo_hi 'after calculating tick_diff - "act_lo_hi" becomes "last_lo_hi" wrlong tick_diff, par 'update HUB-RAM variable "interval" waitpne rpmpin, rpmpin 'wait for next hi to lo transition wrlong update, ptr_Status 'update HUB-RAM variable "status" jmp #rpmloop rpmpin long |< sensor update long -1 last_lo_hi res 1 act_lo_hi res 1 tick_diff res 1 ptr_Status res 1best regardsStefan
You have to understand that this code was released "as is" and not necessarily vying for status as OBEX worthy as it is more of a quick hack. If I waited until I cleaned up the code and commented it all then I probably would never get around to releasing it, which is kind of what always happens. Of course if there is some interest I could repackage it in a form suitable for the OBEX along with refined symbol names and comments. But I find a lot comments tend to IMO clutter the code and it is much easier to read code that has well chosen symbol names and good factoring (for starters). Comments that outline the purpose and rationale of a section of code I find are far more helpful than the minute step by step comments.
But I appreciate that we all think differently and have different levels and areas of experience and this has to be taken into account. At the same time each author should also still be free to express their work from their viewpoint, a bit like each artist will render a scene differently from one another but still recognizable.
Now, to get back to your other question. The PASM routine for the RPM is a very basic capture count on active edge and subtract that from the count at the next active edge, that's all. I felt I "over commented" some of the code. For teaching purposes I would write the code a little differently (and less optimally) to reveal the flow a little clearer rather than over comment.
Here's a slightly more commented version of that code from my point of view.
MeasureRPM mov ar0,par ' par points to first parameter (interval) add ar0,#4 ' ar0 points to second parameter (status) mov r0,cnt ' initial latch of counter (r0) - not synchronized!! ' so the first reading will not be correct (not important) rpmloop waitpeq rpmpin,rpmpin ' wait for hi (loop while lo) mov r1,cnt ' capture the cnt on each lo to hi mov r2,r1 ' make a copy in r2 for later sub r1,r0 ' calculate time diff from last lo to hi (r0) mov r0,r2 ' and remember the cnt at this instance for next calculation wrlong r1,par ' update the interval variable in hub RAM waitpne rpmpin,rpmpin ' wait for lo wrlong update,ar0 ' new reading, set update status ' (this instruction does not necessarily need to be here) jmp #rpmloop rpmpin long |<sensor ' the pin which we are measuring update long -1 ' some constant to set update status, in this case TRUE r0 res 1 ' temp registers r1 res 1 r2 res 1 ar0 res 1Often, we just test a piece of code to see if it works. We may then use that as a basis for something else, that may or may not be divulged.
Comment requirements vary according to the skill of the programmer. For example, I often use short names which actually have no meaning, except to myself. This has come about for many reasons. I started programming in 1971, and commercially in 1974, micros in 1976. In those days, memory was tight, the assemblers were limited to 6 characters, etc, etc. Many programmers use i and j for integers which is a carry over from basic. Remember, basic only had line numbers initially, and they were not even optional.
What beginners require is lots of comments which are really self-explanitary to experienced programmers, who call these comments clutter because they hide what is happening. We can understand a block of code simply by a single comment line at the beginning of the block.
We are also often lazy. We don't like having to type lots of characters, hence a lack of comments and shortened labels. VB (Visual Basic) went to the other extreme with long fancy labels separated by underscores.
Just my point of view and not said to start a war.