Arduino code sources?

[Ralph Mowery]

In article <m3k4fehhjs1tmpfastpovp5ph515ecfvdo@4ax.com>,
me@somewhere.invalid says...

My current sources apart from tutorial projects are the obvious Google Search, the
Arduino Forum, and the Embedded Systems and Micro controllers section of the All
About Circuits Forum.

I found this most helpful. It is a list of the commands and short
explination. Near the end there are some short examples of the
commands.

https://archive.org/details/arduino_notebook

 

[Phil Hobbs]

On 6/1/19 7:38 AM, Lasse Langwadt Christensen wrote:

lørdag den 1. juni 2019 kl. 12.45.13 UTC+2 skrev Terry Pinnell:
Terry Pinnell <me@somewhere.invalid> wrote:

I bought my first Arduino UNO R3 kit two weeks ago (the Elegoo Super Starter kit)
and am stepping through its tutorials. In parallel I'm trying to learn the basics of
its C++ based programming language, but that's proving a struggle. I'm impatient to
use Arduino on my own projects so I will take a 'copy/paste/edit' approach. It then
becomes a matter of finding sketches that cover a particular subject and then
tailoring.

I'd therefore appreciate recommendations on Arduino sketch sources that others have
found useful please.

Terry, East Grinstead, UK

Thanks to those who suggested useful sources of code, a couple of which I've added
to my already extensive 'Arduino Code' bookmarks.

As per my opening post, I am already stepping through the Elegoo tutorials, some 37
projects. And dipping in and out of two other sets.

As also explained, I don't want to master either C or C++. I want to reach the stage
I described: minimal competence for a copy/paste/edit approach.


https://en.wikipedia.org/wiki/Cargo_cult_programming

The number of circuits that are cobbled together from app notes is
large, but dwarfed by the number of Frankenprograms made by cut-n-paste
from Stack Overflow.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Terry Pinnell]

"Rodney Pont" <mlist4@infohit.me.uk> wrote:

On Fri, 31 May 2019 11:48:07 +0100, Terry Pinnell wrote:

I bought my first Arduino UNO R3 kit two weeks ago (the Elegoo Super Starter kit)
and am stepping through its tutorials. In parallel I'm trying to learn the basics of
its C++ based programming language, but that's proving a struggle. I'm impatient to
use Arduino on my own projects so I will take a 'copy/paste/edit' approach. It then
becomes a matter of finding sketches that cover a particular subject and then
tailoring.

I'd therefore appreciate recommendations on Arduino sketch sources that others have
found useful please.

I found books easier to get on with than on screen things
Me too.

but I'm an oldie
Me too.

and a long term programmer.
Not me.

