Request to have elapsedMillis/elapsedMicros data-type added to standard Arduino

[Anthony May]

hi,

i've become somewhat enamoured of Paul Stoffregen's 'elapsedMillis' & 'elapsedMicros' data-type that he includes in his Teensyduino add-on:  http://www.pjrc.com/teensy/td_timing.html

It addresses two shortcomings with the standard millis() & micros() functions:

    - from the novice programmer's perspective variables declared as type 'elapsedMillis' automatically increment every millisecond (& likewise for elapsedMicros / microseconds, so it becomes not just a trivial line of code for the novice user to decide when / how often to do something, but conceptually easier to avoid the ubiquitous "why is my code running so slow when I use delay() ?" problems;

    - it handles the wrap-around of both millis & micros.

Any chance of this being added to 1.5.x ?

Anthony.

[Cristian Maglie]

In data giovedì 31 ottobre 2013 13:16:59, Anthony May ha scritto:
> Any chance of this being added to 1.5.x ?

Seems very nice, there is a pointer to the source code?
May be it simpler to made it available through a library?

C

[Paul Stoffregen]

On 11/02/2013 04:27 AM, Cristian Maglie wrote:

> In data gioved� 31 ottobre 2013 13:16:59, Anthony May ha scritto:
>> Any chance of this being added to 1.5.x ?
> Seems very nice, there is a pointer to the source code?

Here is the source. It's merely a thin wrapper around millis() and
micros().

[David Mellis]

As usual, I'm not convinced that the problem(s) this is trying to solve are worth the complication of having two similar but different functions (millis() and elapsedMillis()). We're talking about:

ellapsedMillis em;

// ...

if (em < 1000) // ...

vs.

unsigned long n = millis();

// ...

if (millis() - n < 1000) // ... 

right?  The former doesn't necessarily seem simpler to me as the latter makes the behavior explicit and without adding much overhead to the code.

I think a big part of the simplicity of Arduino is in the minimal nature of its API and I think additions like this make the API more complicated without sufficient compensating utility.

David

On Sat, Nov 2, 2013 at 7:37 AM, Paul Stoffregen <pa...@pjrc.com> wrote:

On 11/02/2013 04:27 AM, Cristian Maglie wrote:

In data giovedě 31 ottobre 2013 13:16:59, Anthony May ha scritto:

Any chance of this being added to 1.5.x ?

Seems very nice, there is a pointer to the source code?

Here is the source.  It's merely a thin wrapper around millis() and micros().

May be it simpler to made it available through a library?

C

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Paul Stoffregen]

On 11/02/2013 08:53 AM, David Mellis wrote:

As usual, I'm not convinced that the problem(s) this is trying to solve are worth the complication of having two similar but different functions (millis() and elapsedMillis()).

I always assumed this API would be contraversial, for pretty much these reasons, so I've never bothered to propose it for inclusion into Arduino.

Yesterday I replied with the code, only because Cristian requested the source.  You're welcome to use it if you like.  Or somebody could package it up as a library and put it on the playground somewhere.

We're talking about:

ellapsedMillis em;

// ...

if (em < 1000) // ...

vs.

unsigned long n = millis();

// ...

if (millis() - n < 1000) // ... 

right?  The former doesn't necessarily seem simpler to me as the latter makes the behavior explicit and without adding much overhead to the code.

I think a big part of the simplicity of Arduino is in the minimal nature of its API and I think additions like this make the API more complicated without sufficient compensating utility.

David

On Sat, Nov 2, 2013 at 7:37 AM, Paul Stoffregen <pa...@pjrc.com> wrote:

On 11/02/2013 04:27 AM, Cristian Maglie wrote:

In data giovedě 31 ottobre 2013 13:16:59, Anthony May ha scritto:

Any chance of this being added to 1.5.x ?

Seems very nice, there is a pointer to the source code?

Here is the source.  It's merely a thin wrapper around millis() and micros().

May be it simpler to made it available through a library?

C

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Anthony May]

David A. Mellis wrote:

As usual, I'm not convinced

...and the eyes of a thousand former wishful contributors who are no longer here (& a precious few who still are) all roll in unison...

