Is there a project to improve/replace the official examples?

Sorry about mixing up the terminology. I can't claim to be new to this either, LOL.

Potentially unsuitable... okay yes but in this case we only deal with bit zero.
The potential wrong is in how the bit(s) is/are used or checked. If other bits are used then the if() or while() or other way to check just one can include a mask of the others or use the bitRead() function to just get the one wanted.

I have no problem keeping many states as bits in unsigned variables and using bitwise logic to manipulate them en masse because I do keep track of which bits are used and how. Back in the late 80's I experimented with using Amiga graphics chip blit operations to work with whole arrays of bytes but nothing I did for work needed that.

My vote would go for the ! operator. This is much easier to understand and the cpu overhead is minimal.
I mean I have a average loop time of 2miliseconds for a robot with 6 engines, 2 bumper switches, 4 analog reads, gps, remote control and serial communication. For your information: I use plenty of if ... else constructions for readability.

Personally I find this info below a bit over the top for a blink without delay example

analog read takes
// longer, about 9 per millisecond so it's best not to do a bunch of those
// in a row but instead 1 analog read per time through loop() so other tasks
// can get a chance in between analog reads.
// it's also good to avoid using floating-point as that is slooowww and avoid
// using C++ Strings as they mess with your RAM and suck up CPU cycles doing it.

Maybe it is better to add some code that logs "how long -on average, min and max- the other work took". For help on the forum this logging could be really helpful.

Further on I find the example very good.
Best regards
Jantje

I like to keep loop() short and not do everything every time as a matter of course. Some things get priority, especially ones that only happen on time or sensor input or interrupt flag with the ones that check quickest preferred happening sooner. I use state machines to control what part(s) run on any execution of loop(). It's not like loop() won't run again and the critical checks be made first sooner. I may run multiple sub-tasks in one pass through loop() but anything that takes as long as an analog read gets a return to start loop() again.

For me it's about response and having my time-checks close. I do use micros() instead of millis() for fine work. A lot can be done in 1000 micros().

very interesting how all this is coming.
I also measured my loop timing in my projects, however there is one situation I think has no way of improving the timing. Every 10 seconds I upload information to a server on the internet, so I call this...

