Jump to content

Arduinos


system 4-50

Featured Posts

33 minutes ago, nicknorman said:

This line is where interval is used

 

if((currentMillis - previousMillis > interval) || (currentMillis < previousMillis)) {
 

aka “if the difference between current millis() and previous one is greater than interval (currently set to 1000), or if the current millis() is less than the previous one (due to rollover) then ...”

 

So you would expect the if statement to be true once per second.

 

have you tried increasing interval to say 2000 and see if the flashing is slower?

 

The second half of that boolean (currentMillis < previousMillis) is not necessary and will cause bad timing during rollover. In C over/underflow of arithmetic operations is defined for unsigned integers, and after a rollover thevalue currentMillis will become small, whilst previousMillis will be large, so the subtraction will underflow, resulting in a correct value even in that situation.

 

 

MP.

 

Link to comment
Share on other sites

I have taken it out and it is 2 seconds on and 2 off  which is what I should have said it was in my last.

 

it was 2000 millis that made it 1 ssecond changes.

 

now I need to adapt it to make a timedelay for my button

Link to comment
Share on other sites

33 minutes ago, MoominPapa said:

 

The second half of that boolean (currentMillis < previousMillis) is not necessary and will cause bad timing during rollover. In C over/underflow of arithmetic operations is defined for unsigned integers, and after a rollover thevalue currentMillis will become small, whilst previousMillis will be large, so the subtraction will underflow, resulting in a correct value even in that situation.

MP.

 

Won’t it cause bad timing at an overflow anyway? The first time the calc is done after rollover, the subtraction will give a large number even if much less than 1000 millis() has passed. Not that it really matters.

Link to comment
Share on other sites

3 minutes ago, nicknorman said:

Won’t it cause bad timing at an overflow anyway? The first time the calc is done after rollover, the subtraction will give a large number even if much less than 1000 millis() has passed. Not that it really matters.

 

I think its down to the way that unsigned arithmetic works, stuff on the www says its ok but I have not actually tested it myself.

At Rollover currentmillis will become very small, or possibly zero so (currentmilis-previousmillis) will be negative which can't happen with an unsigned number. 

Ive got an Arduino plugged into this PC right now so I might do a little experiment later ?.

 

...............Dave

Link to comment
Share on other sites

1 minute ago, nicknorman said:

Won’t it cause bad timing at an overflow anyway? The first time the calc is done after rollover, the subtraction will give a large number even if much less than 1000 millis() has passed. Not that it really matters.

 

The calculation currentMillis - previousMillis is actually done modulo 2^32, since the variables are unsigned long, which is 32 bits on Ardunio. PreviousMillis is close to rollover, say r milliseconds from rollover, so it's (2^32)-r and currentMillis has rolled over and is now a small number s milliseconds after rollover. So currentMillis - previousMillis is s+r-(2^32), but since the calculation is modulo 2^32, subtracting (or adding) 2^32 is an identity, it doesn't change the result at all and the actual value is s+r. That's exactly what we want for the number of milliseconds since previousMillis, as it's the number of milliseconds before rollover plus the number of milliseconds after rollover.

 

MP.

 

Link to comment
Share on other sites

4 minutes ago, MoominPapa said:

 

The calculation currentMillis - previousMillis is actually done modulo 2^32, since the variables are unsigned long, which is 32 bits on Ardunio. PreviousMillis is close to rollover, say r milliseconds from rollover, so it's (2^32)-r and currentMillis has rolled over and is now a small number s milliseconds after rollover. So currentMillis - previousMillis is s+r-(2^32), but since the calculation is modulo 2^32, subtracting (or adding) 2^32 is an identity, it doesn't change the result at all and the actual value is s+r. That's exactly what we want for the number of milliseconds since previousMillis, as it's the number of milliseconds before rollover plus the number of milliseconds after rollover.

 

MP.

 

 

so in almost plain english it returns the absolute value???????

Link to comment
Share on other sites

11 minutes ago, MoominPapa said:

 

The calculation currentMillis - previousMillis is actually done modulo 2^32, since the variables are unsigned long, which is 32 bits on Ardunio. PreviousMillis is close to rollover, say r milliseconds from rollover, so it's (2^32)-r and currentMillis has rolled over and is now a small number s milliseconds after rollover. So currentMillis - previousMillis is s+r-(2^32), but since the calculation is modulo 2^32, subtracting (or adding) 2^32 is an identity, it doesn't change the result at all and the actual value is s+r. That's exactly what we want for the number of milliseconds since previousMillis, as it's the number of milliseconds before rollover plus the number of milliseconds after rollover.

 

MP.

 


... gets out trusty hex calculator and simulates 1 tick before rollover and 1 tick after, ie 

0x00000001 - 0xFFFFFFFF which gives FFFF00000002 which, constrained to 32 bits, = 2
 

I should have known better than to argue!

 

So this whole millis rollover thing is a red herring!

 

Edited by nicknorman
Link to comment
Share on other sites

16 minutes ago, nicknorman said:


... gets out trusty hex calculator and simulates 1 tick before rollover and 1 tick after, ie 

0x00000001 - 0xFFFFFFFF which gives FFFF00000002 which, constrained to 32 bits, = 2
 

I should have known better than to argue!

 

So this whole millis rollover thing is a red herring!

 

As long as you do it by calculating (now - start > interval). It's tempting to calculate (now > start + interval) but that gives the wrong answer in the case that 1) start + interval has not rolled over, but now has rolled over, start+interval will be a large positive number, but now will be a small positive number, so you'll think the delay has not completed, even when it has.

 

MP.

 

  • Greenie 2
Link to comment
Share on other sites

45 minutes ago, nicknorman said:


... gets out trusty hex calculator and simulates 1 tick before rollover and 1 tick after, ie 

0x00000001 - 0xFFFFFFFF which gives FFFF00000002 which, constrained to 32 bits, = 2
 

I should have known better than to argue!

 

So this whole millis rollover thing is a red herring!

 

 

One day this virus will be gone and we can all talk about boating again. Even a bad day on the water is better than Hexadecimal.

 

..................Dave

Link to comment
Share on other sites

24 minutes ago, dmr said:

 

One day this virus will be gone and we can all talk about boating again. Even a bad day on the water is better than Hexadecimal.

 

..................Dave

 

Free me from the 'rona and brexit, but leave me my boating and my hex.

 

MP.

 

  • Greenie 1
  • Happy 2
Link to comment
Share on other sites

You are worrying me reading Output pins - particularly pin 13. 

 

"NOTE: Digital pin 13 is harder to use as a digital input than the other digital pins because it has an LED and resistor attached to it that's soldered to the board on most boards. If you enable its internal 20k pull-up resistor, it will hang at around 1.7V instead of the expected 5V because the onboard LED and series resistor pull the voltage level down, meaning it always returns LOW. If you must use pin 13 as a digital input, set its pinMode() to INPUT and use an external pull down resistor." from https://www.arduino.cc/en/Tutorial/Foundations/DigitalPins. 

 

Could you remove the line "int ledState = digitalRead(ledPin);  // Reads data from pin (13)    and puts in ledState int" and try flipping it another way? 

 

TheBiscuits gives the code, which you could try without trying the read pin 13. 

void loop()
{
    // check to see if it's time to blink the LED; that is, if the 
  // difference between the current time and last time you blinked 
  // the LED is bigger than the interval at which you want to 
  // blink the LED.
  unsigned long currentMillis = millis();
 
  // Jess's modification
  if((currentMillis - previousMillis > interval) || (currentMillis < previousMillis)) {
    // save the last time you blinked the LED 
    previousMillis = currentMillis;   
 
    // if the LED is off turn it on and vice-versa:
    if (ledState == LOW)
      ledState = HIGH;
    else
      ledState = LOW;
 
    // set the LED with the ledState of the variable:
    digitalWrite(ledPin, ledState);
  }
Link to comment
Share on other sites

Don't worry, this thread was started by a non boater (I think) who wanted help with programming micro-controllers in C, which has nothing much to do with boating.

The forum was obviously able to help. ?

The potential here is almost endless....................

My girlfriend has left me for a much younger man, and even taken the dog with her, what does the forum advise?

The Universe is expanding but at some stage will contract, what preparations does the forum think I should make?

 

 

 

  

Link to comment
Share on other sites

7 hours ago, frahkn said:

Five pages so far and I haven't understood any of it - I understand most of the words, just not when they are joined up.

 

Bit like some of the threads in the politics section (without the rude bits).

Shades of Eric Morecambe - all the right words, but not necessarily in the right order!

  • Greenie 1
Link to comment
Share on other sites

11 hours ago, dmr said:

The Universe is expanding but at some stage will contract, what preparations does the forum think I should make?

These days physicists seem to think that the universe will continue expanding forever. Eventually the protons, neutrons and electrons that make up the atoms in your body will evaporate in to the cold dark void and nothing more will happen, or can ever happen again for all eternity. A bit like Lock Down 3. Hope that has set your mind at rest and soothed your worries.

Link to comment
Share on other sites

1 hour ago, buccaneer66 said:

Are there any good books for those who haven't used C before to help learn it?

 

Programming is a bit like riding a bike, or welding, you can get a bit of background info from a book but really you just gotta do it.

Work through the various demo sketches  (very silly name for programs) that come with the Arduino, starting with the one that flashes the LED, and any of the things that dont make sense type into Google.

There are some moderately useful on-line tutorials.

 

.............Dave

  • Greenie 1
Link to comment
Share on other sites

Once you have got used to the arduino's and come up with all sorts of projects that you can use them for you will probably end up moving onto the esp-32 boards for the built in wifi / bluetooth or the M5Stack boards (which contain an esp32) for the built in screen & semi decent case (all of them use the same programming software and language)

Link to comment
Share on other sites

2 hours ago, buccaneer66 said:

Are there any good books for those who haven't used C before to help learn it?

I bought a C book in about 1990. Quite fat and very dull and impenetrable. And the book wasn’t much better. Absolutely zero progress with trying to make any sense of it. Last year, ie 30 years later, I thought I really ought to give myself a good slapping and get a grip, so I bought books called “C programming in easy steps” and “C for Dummies”. The Dummies book was truly awful, irritating, patronising and hopeless. The “easy steps” book was quite good, has most of what you need reasonably concisely.

 

But the real trick is that you need to have a project or at least something to actually programme on. You can’t just read a book about it because it won’t mean anything.

Link to comment
Share on other sites

1 hour ago, Jen-in-Wellies said:

Eventually the protons, neutrons and electrons that make up the atoms in your body will evaporate in to the cold dark void and nothing more will happen, or can ever happen again for all eternity

not quite.  Time will stop which is equivalent to being inderterminate which is identical to what it was before everything began which sounds as if it means everything will start all over again but it wont because the repeat run will be the same original run.  Another beer anybody?

Link to comment
Share on other sites

Oh I should also mention that Arduino-speak is C++, which is an extended version of C.

 

One of the “issues” with Arduino is that there are a lot of library functions that are already provided for you to use, eg to interact with the hardware. This is fine but can give a bit of a false impressions about what is C++ and what is Arduino library.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.