i understand you need to Just Say No to a lot of well-intentioned suggestions in projects like this.  but...

not convinced that the problem(s) this is trying to solve are worth the complication of having two similar but different functions (millis() and elapsedMillis()).

every Arduino forum - which almost by definition are aimed at novice/non-programmers - regularly sees posts describing problems with timing & "unexpected" temporal behaviour.

most of the AVR's hardware has been abstracted by the Arduino platform in functions like digitalWrite(), analogRead(), a bunch of math, bits & bytes, serial, interrupts even!

but not the glaring exception of the timer(s), critical to so many applications, but which are still only presented to the novice user "as is", and with no consideration of wrap-around.  why?

We're talking about:

ellapsedMillis em;

// ...

if (em < 1000) // ...

vs.

unsigned long n = millis();

// ...

if (millis() - n < 1000) // ... 

right?  The former doesn't necessarily seem simpler to me as the latter makes the behavior explicit and without adding much overhead to the code.

i think you've forgotten what it's like being new to a high-level language, or being a "non--programmer".

"digitalWrite(13, HIGH)"  is pure magic of hardware abstraction of great benefit for the novice.

so is " if ( MyElapsedMillisVariable > 250) { do stuff } ", whether for a 1-off comparison, or even if I have to zero it or subtract 250 from it afterward.

IMHO that's not a complication, it's a much needed hardware abstraction, whose overhead is minimal.

Anthony.

[Mikal Hart]

I agree with David.  To make correct use of elapsedMillis, one must have a fairly sophisticated understanding of C++ object lifespans.  Consider the plausible but incorrect:

 

void loop()

{

  elapsedMillis em;

 

  if (em > 5000) // turn on LED after 5 seconds

    digitalWrite(13,  HIGH);

}

 

Of course everyone here understands why this fails and how to correct it.  But when you imagine explaining to a beginner, it seems less like a “much needed hardware abstraction” to me.

 

Mikal

 

--

You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Peter Feerick]

Anthony,

Said beginner would also have to have ignored this comment in the sample code Paul provided in the documentation page...

// create elapsedMillis outside loop(), to retain its value each time loop() runs.

I agreed with David's comment re: simplicity of

the

A

rduino

platform

. But simplicity should not be confused with minimalism. If I have to step through a few hoops to add millis() based delays in my

sketch

, and the API doesn't help me something as simple* as this, then it's hard, not simple. *Simple as far as a new user/artist/designer would be

concerned. 

-Pete

[Tom Igoe]

Mikal makes a good point, building on Dave’s point. One of the concepts I see students (other than those who are good at math) struggle with more than most are variables. "How do variables get their value?" is the usual question. My usual answer is “You give them value, using the = operator, like so:  variable = 5, or variable = analogRead(A0). In the latter case, you know that the function analogRead() is going to return a value when it runs, and you’re putting the value in the variable.”

But this proposal makes a variable that changes its value automagically. That’s confusing and inconsistent with the above explanation.  So if we did implement this, what would be a simpler explanation of variables that’s consistent with this new one that changes on its own?

t.

[Paul Stoffregen]

Did I mention my long-held belief elapsedMillis would be contraversial?� There's a reason I've never brought it up here....

These are all good points.� The variable scope issue has come up a few times over the last couple years.� But overall, feedback from users about elapsedMillis has been very positive.� Everybody seems to "get it" pretty easily.� Then again, Teensy tends to appeal to slightly more technically savvy users, so I wouldn't claim that experience necessarily would apply to all or even many Arduino users.

I've long intended to package elapsedMillis as a library (AFAIK just add keywords.txt) and publish it somewhere, maybe on the playground?� But that's never been a priority.� Perhaps if someone felt strongly enough about this, they could put in that relatively minor amount of work as a first step?� A readme.txt file could be included, soliciting feedback.� Maybe over time, such feedback might lead to a better sense of whether this feature belongs in the official core?



On 11/04/2013 05:31 AM, Tom Igoe wrote:

Mikal makes a good point, building on Dave�s point. One of the concepts I see students (other than those who are good at math) struggle with more than most are variables. "How do variables get their value?" is the usual question. My usual answer is �You give them value, using the = operator, like so: �variable = 5, or variable = analogRead(A0). In the latter case, you know that the function analogRead() is going to return a value when it runs, and you�re putting the value in the variable.�

But this proposal makes a variable that changes its value automagically. That�s confusing and inconsistent with the above explanation. �So if we did implement this, what would be a simpler explanation of variables that�s consistent with this new one that changes on its own?

t.

On Nov 3, 2013, at 1:54 AM, Mikal Hart <mh...@sundial.com> wrote:

I agree with David.� To make correct use of elapsedMillis, one must have a fairly sophisticated understanding of C++ object lifespans.� Consider the plausible but incorrect:

�

void loop()

{

� elapsedMillis em;

�

��if (em > 5000) // turn on LED after 5 seconds

��� digitalWrite(13, �HIGH);

}

�

Of course everyone here understands why this fails and how to correct it.� But when you imagine explaining to a beginner, it seems less like a �much needed hardware abstraction� to me.

�

Mikal

�

From:�Anthony May [mailto:tech...@gmail.com]�
Sent:�Sunday, November 03, 2013 12:13 AM
To:�devel...@arduino.cc
Subject:�Re: [Developers] Request to have elapsedMillis/elapsedMicros data-type added to standard Arduino

�

David A. Mellis wrote:

As usual, I'm not convinced

�

...and the eyes of a thousand former wishful contributors who are no longer here (& a precious few who still are) all roll in unison...

�

i understand you need to Just Say No to a lot of well-intentioned suggestions in projects like this. �but...

�

not convinced that the problem(s) this is trying to solve are worth the complication of having two similar but different functions (millis() and elapsedMillis()).

�

every Arduino forum - which almost by definition are aimed at novice/non-programmers - regularly sees posts describing problems with timing & "unexpected" temporal behaviour.

�

most of the AVR's hardware has been abstracted by the Arduino platform in functions like digitalWrite(), analogRead(), a bunch of math, bits & bytes, serial, interrupts even!

�

but not the glaring exception of the timer(s), critical to so many applications, but which are still only presented to the novice user "as is", and with no consideration of wrap-around. �why?

�

We're talking about:

�

ellapsedMillis em;

// ...

if (em < 1000) // ...

�

vs.

�

unsigned long n = millis();

// ...

if (millis() - n < 1000) // ...�

�

right? �The former doesn't necessarily seem simpler to me as the latter makes the behavior explicit and without adding much overhead to the code.

�

i think you've forgotten what it's like being new to a high-level language, or being a "non--programmer".

�

"digitalWrite(13, HIGH)" �is pure magic of hardware abstraction of great benefit for the novice.

�

so is " if ( MyElapsedMillisVariable > 250) { do stuff } ", whether for a 1-off comparison, or even if I have to zero it or subtract 250 from it afterward.

�

IMHO that's not a complication, it's a much needed hardware abstraction, whose overhead is minimal.

�

Anthony.

�

�

--�

You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to�developers+...@arduino.cc.

--�

You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to�developers+...@arduino.cc.

[Tom Igoe]

I’m not too attached to either way —part of me likes it, and part thinks what I posted. If there were strong support among users and teachers for the new way, I’d go with it. It might be one of those inconsistencies that people just get. And maybe there’s a better way to explain variables than I have.  How do you explain it to beginners? 

On Nov 4, 2013, at 9:00 AM, Paul Stoffregen <pa...@pjrc.com> wrote:

Did I mention my long-held belief elapsedMillis would be contraversial?  There's a reason I've never brought it up here....

These are all good points.  The variable scope issue has come up a few times over the last couple years.  But overall, feedback from users about elapsedMillis has been very positive.  Everybody seems to "get it" pretty easily.  Then again, Teensy tends to appeal to slightly more technically savvy users, so I wouldn't claim that experience necessarily would apply to all or even many Arduino users.

I've long intended to package elapsedMillis as a library (AFAIK just add keywords.txt) and publish it somewhere, maybe on the playground?  But that's never been a priority.  Perhaps if someone felt strongly enough about this, they could put in that relatively minor amount of work as a first step?  A readme.txt file could be included, soliciting feedback.  Maybe over time, such feedback might lead to a better sense of whether this feature belongs in the official core?