I'm currently ploughing through Simon Monk's 'Programming Arduino, 2nd Edition'.
Quite readable up to his first complex example, flashing Morse code to the LED from
the serial monitor), mainly because of its use of arrays within arrays ;-(

Arduino for Dummies is good for getting used to Arduino with worked
examples.

Went straight to your next recommendation as I hope Monk's book and the online
tutorials I'm studying will get me to a stage I can benefit from the Margolis.

Arduino Cookbook published by O'Reilly is also very good and goes into
programming techniques such as loops, decision structures and variable
types.
Looks good, although pretty expensive at Ł24 (~ $30), but have just ordered.

I presume those would be useful to a started in programming. It
states the problem (such as You want to send text and data from your
Arduino to your pc) and then shows a solution.

Thanks, appreciated.

Terry, East Grinstead, UK

 

[Tom Gardner]

On 01/06/19 16:32, Phil Hobbs wrote:

The number of circuits that are cobbled together from app notes is large, but
dwarfed by the number of Frankenprograms made by cut-n-paste from Stack Overflow.

Ain't that the truth.

stackexchange is OK-ish for "which button do I press to
frobnitz the schlitz", but the format actively discourages
discussion and therefore understanding.

 

[Tom Gardner]

On 01/06/19 16:26, Phil Hobbs wrote:

On 6/1/19 7:33 AM, Tom Gardner wrote:
On 01/06/19 12:06, Clifford Heath wrote:
On 1/6/19 4:50 pm, Tom Gardner wrote:
What you gain on the swings you lose on the roundabouts.

While I am certainly no fan of C++ (e.g. see the C++ FQA),
one advantage of the Arduino class machines is that you are
programming against bare silicon.

If you think that 120 CPU cycles to set or clear a port pin is "bare silicon"
then I don't know what to think. That's how long "digitalWrite" takes to
perform a 2-cycle operation.

Rank beginners, such as the OP, doing blinkies and
the like won't be affected by that.


The Arduino C libraries are a really bad direction to start off in, even for
a raw beginner. They are so unnecessarily so very badly implemented.

No way am I going to defend Arduino for people that
know what they are doing.

But for rank beginners, they offer a low cost of entry
and gentle learning curve. That's valuable in those
circumstances.

Only after they even notice the limitations, will they be
in a position to do something about it.


Having an operating system in a hard real-time system can
be a real impediment and a steep learning curve.




Except for the lack of a debugger.  Arduino may be C++ish, but its debugging is
strictly 1965.

Some would regard that as an advantage

You have to /think/ before you press "run".

 

[bitrex]

On 6/1/19 11:26 AM, Phil Hobbs wrote:

On 6/1/19 7:33 AM, Tom Gardner wrote:
On 01/06/19 12:06, Clifford Heath wrote:
On 1/6/19 4:50 pm, Tom Gardner wrote:
What you gain on the swings you lose on the roundabouts.

While I am certainly no fan of C++ (e.g. see the C++ FQA),
one advantage of the Arduino class machines is that you are
programming against bare silicon.

If you think that 120 CPU cycles to set or clear a port pin is "bare
silicon" then I don't know what to think. That's how long
"digitalWrite" takes to perform a 2-cycle operation.

Rank beginners, such as the OP, doing blinkies and
the like won't be affected by that.


The Arduino C libraries are a really bad direction to start off in,
even for a raw beginner. They are so unnecessarily so very badly
implemented.

No way am I going to defend Arduino for people that
know what they are doing.

But for rank beginners, they offer a low cost of entry
and gentle learning curve. That's valuable in those
circumstances.

Only after they even notice the limitations, will they be
in a position to do something about it.


Having an operating system in a hard real-time system can
be a real impediment and a steep learning curve.




Except for the lack of a debugger.  Arduino may be C++ish, but its
debugging is strictly 1965.

Cheers

Phil Hobbs

aside from the maybe 2-5% of a code that's uP-specific I generally just
sketch out all the functional blocks and algorithms as if I'm writing
and debugging a console application and do any required debugging on the
desktop IDE, using a set of stem functions for the
implementation-specific uP stuff.

Then just port the code like any other code-porting job. If you've kept
the capabilities of your target hardware in mind wrt resources and clock
speed etc. generally it basically works first time and the rest is
performance tuning, not head-scratching trying to debug why some
untested algorithm isn't working on the 8 or 32 bit bare-metal processor
itself. It's what using a portable language is all about really!

 

[bitrex]

On 6/1/19 5:18 PM, bitrex wrote:

On 6/1/19 11:26 AM, Phil Hobbs wrote:
On 6/1/19 7:33 AM, Tom Gardner wrote:
On 01/06/19 12:06, Clifford Heath wrote:
On 1/6/19 4:50 pm, Tom Gardner wrote:
What you gain on the swings you lose on the roundabouts.

While I am certainly no fan of C++ (e.g. see the C++ FQA),
one advantage of the Arduino class machines is that you are
programming against bare silicon.

If you think that 120 CPU cycles to set or clear a port pin is "bare
silicon" then I don't know what to think. That's how long
"digitalWrite" takes to perform a 2-cycle operation.

Rank beginners, such as the OP, doing blinkies and
the like won't be affected by that.


The Arduino C libraries are a really bad direction to start off in,
even for a raw beginner. They are so unnecessarily so very badly
implemented.

No way am I going to defend Arduino for people that
know what they are doing.

But for rank beginners, they offer a low cost of entry
and gentle learning curve. That's valuable in those
circumstances.

Only after they even notice the limitations, will they be
in a position to do something about it.


Having an operating system in a hard real-time system can
be a real impediment and a steep learning curve.




Except for the lack of a debugger.  Arduino may be C++ish, but its
debugging is strictly 1965.

Cheers

Phil Hobbs


aside from the maybe 2-5% of a code that's uP-specific I generally just
sketch out all the functional blocks and algorithms as if I'm writing
and debugging a console application and do any required debugging on the
desktop IDE, using a set of stem functions for the
implementation-specific uP stuff.

Then just port the code like any other code-porting job. If you've kept
the capabilities of your target hardware in mind wrt resources and clock
speed etc. generally it basically works first time and the rest is
performance tuning, not head-scratching trying to debug why some
untested algorithm isn't working on the 8 or 32 bit bare-metal processor
itself. It's what using a portable language is all about really!

premature optimization is the ROOT OF ALL EVIL and even most realtime uP
applications do not have to be written in hand-coded ASM or C like
everything needs blazing performance.

The bulk of it can be just written in friendly object-oriented design
patterns using most of the same niceties you have when writing a console
application for a desktop.

 

[John Miles, KE5FX]

On Saturday, June 1, 2019 at 3:06:15 AM UTC-7, Cursitor Doom wrote:

On Fri, 31 May 2019 17:02:54 -0700, John Miles, KE5FX wrote:

The advice to start with K&R C is OK as far as it goes,
but it's akin to telling an electronics novice to start with
vacuum tubes.

What's wrong with that?

For one thing, you'll be outcompeted by people who spent the same amount
of time learning modern techniques.

For another, people who advocate K&R C are looking through rose-colored
glasses to some extent. There is some genuinely crappy code in that
book, and some of the decisions made in the early history of C and
its standard library have probably cost us hundreds of billions of dollars.
Remember, this is the generation of programmers who thought scanf() and
strcat() were good ideas. K&R deserves a prominent place on the shelf,
but in a museum rather than a bookstore.

-- john, KE5FX

 

[Phil Hobbs]

On 6/1/19 2:03 PM, Tom Gardner wrote:

On 01/06/19 16:26, Phil Hobbs wrote:
On 6/1/19 7:33 AM, Tom Gardner wrote:
On 01/06/19 12:06, Clifford Heath wrote:
On 1/6/19 4:50 pm, Tom Gardner wrote:
What you gain on the swings you lose on the roundabouts.

While I am certainly no fan of C++ (e.g. see the C++ FQA),
one advantage of the Arduino class machines is that you are
programming against bare silicon.

If you think that 120 CPU cycles to set or clear a port pin is "bare
silicon" then I don't know what to think. That's how long
"digitalWrite" takes to perform a 2-cycle operation.

Rank beginners, such as the OP, doing blinkies and
the like won't be affected by that.


The Arduino C libraries are a really bad direction to start off in,
even for a raw beginner. They are so unnecessarily so very badly
implemented.

No way am I going to defend Arduino for people that
know what they are doing.

But for rank beginners, they offer a low cost of entry
and gentle learning curve. That's valuable in those
circumstances.

Only after they even notice the limitations, will they be
in a position to do something about it.


Having an operating system in a hard real-time system can
be a real impediment and a steep learning curve.




Except for the lack of a debugger.  Arduino may be C++ish, but its
debugging is strictly 1965.

Some would regard that as an advantage

You have to /think/ before you press "run".

There's not that much trouble you can get into on an ATmega, but it's
very educational to single-step your code at the assembly level. Plus
<stdio.h> isn't that small, so printf() isn't a huge help, and there's
no semihosting.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[bitrex]

On 6/1/19 8:08 PM, Phil Hobbs wrote:

Then just port the code like any other code-porting job. If you've
kept the capabilities of your target hardware in mind wrt resources
and clock speed etc. generally it basically works first time and the
rest is performance tuning, not head-scratching trying to debug why
some untested algorithm isn't working on the 8 or 32 bit bare-metal
processor itself. It's what using a portable language is all about
really!

premature optimization is the ROOT OF ALL EVIL and even most realtime
uP applications do not have to be written in hand-coded ASM or C like
everything needs blazing performance.

So what are you going to use on an ATmega, python 3 and MariaDB maybe?

Use C++, but like modern C++ with templates and namespaces and
interfaces and iterators and like, an actual structured approach to
object-oriented design, not just C code farmed out into class functions.

It all works out fine with avr-gcc for an ATMega, even. Nah just using
those features doesn't bloat the code or make it slow intrinsically,
it's very close to zero overhead abstraction and can often reduce
codebase size.

Using heavyweight algorithms or containers like std::string, or arduino
String, or vectors or tree-based data structures like maps would require
a very good reason on a platform like that, though.

 

[Lasse Langwadt Christense]

søndag den 2. juni 2019 kl. 02.08.52 UTC+2 skrev Phil Hobbs:

On 6/1/19 5:24 PM, bitrex wrote:
On 6/1/19 5:18 PM, bitrex wrote:
On 6/1/19 11:26 AM, Phil Hobbs wrote:
On 6/1/19 7:33 AM, Tom Gardner wrote:
On 01/06/19 12:06, Clifford Heath wrote:
On 1/6/19 4:50 pm, Tom Gardner wrote:
What you gain on the swings you lose on the roundabouts.

While I am certainly no fan of C++ (e.g. see the C++ FQA),
one advantage of the Arduino class machines is that you are
programming against bare silicon.

If you think that 120 CPU cycles to set or clear a port pin is
"bare silicon" then I don't know what to think. That's how long
"digitalWrite" takes to perform a 2-cycle operation.

Rank beginners, such as the OP, doing blinkies and
the like won't be affected by that.


The Arduino C libraries are a really bad direction to start off in,
even for a raw beginner. They are so unnecessarily so very badly
implemented.

No way am I going to defend Arduino for people that
know what they are doing.

But for rank beginners, they offer a low cost of entry
and gentle learning curve. That's valuable in those
circumstances.

Only after they even notice the limitations, will they be
in a position to do something about it.


Having an operating system in a hard real-time system can
be a real impediment and a steep learning curve.




Except for the lack of a debugger.  Arduino may be C++ish, but its
debugging is strictly 1965.

Cheers

Phil Hobbs


aside from the maybe 2-5% of a code that's uP-specific I generally
just sketch out all the functional blocks and algorithms as if I'm
writing and debugging a console application and do any required
debugging on the desktop IDE, using a set of stem functions for the
implementation-specific uP stuff.

Then just port the code like any other code-porting job. If you've
kept the capabilities of your target hardware in mind wrt resources
and clock speed etc. generally it basically works first time and the
rest is performance tuning, not head-scratching trying to debug why
some untested algorithm isn't working on the 8 or 32 bit bare-metal
processor itself. It's what using a portable language is all about
really!

premature optimization is the ROOT OF ALL EVIL and even most realtime uP
applications do not have to be written in hand-coded ASM or C like
everything needs blazing performance.

So what are you going to use on an ATmega, python 3 and MariaDB maybe?

not enough layers of abstraction and interpretation to be considered cool

 

[Tom Gardner]

On 02/06/19 00:56, Phil Hobbs wrote:

On 6/1/19 2:03 PM, Tom Gardner wrote:
On 01/06/19 16:26, Phil Hobbs wrote:
On 6/1/19 7:33 AM, Tom Gardner wrote:
On 01/06/19 12:06, Clifford Heath wrote:
On 1/6/19 4:50 pm, Tom Gardner wrote:
What you gain on the swings you lose on the roundabouts.

While I am certainly no fan of C++ (e.g. see the C++ FQA),
one advantage of the Arduino class machines is that you are
programming against bare silicon.

If you think that 120 CPU cycles to set or clear a port pin is "bare
silicon" then I don't know what to think. That's how long "digitalWrite"
takes to perform a 2-cycle operation.

Rank beginners, such as the OP, doing blinkies and
the like won't be affected by that.


The Arduino C libraries are a really bad direction to start off in, even
for a raw beginner. They are so unnecessarily so very badly implemented.

No way am I going to defend Arduino for people that
know what they are doing.

But for rank beginners, they offer a low cost of entry
and gentle learning curve. That's valuable in those
circumstances.

Only after they even notice the limitations, will they be
in a position to do something about it.


Having an operating system in a hard real-time system can
be a real impediment and a steep learning curve.




Except for the lack of a debugger.  Arduino may be C++ish, but its debugging
is strictly 1965.

Some would regard that as an advantage

You have to /think/ before you press "run".

There's not that much trouble you can get into on an ATmega, but it's very
educational to single-step your code at the assembly level.  Plus <stdio.h
isn't that small, so printf() isn't a huge help, and there's no semihosting.

Just so, on all counts.

It can be very entertaining looking at heavily optimised
C code, and single stepping it for that matter. Obfuscated
is the word that springs to mind.

 

[Phil Hobbs]

On 6/1/19 5:24 PM, bitrex wrote:

On 6/1/19 5:18 PM, bitrex wrote:
On 6/1/19 11:26 AM, Phil Hobbs wrote:
On 6/1/19 7:33 AM, Tom Gardner wrote:
On 01/06/19 12:06, Clifford Heath wrote:
On 1/6/19 4:50 pm, Tom Gardner wrote:
What you gain on the swings you lose on the roundabouts.

While I am certainly no fan of C++ (e.g. see the C++ FQA),
one advantage of the Arduino class machines is that you are
programming against bare silicon.

If you think that 120 CPU cycles to set or clear a port pin is
"bare silicon" then I don't know what to think. That's how long
"digitalWrite" takes to perform a 2-cycle operation.

Rank beginners, such as the OP, doing blinkies and
the like won't be affected by that.


The Arduino C libraries are a really bad direction to start off in,
even for a raw beginner. They are so unnecessarily so very badly
implemented.

No way am I going to defend Arduino for people that
know what they are doing.

But for rank beginners, they offer a low cost of entry
and gentle learning curve. That's valuable in those
circumstances.

Only after they even notice the limitations, will they be
in a position to do something about it.


Having an operating system in a hard real-time system can
be a real impediment and a steep learning curve.




Except for the lack of a debugger.  Arduino may be C++ish, but its
debugging is strictly 1965.

Cheers

Phil Hobbs


aside from the maybe 2-5% of a code that's uP-specific I generally
just sketch out all the functional blocks and algorithms as if I'm
writing and debugging a console application and do any required
debugging on the desktop IDE, using a set of stem functions for the
implementation-specific uP stuff.

Then just port the code like any other code-porting job. If you've
kept the capabilities of your target hardware in mind wrt resources
and clock speed etc. generally it basically works first time and the
rest is performance tuning, not head-scratching trying to debug why
some untested algorithm isn't working on the 8 or 32 bit bare-metal
processor itself. It's what using a portable language is all about
really!

premature optimization is the ROOT OF ALL EVIL and even most realtime uP
applications do not have to be written in hand-coded ASM or C like
everything needs blazing performance.

So what are you going to use on an ATmega, python 3 and MariaDB maybe?

The bulk of it can be just written in friendly object-oriented design
patterns using most of the same niceties you have when writing a console
application for a desktop.

Niceties = subtleties, not nice things.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

Lasse Langwadt Christensen <langwadt@fonz.dk> wrote in
news:4732e0ba-0ebf-414d-90e4-7295ac94288d@googlegroups.com:

in what way? you are comparing a bicycle to a jetliner

Trying to use an adruino to control somthing..

Sounds like iOT stuff.

That hummingboard has plenty of control hooks and interface
options.

So depending on the application one chooses what one thinks is
appropriate.

Solid Run is the Cadillac of the genre.

Adruino is the tricycle.

So yeah... I guess you are right.

But I do not need to call it a Lear Jet.

'Bayliner' is supposed to be 'the Cadillac of Boats' for us middle
class consumers, so the Cadillac comparison is enough.

 

[Jan Panteltje]

On a sunny day (Sat, 1 Jun 2019 15:06:46 -0700 (PDT)) it happened "John Miles,
KE5FX" <jmiles@gmail.com> wrote in
<ab2c7bed-385d-4dec-b1de-57eecae0e819@googlegroups.com>:

On Saturday, June 1, 2019 at 3:06:15 AM UTC-7, Cursitor Doom wrote:
On Fri, 31 May 2019 17:02:54 -0700, John Miles, KE5FX wrote:

The advice to start with K&R C is OK as far as it goes,
but it's akin to telling an electronics novice to start with
vacuum tubes.

What's wrong with that?

For one thing, you'll be outcompeted by people who spent the same amount
of time learning modern techniques.

For another, people who advocate K&R C are looking through rose-colored
glasses to some extent. There is some genuinely crappy code in that
book, and some of the decisions made in the early history of C and
its standard library have probably cost us hundreds of billions of dollars.
Remember, this is the generation of programmers who thought scanf() and
strcat() were good ideas. K&R deserves a prominent place on the shelf,
but in a museum rather than a bookstore.

-- john, KE5FX

You should read and study libc.info.
As to 'objects' if you know how to use structures and linked lists
then you never ever need seeplushplush.

Basic programming is beyond playing with snakes and an other language each year [1].
C is extremely powerful very efficient.
The argument 'I Do Not Want To Know How To Program So I use SeePlushPlush'
if for kindergarten tinkers.

Somebody having trouble understanding the programming basics
then goes and writes a 'new' language,
after 3 version iterations it is still worthless crap.

This was with plusplus, is with python.
I wastes everybody's time having to try to follow the idiots wrong ideas.


Long ago there was a magazine 'Dr Dobbs', do not know if it still exists.
but I sure picked up a lot of programming methods from that,
And that, over time, proved very valuable,
no matter what 'language' you scribble in,
but C is easiest to apply those techniques.

 

[Clifford Heath]

On 2/6/19 12:19 am, Rodney Pont wrote:

On Sat, 1 Jun 2019 21:06:36 +1000, Clifford Heath wrote:

The Arduino C libraries are a really bad direction to start off in, even
for a raw beginner. They are so unnecessarily so very badly implemented.

A lot of the C/C++ libraries seem to have been written by people who
are out to prove how clever they are. Some I understood what they were
doing and managed to use them but there were a lot more that just
didn't have sufficiently clear documentation for me to use them. I've
been using 'objects' for nearly thirty years and get along with them
but I found it hard to understand how the developer got from there to
here if you see what I mean.

Tend to agree, but what can you expect for nothing? OTOH it can be done
well. How do you find this C++ and documentation:
<https://github.com/cjheath/AD9959>?

Clifford Heath.

 

[Clifford Heath]

On 2/6/19 8:06 am, John Miles, KE5FX wrote:

On Saturday, June 1, 2019 at 3:06:15 AM UTC-7, Cursitor Doom wrote:
On Fri, 31 May 2019 17:02:54 -0700, John Miles, KE5FX wrote:

The advice to start with K&R C is OK as far as it goes,
but it's akin to telling an electronics novice to start with
vacuum tubes.

What's wrong with that?

For one thing, you'll be outcompeted by people who spent the same amount
of time learning modern techniques.

For another, people who advocate K&R C are looking through rose-colored
glasses to some extent. There is some genuinely crappy code in that
book, and some of the decisions made in the early history of C and
its standard library have probably cost us hundreds of billions of dollars.

The most costly mistake in the history of programming has to be "errno",
from Unix. DOS and Windows copied it, more or less.

Recall "Unknown error 0x80000000"? We Unix folk used to laugh, but it's
just what you get when a call returns -1 or NULL without setting errno.

EPERM: "Permission denied" - What permission was needed? To access what
operation on what object? - The kernel knew these things, but didn't say.

ENOENT: "No such file or directory" - Well which is it, a file or a
directory? Perchance you'd like to tell me which one?

Those are just the first two errors in errno. It doesn't get any better.
Windows has literally millions of such error codes, because they break
it up as a 16 bit value under a 12-bit "facility code".

This is the root of *most* user frustration and time lost with computer
systems. We expect things to go wrong, but we also expect to be told
what, and why, and how we can fix it.

Clifford Heath.

 

[John Miles, KE5FX]

On Sunday, June 2, 2019 at 12:42:43 AM UTC-7, Clifford Heath wrote:

Tend to agree, but what can you expect for nothing? OTOH it can be done
well. How do you find this C++ and documentation:
https://github.com/cjheath/AD9959>?

That's an amusing coincidence. I spent this afternoon duct-taping
an AD9959 demo board to a Mega2560 for a one-off production test rig,
when I wasn't on here arguing with (seemingly drunk) people about C.

The board refused to put out a signal at first, and having seen your page
in the Google results for 'AD9959', I was tempted to crib your register
settings from it. It eventually occurred to me to run the ADI software
and dump its registers for comparison, but your source code was going to
be the next resort if that hadn't worked.

Looks good to me, for what that's worth.

-- john, KE5FX

 

[Jan Panteltje]

On a sunny day (Sun, 2 Jun 2019 17:55:07 +1000) it happened Clifford Heath
<no.spam@please.net> wrote in <xhLIE.27461$NT5.464@fx47.iad>:

On 2/6/19 8:06 am, John Miles, KE5FX wrote:
On Saturday, June 1, 2019 at 3:06:15 AM UTC-7, Cursitor Doom wrote:
On Fri, 31 May 2019 17:02:54 -0700, John Miles, KE5FX wrote:

The advice to start with K&R C is OK as far as it goes,
but it's akin to telling an electronics novice to start with
vacuum tubes.

What's wrong with that?

For one thing, you'll be outcompeted by people who spent the same amount
of time learning modern techniques.

For another, people who advocate K&R C are looking through rose-colored
glasses to some extent. There is some genuinely crappy code in that
book, and some of the decisions made in the early history of C and
its standard library have probably cost us hundreds of billions of dollars.

The most costly mistake in the history of programming has to be "errno",
from Unix. DOS and Windows copied it, more or less.

Recall "Unknown error 0x80000000"? We Unix folk used to laugh, but it's
just what you get when a call returns -1 or NULL without setting errno.

Probably the programmer screwed up in that case.
Read the documentation for that function if it is in libc.
Lemme state that if you really do not know what is happeing you should not be programming.

(operator overloading in seeplushplush comes to mind)

Why do I NEVER have those problems?

Well I dunno.

What I usually do in C is have a printf() at the start of each function, that can be activated by running the thing
with a command line flag:
my_program -v 1
for level 1 debugging
That printf then prints the function name and arguments.
Like this for example:

char *my_function_do_something(int a, char *b, int *result)
{
int b;

if(verbose)
{
fprintf(stderr, "my_function_do_something(): arg a=%d b=%p result=%p\n", a, b, result);
}

/* parameter check */
if(a < 10) return 0;
if(a > 20) return 0;
if(! b) return 0;
if(! result) return 0;

// do something
if(! calculation(a, &b) ) // calculation will say what is wrong in verbose mode
{
return 0;
}

*result = a * 1234;

if(*result == NAN) // LOL
{
if(verbose)
{
fprintf(stderr "my_function_do_something(): calculation() returned out of range value %d for *result\n", *result);
}

return 0;
}

i(verbose)
{
fprintf(stderr, "my_function_do_something(): returning *result=%d\n", *result);
}

// OK
return 1;
}



called like

if(! my_function_do_something(x, some_string, &a) )
{
return 0;
// could optionally exit here
}

If you put the error report in every function that way,
then you see any problems in verbose mode in a few seconds.
Also you see any silly number mistakes you made.

For errno again check the library documentation.

I have not used a debugger since 1984 or so when I wrote one...

EPERM: "Permission denied" - What permission was needed? To access what
operation on what object? - The kernel knew these things, but didn't say.

ENOENT: "No such file or directory" - Well which is it, a file or a
directory? Perchance you'd like to tell me which one?

Those are just the first two errors in errno. It doesn't get any better.
Windows has literally millions of such error codes, because they break
it up as a 16 bit value under a 12-bit "facility code".

This is the root of *most* user frustration and time lost with computer
systems. We expect things to go wrong, but we also expect to be told
what, and why, and how we can fix it.

Clifford Heath.

libc.info is good.
I you have never heard of it (it should be on your Linux system) then try this old version in text form:
http://www.panteltje.com/pub/libc.info.txt

What are you going to do without it?
Networking? memory management? math? threads?
All C library functions are treated there, many with examples.

It is my C programming reference, I just use the text editor search function on it.

Maybe the extra fprintf(stderr is more work.
But it stil saves time.
Especialy when you write code incrementally.
For more complex problems I often start wih text
/* do this */
/* do that */
/* do something different */

and fill in the code later.
Turing
its simple

seeplusplush is a crime against humanity.
There were days not even the seeplushplush compiler writers could agree what the syntax meant.
Did not get better, now NOBODY knows it

 

Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> wrote in
news:qd05h7$as3$1@dont-email.me:

> seeplusplush is a crime against humanity.

A little bit more than just a bit opinionated and narrow
vissioned.

There were days not even the seeplushplush compiler writers could
agree what the syntax meant.

In YOUR clics. In some here too... But certainly not all. Just
because one brain is of a fucked mindset doesn't mean the whole
troup has to do push ups.

Did not get better, now NOBODY knows
it

Now, there are TrumpTardesque idiots everywhere whom actually
think they are of some vast intelligence, when in fact, they are,
just like Trump, in possession of very little substantive content,
much less intelligence. And just like TrumpTardesque-ish dopes,
there is always someone there to declare the entire cart bad because
of the presence of one bad apple. And that is a serious flaw in
those particular observers.