Need Help with counting time between inputs
3snke
Posts: 7
in Propeller 1
I am trying to count the milliseconds between two inputs when their states change to calculate how fast my hot wheels are traveling. I looked through the libraries and found mstime which counts the duration of a cog while it’s running but I was unsuccessful at getting any returned values. I’m almost certain the code is wrong because I’m still a beginner and the libraries are usually lacking in examples which help me tremendously. Any input to mstimer.h or any other method for counting milliseconds is greatly appreciated.
2048 x 1536 - 409K
4032 x 3024 - 2M
Comments
This code measures the event time in system ticks and displays the result in 1/100ths milliseconds (10 microseconds). If you use optical sensors the output will probably be active-low which is how this code works. If your sensors are active-high you'll need to change waitpne to waitpeq. Timed events must be less than ~26 seconds, otherwise there will be a roll-over error with the CNT register.
/* Event timer -- measures milliseconds between falling edges of two sensors */ #include "simpletools.h" #define SENSOR_1 4 // active-low sensor inputs #define SENSOR_2 5 void main() { int et; while(1) { pause(3000); for(int i = 3; i > 0; i--) { printf("%d... ", i); pause(1000); } printf("Go!\n"); et = elapsed_ticks() / 800; printf("Event time: %d.%02d ms\n\n", et / 100, et % 100); } } // Return elapsed time between active-low sensors // -- units returned is in system ticks int elapsed_ticks() { int elapsed; waitpne(1 << SENSOR_1, 1 << SENSOR_1); // wait for input to drop elapsed = -CNT; // start timing waitpne(1 << SENSOR_2, 1 << SENSOR_2); elapsed += CNT - 144; // stop timing & remove overhead return elapsed; }Just like that. Give it a try. And I can read C code. Wonderful.
I do love the style you program in Spin, and I try to reach that goal with my own stuff, but I fail miserable.
It proves again that programming and style is independent of the language used and I wish I had the ability of you to separate meaningful subroutines and name them correctly. Does not happen here but in most of your objects I was bound to use, I was in awe about the structure and naming.
Some people know that programming is a art form, and in my opinion you are already a great artist. I know you want to be a actor, but - hell - why?
Sorry if I offended you, but gosh Jon, with all the stuff you did with props and controllers, didn't you figured out that that is where you belong? You should teach the art of programming, not trying to get more - hmm- screen time(?)
Please be not offended. I am a big fan of you.
Enjoy!
Mike
Tony Robbins once posed the question: What do you have to give up to have more?
The answer: Nothing!
I will agree with you, though, that good form/style is independent of language. Part of my charge at the new job is to teach our young staff how to code well. Language is irrelevant. We primarily use Python and C, but I have been showing the kids (as I call them) the wonders of the Propeller and a couple are jumping on.
I also get to do product development and was recently granted the funds to develop a product for the company. I'm using the Propeller. I'm also going to build an ICS demo device with a couple of the youngsters that uses the Propeller and modular IO over and I2C and SPI bus structure.
It's hard for people who are not actors to understand those of us who are. There is nothing at all logical about that choice. My coach and dear friend, the late Cliff Osmond, told actors that they literally had to be out of their minds to act. It was a double entendre . First, it's not a logical choice for an secure life. Second, by being out of our own mind, we can occupy the mind of character we are playing.
Few make it big, a few more make a living, most of us have other jobs. No matter where we are, we are driven to get on a stage or in front of a camera. While in Texas I had the opportunity to work with casting director Shari Rhodes ("Jaws"). She told a group of us that people are born to be actors and it's best that they pursue that profession -- regardless of outcome -- lest they become serial killers. She was being a bit jokey, of course, but with a point: we are happy pursuing our dreams. Enjoy the journey.
Those who look at my code can tell that I enjoy it. I try to do with with care, because most of the code I write will be viewed by others. That's the thing about source code: it's for humans. That said, I think we should be kind to the fellow humans who see our code by giving them something that is clean, concise, and appropriately documented.
Finally, I was able to write that little demo in a language I don't routinely use (but do routinely swear at) because I know the Propeller well. My message to those of you that are new to the Propeller is that learning to code in Spin -- even if you won't use it heavily later -- is valuable because it really helps you learn the hardware. Understanding the hardware is one of the keys to writing clean code.
"et = elapsed_ticks() / 800;
printf("Event time: %d.%02d ms\n\n", et / 100, et % 100);
"
elapsed += CNT - 144; // stop timing & remove overhead
"
is the 800 referring to the speed at which the propeller runs at? I was able to piece together how the code works but these three lines confuse me.
- Thanks
I'll just re-quote this one for emphasis. The importance of understanding the general functions in a CPU, how they go about accessing memory, fetching instructions, why registers exist, decoding and executing each instruction, one by one.
Programming languages become far more understandable once the hardware beneath is learnt.
The " - 144" is subtracting 144 ticks (1.8 microseconds) from the measured interval. This is done because that is the excess number of ticks in spin processing time required to acquire the interval measurement.
The two part " / 100" and " % 100" in the printf() is for presentation of what's called a fixed point number. In this case, treating it as milliseconds with two decimal places.
The waitxxx instructions are specific to the Propeller. This is part of my point about leaning the hardware well in order to write the most efficient code. You could, of course, use a loop to monitor a pin; but the waitxxx instructions simplify that and remove a lot of overhead (not all, though).
Using C the Propeller is forced to run at 80MHz; dividing the number of system ticks in the event by 800 reduces the result to 10 microsecond units (0.01 milliseconds). I thought -- considering the short length of your speed trap -- that sub-millisecond resolution would be appropriate.
There is always some amount of overhead in coding, and coding is an iterative process. The "- 144" was not part of the first cut, though I knew from past experience I would need to subtract some overhead. In the first cut of code I simply looked at the raw result when the second sensor was blocked before the first tripped; this would simulate a zero-duration event. The result of this test was the overhead that needed to be removed from the timing result. After that it was a simple matter to divide to an appropriate resolution and format the output.
Jon I fully agree to both of your statements. Regarding how the prop works, certainly. Regarding the work you do, both acting, and even behind the scenes, it is still amazing.
I have several of your examples here for the Prop, the one for the RGB Pixels is one. For the Stamp? That's the Calculator one I use to confirm that I'd managed to get the thing running properly.
And as usual this is being sponsored by the friends of Dwarf Grumpy.