On 11/04/2013 05:31 AM, Tom Igoe wrote:

Mikal makes a good point, building on Dave’s point. One of the concepts I see students (other than those who are good at math) struggle with more than most are variables. "How do variables get their value?" is the usual question. My usual answer is “You give them value, using the = operator, like so:  variable = 5, or variable = analogRead(A0). In the latter case, you know that the function analogRead() is going to return a value when it runs, and you’re putting the value in the variable.”

But this proposal makes a variable that changes its value automagically. That’s confusing and inconsistent with the above explanation.  So if we did implement this, what would be a simpler explanation of variables that’s consistent with this new one that changes on its own?

t.

On Nov 3, 2013, at 1:54 AM, Mikal Hart <mh...@sundial.com> wrote:

I agree with David.  To make correct use of elapsedMillis, one must have a fairly sophisticated understanding of C++ object lifespans.  Consider the plausible but incorrect:

 

void loop()

{

  elapsedMillis em;

 

  if (em > 5000) // turn on LED after 5 seconds

    digitalWrite(13,  HIGH);

}

 

Of course everyone here understands why this fails and how to correct it.  But when you imagine explaining to a beginner, it seems less like a “much needed hardware abstraction” to me.

 

Mikal

 

From: Anthony May [mailto:tech...@gmail.com] 
Sent: Sunday, November 03, 2013 12:13 AM
To: devel...@arduino.cc
Subject: Re: [Developers] Request to have elapsedMillis/elapsedMicros data-type added to standard Arduino

 

David A. Mellis wrote:

As usual, I'm not convinced

 

...and the eyes of a thousand former wishful contributors who are no longer here (& a precious few who still are) all roll in unison...

 

i understand you need to Just Say No to a lot of well-intentioned suggestions in projects like this.  but...

 

not convinced that the problem(s) this is trying to solve are worth the complication of having two similar but different functions (millis() and elapsedMillis()).

 

every Arduino forum - which almost by definition are aimed at novice/non-programmers - regularly sees posts describing problems with timing & "unexpected" temporal behaviour.

 

most of the AVR's hardware has been abstracted by the Arduino platform in functions like digitalWrite(), analogRead(), a bunch of math, bits & bytes, serial, interrupts even!

 

but not the glaring exception of the timer(s), critical to so many applications, but which are still only presented to the novice user "as is", and with no consideration of wrap-around.  why?

 

We're talking about:

 

ellapsedMillis em;

// ...

if (em < 1000) // ...

 

vs.

 

unsigned long n = millis();

// ...

if (millis() - n < 1000) // ... 

 

right?  The former doesn't necessarily seem simpler to me as the latter makes the behavior explicit and without adding much overhead to the code.

 

i think you've forgotten what it's like being new to a high-level language, or being a "non--programmer".

 

"digitalWrite(13, HIGH)"  is pure magic of hardware abstraction of great benefit for the novice.

 

so is " if ( MyElapsedMillisVariable > 250) { do stuff } ", whether for a 1-off comparison, or even if I have to zero it or subtract 250 from it afterward.

 

IMHO that's not a complication, it's a much needed hardware abstraction, whose overhead is minimal.

 

Anthony.

 

 

-- 
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

-- 
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Anthony May]

On Tuesday, 5 November 2013 01:00:42 UTC+11, paul wrote:

Did I mention my long-held belief elapsedMillis would be contraversial?� There's a reason I've never brought it up here....

I must reinforce Paul's assertion that it isn't him driving this - it's just me, a 'nobody' who thinks Arduino is an astonishing development (i'm an EE & ASM-programming uC-geek from the 90s getting back into it, including wrapping my head around C/C++), who stumbled across his elapsedMillis/elapsedMicros datatype in Teensyduino, loved it for its "simple magic" that was entirely in keeping with all the other Simple Magic in Arduinoland, I asked the question on his forums "How do I get this in non-Teensy targets?" and which lead to my request here.  Paul was quite up front that he wasn't going to push it himself, that someone else would have to.  Having kept half an eye on this forum for 6 months I already understood why.