// Make a HTTP request:
        Serial.print("Connecting...");
        if (client.connect(server, 80)) {//if (client.connect()) 
          Serial.print("connected!");
                    client.println(str);
                    client.println();
                    client.println();
                    client.stop();

It takes around 1300ms to finish, have not found a way to improve it, if any of you know how to.
Also when reading DS18B20 you need to do some delays, that also adds nearly a seconds (I only read them every 5 minutos)

First find the part that is blocking execution.

My guess is it's client.connect(server, 80). Perhaps that library has alternatives to waiting.

Sergegsx:
very interesting how all this is coming.
I also measured my loop timing in my projects, however there is one situation I think has no way of improving the timing. Every 10 seconds I upload information to a server on the internet, so I call this...

// Make a HTTP request:

Serial.print("Connecting...");
        if (client.connect(server, 80)) {//if (client.connect())
          Serial.print("connected!");
                    client.println(str);
                    client.println();
                    client.println();
                    client.stop();




It takes around 1300ms to finish, have not found a way to improve it, if any of you know how to.
Also when reading DS18B20 you need to do some delays, that also adds nearly a seconds (I only read them every 5 minutos)

I solved this issue by offloading the ethernet stuff to a external party. This could be a pi but I choose a hacked wifi router. This way I can use Serial.print() commands and the ash script on the router knows what to do with it.
It is faster, cheaper, more modular and allows me to do lots of extras like remote upload of a sketch. I love it when my robot is in the back of the garden in the rain and I uploaded a new sketch from the comfort of my sofa enjoying the heat of a good fire. ]:smiley:

I still have the problem with SD logging. SD cards need to reorganize from time to time and that can take up to 140 ms. For debugging I can log all data in every loop. But for real running I simply disable logging.

GoForSmoke:
... but anything that takes as long as an analog read gets a return to start loop() again.

Can you explain what you mean by this? Have you split the analog read in 2 actions?

GoForSmoke:
For me it's about response and having my time-checks close. I do use micros() instead of millis() for fine work. A lot can be done in 1000 micros().

I agree lots can be done in 1000micros, but IMHO for most applications millis() is more than enough. I mean if a project has 5 (software) components each taking 2 millis() for a loop that is 10 millis() for the total project loop. That is still 100 times a second. In my experience that is more than enough for the average project and for most expert projects.

best regards
jantje

Jantje, its a good idea what you propose, and I have several of those TPLink 703, actually I use one of them to convert Wifi to Ethernet for this same project, so I dont have to deal with wifi shields.
however, I wanted to keep all the programing and hacking on the arduino, so that when reproducing this project I dont need to depend also on the hacked router. Also this way I can use a network cable, with my project, or a router in bridge mode, and the sketch does not need to be changed.
however, thanks for the suggestion.

I believe there is a timeout on the upload execution, the disadvantage of this is that you start loosing uploads if things take a little bit longer than expected.

Jantje:
I still have the problem with SD logging. SD cards need to reorganize from time to time and that can take up to 140 ms. For debugging I can log all data in every loop. But for real running I simply disable logging.

Some things will just take longer. I haven't delved deeply into SD, just use a library. It would be nice to interleave small tasks while waiting for the SD chip to finish housekeeping though and I am sure it can be done but may require extra buffer space.

GoForSmoke:
... but anything that takes as long as an analog read gets a return to start loop() again.

Can you explain what you mean by this? Have you split the analog read in 2 actions?

No. But if I have say 4 analog sensors I read 1 at a time through loop() allowing other short tasks to run between analog reads. Like if I want Blink and 4 reads, the blink time gets checked 4 times for every 1 time that all the sensors are read, that is 4 times as responsive. I am giving the analog reads a lower priority.

Hey, I usually put Serial I/O last.
With Serial input I read and operate on each character as it comes in. I don't buffer and then parse and lex, I analyze on the fly to match commands and evaluate digits. It saves time by not wasting it and IME (in my experience) it's not more code than buffer and crunch, just different and faster.

GoForSmoke:
For me it's about response and having my time-checks close. I do use micros() instead of millis() for fine work. A lot can be done in 1000 micros().

I agree lots can be done in 1000micros, but IMHO for most applications millis() is more than enough. I mean if a project has 5 (software) components each taking 2 millis() for a loop that is 10 millis() for the total project loop. That is still 100 times a second. In my experience that is more than enough for the average project and for most expert projects.

best regards
jantje
[/quote]

Do what you want. I write so that components are as unrelated as they can be and that includes order and priority of operation. I find state machines to be a more flexible approach trading nested levels of hard-coded logic for soft links via variables and pointers... and yes I have used tables of function pointers to organize code as well. It makes it easier to add/rearrange components and make major changes in how a whole package works. It is a far more spaghetti-resistant approach.

What I would really like is true parallel processing (and can achieve that with multiple AVR's if I take the time and have a task worth the effort). Until then I can can code to use the principles of parallel processing on a single chip.

So each time through loop() I run all necessary checks and actions and a slice of a task and that's it. Loop() keeps running, the tasks get done and it's dead simple to add tasks.
I coded for money for 19 years and school/hobby almost as long and one thing I most desire to avoid is a lot of deeply nested code. Consider Bauhaus vs Art-Deco.

Sergegsx:
I believe there is a timeout on the upload execution, the disadvantage of this is that you start loosing uploads if things take a little bit longer than expected.

How late is tolerable? Can it trigger an interrupt on data ready?

Hi,
Back to the question of updating the examples, and possibly providing a way to catalog / find them:

Does anyone have a connection to the developers who can propose that a few very-involved forum supporters can get access to the example area??

I'm positive that good, well-documented examples would be the result.

Try contacting Masssimo or any of the other founders, Terry - I'm sure they'd be amenable, given your track-record.

My personal gripe with some of the examples is overuse of globals where locals would be preferable.

terryking228:
Hi,
Back to the question of updating the examples, and possibly providing a way to catalog / find them:

Does anyone have a connection to the developers who can propose that a few very-involved forum supporters can get access to the example area??

I'm positive that good, well-documented examples would be the result.

A set of examples comes with every Arduino IDE.
Did I mention the use of String objects?

Also a thought, we could use a howto section on hardware that doesn't disappear.

BTW, can opto-isolators be used as voltage level shifters? I think so.....

A set of examples comes with every Arduino IDE.

There must be a repository of those that Arduino uses when they build a new release. That's what we need to get access to. It would be good to make those all consistent with the same basic template, and the same conventions so that they are a good example for users.

I would like to suggest a template like this: http://arduino-info.wikispaces.com/YourDuinoStarter_SketchTemplate

So BLINK would look like this: http://arduino-info.wikispaces.com/YourDuinoStarter_Blink

And MAYBE there would be some more complex examples like: http://arduino-info.wikispaces.com/YourDuinoStarter_AutomationExample

Hmmm.

What do you guys think?? Would people be willing to work on updating many/most of them?? I think the simple ones are actually most important for new users. The complex stuff will be mostly used by those with a clue??

I like it

I sent a PM to Massimo.

Longtime contributors like AWOL, CodingBadly, RobTillaert, Crossroads etal, etal, if you'd be up for reworking official examples, let us know...

The examples are in the github repository. For instance this is a link to the eeprom examples.
https://github.com/arduino/Arduino/tree/master/libraries/EEPROM/examples
I guess massimo will propose to do the changes in a fork on github and when you do a pull request they may become part of the release.
Best regards.
jantje

There should be some kind of review process with no one "owning" any sketch.

I agree.. if Massimo will fork the examples, people could communicate (here?) and volunteer for particular examples.

No one should 'own' one, but the editors name and contact email should be in the source, IMHO.

terryking228:
I agree.. if Massimo will fork the examples, people could communicate (here?) and volunteer for particular examples.

No one should 'own' one, but the editors name and contact email should be in the source, IMHO.

In git anyone can fork any available code. So no need to bother Massimo with that.

The evaluation is done when someone who forked code does a pull request. At that point in time the owner of the code can look at the code accept/reject the proposed change. So in our situation the Arduino core team will do the "validation" after a pull request.

I think that if we propose anything to the core Arduino team we would be better to take this way of working as a guideline.

Best regards
Jantje

dont hold your breath

we still as of 1.05 have all the warnings in the standard compile of the examples,
like in the print, serial and tone libraries.

been in the official arduino release for years, fix's out there, but never put into the official release,,

dont hold your breath

Good advice. I started this thread to see about breathing some life into fixing the examples. Let's not hold that back!

If no one spends the time then that whole section stays unchanged.
But I see that here we do spend time, often on ships that sail off the world's edge for all that.

I also see a lot of time spent correcting some of the bad habits that many of the examples teach. So perhaps a proper effort will have good returns.