Too cryptic for me, but perhaps not for others
Hi Melanie,
Yes I understand that you can take the approach you just gave, but I tend to like things to mean what they say. If I have a statement that says "Pauseus 100" then I would like it to actually mean that I am taking a 100 microsecond pause. In this case we really aren't talking about "thinking outside of the box", but instead, about writing understandable code. Besides we aren't just talking about Pause routines here. There are 24 PBP functions that are all affected by incorrect oscillator selection.
Code:
COUNT, DEBUG, DEBUGIN,DTMFOUT,FREQOUT,HPWM,HSERIN,HSEROUT,
I2CREAD,I2CWRITE,LCDOUT,OWIN,OWOUT,PAUSE,PAUSEUS,
SERIN,SERIN2,SEROUT,SEROUT2,SHIFTIN,SHIFTOUT,
SOUND,XIN, and XOUT
I would hate to come back later, and try to debug even my own code, not say someone elses, if I used the method you suggested. Especially if a variety of the functions mentioned above were sprinkled throughout.
Don't get me wrong, I like PBP, and really appreciate the effort that had to be put into making it what it is today. However this is a "Wish List" and my wish is to see a better way to do the Oscillator Define, so that all functions utilizing timing in their makeup continue to do what they say, and to mean what they mean. Is this asking too much? Or am I developing a case of OCD?
Re: DEFINE OSC too limited
Good answer Melanie, I agree 100% with what you say. Purists tend to focus too much on one parameter, not realizing that in the big picture, there are lots of things that affect your reading, like temperature! In engineering we typically ignore the bottom 10% and the top 90% and concentrate efforts in between, meaning we don't sweat the small stuff unless it is ABSOLUTELY necessary. A LED that doesn't blink at exactly 1.0000Hz? Who cares, unless your using to to time Longines watches.
Re: DEFINE OSC too limited
Quote:
Originally Posted by
queenidog
Good answer Melanie, I agree 100% with what you say. Purists tend to focus too much on one parameter, not realizing that in the big picture, there are lots of things that affect your reading, like temperature! In engineering we typically ignore the bottom 10% and the top 90% and concentrate efforts in between, meaning we don't sweat the small stuff unless it is ABSOLUTELY necessary. A LED that doesn't blink at exactly 1.0000Hz? Who cares, unless your using to to time Longines watches.
... I do not know if Mel will even see your post ...
did you notice it is a 10 years after dig out ( tadaaa, music ON ) ... add to that Mel has left this forum many years ago ... ( 2 or more ...)
Quote:
Last Activity:- 22nd February 2012 01:20
Alain
Re: DEFINE OSC too limited
Yes I saw the date, but felt compelled to answer anyway, unaware of her status on this forum.
I had a friend who was doing some non-critical A/D conversions but was unsatisfied with the 10 bit (1:1024) resolution of his PIC and was going to employ an external A/D for the extra bits. I reminded him of the resolution and accuracy of his own DVM which was really no better. That and the fact that 10 bits over 5 volts is a resolution of about 5 mV.
Sometimes the forest can't be seen for the trees.
Re: DEFINE OSC too limited
Does anyone know why Melanie left the forum?
She was a prolific poster and helped many along the way and then suddenly, nothing more.
I have always been curious about her departure.
I wonder if she is aware of the sad news about Darrel Taylor?
Cheers
Barry
VK2XBP
Re: DEFINE OSC too limited
Yeah I was thinking about that myself... we kind of almost get to know each other in an anonymous sort of way.
I would be nice to hear how/what she is doing now days.
I'm sure there are others who have left after making a real positive impact on the learning experience of microcontroller programming.
Really a great bunch here... I wish the Basic Language would experience a sort of comeback or revival!!
Re: DEFINE OSC too limited
I was going to point that out, but then thought why bother.. lol.
I have wondered the same and just assume people move on, same as I thought with Darrel for some time actually.
It is true that the imagination can move around some limiting facts. That is a positive and true message!
Re: DEFINE OSC too limited
Quote:
Originally Posted by
Aussie Barry
Does anyone know why Melanie left the forum?
She was a prolific poster and helped many along the way and then suddenly, nothing more.
I have always been curious about her departure.
I wonder if she is aware of the sad news about Darrel Taylor?
Cheers
Barry
VK2XBP
Hi, Barry
Mel left the forum for professionnal reasons, as she was to travel a lot with her new function.
as she wrote me she was to spend much much time flying around the world.
Moreover she has a new Hobby : flying light aircrafts ...
I did not have any news from her for at least two years ...
Alain
Re: DEFINE OSC too limited
Hi Alain,
Thank you for the quick reply.
If you still have her contact details, perhaps you could let her know about Darrel.
Cheers
Barry
VK2XBP
Re: DEFINE OSC too limited
What about Darrel Taylor? Geez, he was another one who helped me a lot, not only through this forum but through the MELabs forum. He was the one that really got me started with this PIC/PBPro stuff, after I had a long hiatus from Motorola products. Great guy, smart as hell and helps every one. What is his story?
Re: DEFINE OSC too limited
Re: DEFINE OSC too limited
i have to aggree that the OSC define is very limiting and also makes for harder reading of code later on
i needed 1mhz setting , but there i no such setting , have to use 4mhz , which is fine , but it means all the code that has any pauses pauseus , are not correct and these routines have been used in other chips and now need to be changed just to suit this cpu setting.
not happy
it makes for servicing the software harder later down the road, and inconsitancies when the code is transported
not good
Re: DEFINE OSC too limited
Quote:
Originally Posted by
Heckler
... I wish the Basic Language would experience a sort of comeback or revival!!
Won't ever happen (outside of the hobby/education market) due to its many limitations/shortcomings.