On 11/04/2013 05:31 AM, Tom Igoe wrote:

Mikal makes a good point, building on Dave�s point. One of the concepts I see students (other than those who are good at math) struggle with more than most are variables. "How do variables get their value?" is the usual question. My usual answer is �You give them value, using the = operator, like so: �variable = 5, or variable = analogRead(A0). In the latter case, you know that the function analogRead() is going to return a value when it runs, and you�re putting the value in the variable.�  But this proposal makes a variable that changes its value automagically. That�s confusing and inconsistent with the above explanation. �So if we did implement this, what would be a simpler explanation of variables that�s consistent with this new one that changes on its own?

 

"Variables are a box.  You put something in there, and it stays there, unchanged, until you do something else with what's in that box.  When you refer to the box by its name, the contents of that box are used to do stuff: math, make decisions, communicate with something or someone, and so on.  There are several different types of box, for holding different kinds of data: boolean, bytes, integers , long integers, characters, floating-point numbers, and so on.  You decide what type of box you want when you declare the variable."

Only on the (proposed) elapsedMillis/elpasedMicros data-type page would there be something like this:

"elapsedMillis/elapsedMicros aren't like normal variables, they're actually a special variable type that gets automatically incremented by the CPU's timer every milli/micro-second.  So when you set it to 0 (zero), 1 millisecond later that box will contain 1, not 0.  1385 milliseconds later, that box will contain 1385.

You can set/reset it to whatever value you want, when ever you want, and it will be incremented by 1 after each milli/micro-second of time has passed.  You can use it to easily decide in your program when to do stuff.

But be careful!  Most of the time you will probably want to declare variables of the elapsedMillis/elpasedMicros data-type globally, at the top of your sketch.  If you define them inside a function() or in loop(), they will be reset to 0 (zero) each time the function() is called or loop() begins from the top."

...and a million grey-beards all cried out in sphincter-clenching horror... ;)

but we wouldn't be here if we were unwilling to accept a programming environment that went out of its way to soften the edges of sometimes difficult concepts, boilerplate code, & abstracting the technicalities of hardware, especially with such a lavish supply of examples of neophytes getting timing wrong.

[Paul] I've long intended to package elapsedMillis as a library (AFAIK just add keywords.txt) and publish it somewhere, maybe on the playground?� But that's never been a priority.� Perhaps if someone felt strongly enough about this, they could put in that relatively minor amount of work as a first step?� A readme.txt file could be included, soliciting feedback.� Maybe over time, such feedback might lead to a better sense of whether this feature belongs in the official core?

Given that I made the astonishing discovery (that's not sarcasm, it's genuine) that I could add an entirely new datatype - elapsedMillis/elapsedMicros - simply by copying elapsedMillis.h into a folder of the same name in my user-defined Sketches/Libraries folder, just like it were a code library, I'll give it a go.

Anthony.

[John Plocher]

[Paul] I've long intended to package elapsedMillis as a library (AFAIK just add keywords.txt) and publish it somewhere, maybe on the playground?

 

 [Anthony] I'll give it a go.

Here's a starting point if you want to put something up on playground...

  -John

[John Plocher]

(and, like all code posts, the test one does right after posting finds a bug)

Change the < to an > in the millisloop() snippit.  Teach me to copy/paste's from a discussion thread :-)

  -John

(a big thank you to Paul for, well, everything)

[Peter Feerick]

John,

I'll bite, as you beat me to the zip file package... I'll write up something for the playground later this afternoon if that's ok with you.

Cheers,
Peter

Peter Feerick
BIT, BLDes CQU

0413 431 284

174 Cummins Rd
Bundaberg Q 4670

peter....@gmail.com
peter....@cqumail.com

[John Plocher]

Based on offline feedback, I've got a new package, with improved and tested examples (yup, two :-)

  -John

[Peter Feerick]

* Last post to developer forum on this thread unless further issues are raised - direct emails from now onwards to avoid clutter*

Initial stub article has been created on the Playground (and linked to from main libraries page) -> http://playground.arduino.cc//Code/ElapsedMillis

Source code is hosted on github -> https://github.com/pfeerick/arduino-elapsedMillis

Will finalise playground article and any minor amendments to code download by Saturday, Any suggestions, comments and small furry creatures are welcome :)

Cheers,
Pete

Peter Feerick
BIT, BLDes CQU

0413 431 284

174 Cummins Rd
Bundaberg Q 4670

peter....@gmail.com
peter....@cqumail.com

[Matthijs Kooijman]

Hey Peter,

> Initial stub article has been created on the Playground (and linked to from
> main libraries page) -> http://playground.arduino.cc//Code/ElapsedMillis
>
> Source code is hosted on github ->
> https://github.com/pfeerick/arduino-elapsedMillis

Yay for hosting the code on Github. I really hate code hosted on the
playground itself where you have to copy-paste the code or download a
zip without version history.

On nitpick about the example:

elapsedMillis em;

Perhaps call this variable "elapsed" instead? That makes the code a lot
easier to read and might encourage new users to uses more than two
letters for their variables :-)

Might be personal preference, though.

One more: The indentation of the code inside the if in loop() seems
messed up.

Perhaps you should also include a link to the github repository itself
(and suggest to report any issues there as well), instead of just the
generated zip file and indicate that the zip file always returns the
latest version from git?

> Will finalise playground article and any minor amendments to code download
> by Saturday, Any suggestions, comments and small furry creatures are
> welcome :)

That's my $0,02 (no furry creatures though, I'd like to keep my cats to
myself ;-p)

Thanks for picking this up!

Gr.

Matthijs

[Paul Stoffregen]

On 11/07/2013 02:03 AM, Peter Feerick wrote:

* Last post to developer forum on this thread unless further issues are raised - direct emails from now onwards to avoid clutter*

Initial stub article has been created on the Playground (and linked to from main libraries page) -> http://playground.arduino.cc//Code/ElapsedMillis

I have added a link to this playground page from my original web page about elapsedMillis.

[Matthew Ford]

Hi John,
Can you change the zip structure so that the user can just unzip it to their arduino/libraries directory
i.e. move elapsedMillis directory to the top level and move the readme into the elapsedMillis

matthew

[Tom Igoe]

You could also just use the install library feature if the structure is right...

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Peter Feerick]

Mathew,

I have a open issue for this on github + for a repository rename, and will hopefully have a chance to close it tonight. Plus incorporate Matthijs's feedback. 

Peter

Sent from my iPod

[Peter Feerick]

@Tom, Just found and tried that option - doesn't work as it creates a folder the same name as the zip file - and elaspedMillis-master is not correct nor valid! :(

@Matthew, zip file structure changed. You can now just unzip into elapsedMillis folder yourself, or clone with git.

@Matthijs, feedback appreciated and incorporate - no, not just you and I have enough cats... four flying feline rodents is enough for one household :)

@Paul, thanks for linking to the Playground page, and thanks for the great starting code.

Playground page has been completed (for now). Thanks to everyone for their feedback and comments.

Cheers,
Pete

[Matthew Ford]

Hi Peter,
your change is a step backwards
previous zip file has an internal folder called
elapsedMillis
which could be unzip to libraries  (or copied after unzipping to a temp dir)

The latest zip has no folder that can be put in libraries,  the users have to create their own folder.

please either revert the zip
or preferably
create as zip with just one top level folder called 
elapsedMillis
which contains all the files

thanks
matthew

[Peter Feerick]

Matthew,

Whilst I fully understand your point, unless someone can suggest a practical alternative that allows me to include the elapsedMillis folder whilst not capturing the rest of my Arduino library, this won't be changing any time soon, and appears to be the normal practice for Arduino libraries maintained in version control system (ie. Github).

For example, https://github.com/openenergymonitor/EmonLib, https://github.com/jcw/jeelib, and https://github.com/milesburton/Arduino-Temperature-Control-Library

I will however add more informative documentation on installing the library. 

As a side note, if a beginner can't even create a folder to put the library in, I would be very worried for a beginner, as they would have a *very* steep learning curve ahead of them :)

Cheers,

Pete

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--

[John Plocher]

It is a relatively standard thing to have a tar file that extracts into "library" and creates the needed directory automatically...

Both a tar tract and a git clone into the lib dir should result in a working Hilda env...  (IMO...)

  John

You received this message because you are subscribed to a topic in the Google Groups "Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/arduino.cc/d/topic/developers/FAw_W0Vn7kg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to developers+...@arduino.cc.

[Matthew Ford]

Hi Pete
I tried following the instructions on the playground page

"The latest version of the source code is always available for download here (this is a zip file containing the current version of the code). Just download the file, and unpack the contents to your Sketchbook\Libraries folder in a folder named 'elapsedMillis'. (For more information, have a look at the Arduino Guide to Installing Libraries)."

When I unzipped the zip file to the libraries dir, I got a folder called, elapsedMillis-master.
When I created a folder called elapsedMillis and unzipped the zip file into that I got  elapsedMillis/elapsedMillis-master , which didn't work either.

Then I went to the Arduino Guide to Installing Libraries. That page talks about using Automatic Install and that did not work.

Had to scroll down to the Manual installation to get instructions that worked.

I think these instructions are not clear enough for a beginner. It should not be this hard to install a library.

I like the elapsedMillis library and want to encourage it use, so as a convenience, I will host a zip file on
http://www.forward.com.au/pfod/ArduinoProgramming/TimingDelaysInArduino.html
that can be used with the Automatic Install
.
matthew

[Peter Feerick]

Matthew,

AFAIK,  no (normal) github zip will work as it typically is called [reponame]-master.zip., so I need to come up for a solution to work with auto install in arduino ide,  as it seems  it makes a folder same name if only one folder in root of zip or a folder the same name as the zip in other cases.

I have little time to work on this at due to other commitments but hope to address this soon.

Pete

[Matthijs Kooijman]

Hey John,

On Sat, Nov 09, 2013 at 06:42:55AM -0800, John Plocher wrote:
> It is a relatively standard thing to have a tar file that extracts into
> "library" and creates the needed directory automatically...

On the other had, it is common for zipfiles to _not_ include this top
directory, I think.

> Both a tar tract and a git clone into the lib dir should result in a
> working Hilda env... (IMO...)

With an autogenerated zipfile from github, I don't see how this is
possible. The git clone operation always clones into a subdirectory
(i.e., makes a subdirectory for you), while the unzip operation does
not. Hence, you'll either have to create the directory yourself when
unzipping, or you'll have an extra directory in the git clone approach.

Perhaps someone should file a feature request with github about
optionally including a top-level directory in zip files?

Gr.

Matthijs

[Paul Stoffregen]

On 11/10/2013 01:20 AM, Matthijs Kooijman wrote:
> Perhaps someone should file a feature request with github about
> optionally including a top-level directory in zip files?

Arduino's Edit > Add Library feature could also be programmed to
recognize and automatically handle these cases.

[Tom Igoe]

FWIW, the Adafruit libraries off GitHub usually work straight out for me with the Add Library feature. May be worth looking at them as example structures.

t.

[Matthew Ford]

While writing a sketch for beginners, I was doing a digital read of a
PWM output
And it did not do as I expected.
What I was expecting was HIGH and LOW in about the PWM ratio
But always got LOW.

Then found this in the code
I don't see any reason to override a uses PWM setting just because their
code asks for a read.
matthew

int digitalRead(uint8_t pin)
{
uint8_t timer = digitalPinToTimer(pin);
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);

if (port == NOT_A_PIN) return LOW;

// If the pin that support PWM output, we need to turn it off
// before getting a digital reading.
if (timer != NOT_ON_TIMER) turnOffPWM(timer);

if (*portInputRegister(port) & bit) return HIGH;
return LOW;
}

[Rob Tillaart]

Good question Matthew,

The only reason I can think of is that if there is a PWM signal on the PIN, digitalRead() will be "random" as it can be LOW or HIGH with a chance related to the duty cycle.

And that is most of the time not what a programmer intends (OK that is an assumption)

Have you tried removing/commenting the line with turnOffPWM() and see what happens? 

That would almost be identical to reading the port directly. Again I expect it can give "random" HIGH LOW if the PWM is on.

Rob

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Peter Feerick]

Forgot to cc mailing list
>
> Matthew,
>
> If my understanding of how pwm works on AVRs is correct (after a brief skim of the AVR timers app note) , pwm is based on output compare, which requires the pin to be set as an output. As soon as you try to use digitalread (implying an input pin), the AVR automatically disables pwm! there is also an old forum discussion which mentions that the AVR chip disables pwm before reading the pin anyway, so the specific instruction to stop it is pointless anyway.
>
> Please feel free to berate me if I'm wrong! :)
>
> Pete
>
> Sent from my iPod

[Knight, Dave]

Maybe this is a dumb question, but why exactly do you want to read a pwm output pin?  

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
"Gun control empowers the wolves, and creates more sheep!"
              Dan Bongino, Former US Secret Service Agent

[Peter Feerick]

Matthew,

Sorry, yes, that is correct. Since digitalRead is just a pretty way of reading the AVR PINx register... The following applies

AVR Registers

... 

PINx (Port IN) used to read data from port pins. In order to read the data from port pin, first you have to change port’s data direction to input. This is done by setting bits in DDRx to zero. If port is made output, then reading PINx register will give you data that has been output on port pins.

To submit a bug report, request features, changes, etc, use the issue tracker on GitHub.  

https://github.com/arduino/Arduino/issues

Pete

On 15 Nov 2013, at 8:13 am, Matthew Ford <matthe...@forward.com.au> wrote:

On 14/11/2013 10:42 PM, Knight, Dave wrote:

Maybe this is a dumb question, but why exactly do you want to read a pwm output pin? 

Very sensible question, Dave
and thanks to the others who replied to my email.

I posted an instructable
"Arduino for Beginners, controlled by Android, No coding required, No soldering required"
http://www.instructables.com/id/Arduino-for-Beginners-controlled-by-Android-No-cod/
which controls all the digital and analog pins from your Android mobile.

I am now adding plotting to the android app and wanted to plot the digital pin states.
So I just added a loop to digitalRead each pin and output the result.
BUT when I tried reading a pin set to PWM,  Arduino'a digitalRead() over rode the user's PWM setting and made the pin output low.

When I replace Arduino's version of digitalRead with the one suggested by Greg (myDigitalRead below),  everything works.

Pete, I checked the Atmel docs and looks to me like you can always read the digital state, and result of Greg's code supports this.

So I think this is a bug in the Arduino library and would like to raise request for it be fixed. 
Is there a web page on submitting change requests?

matthew

int myDigitalRead(uint8_t pin)
{
    uint8_t timer = digitalPinToTimer(pin);
    uint8_t bit = digitalPinToBitMask(pin);
    uint8_t port = digitalPinToPort(pin);

    if (port == NOT_A_PIN) return LOW;

    // If the pin that support PWM output, we need to turn it off
    // before getting a digital reading.
    //this is MY digital read, I want PWM on.
    //if (timer != NOT_ON_TIMER) turnOffPWM(timer);


    if (*portInputRegister(port) & bit) return HIGH;
    return LOW;
}

On 14/11/2013 10:42 PM, Knight, Dave wrote:

Maybe this is a dumb question, but why exactly do you want to read a pwm output pin?  

On Thursday, November 14, 2013, Matthew Ford wrote:

While writing a sketch for beginners,  I was doing a digital read of a PWM output
And it did not do as I expected.
What I was expecting was HIGH and LOW in about the PWM ratio
But always got LOW.

Then found this in the code
I don't see any reason to override a uses PWM setting just because their code asks for a read.
matthew

int digitalRead(uint8_t pin)
{
    uint8_t timer = digitalPinToTimer(pin);
    uint8_t bit = digitalPinToBitMask(pin);
    uint8_t port = digitalPinToPort(pin);

    if (port == NOT_A_PIN) return LOW;

    // If the pin that support PWM output, we need to turn it off
    // before getting a digital reading.
    if (timer != NOT_ON_TIMER) turnOffPWM(timer);

    if (*portInputRegister(port) & bit) return HIGH;
    return LOW;
}

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.