Arduino code sources?

Not a bad method.

I taught myself circuit design largely by reading app notes, assuming that all the circuits were junk, and figuring out why. (Some of them are okay, of course, but you can always think about input protection and so forth.)

Cheers

Phil Hobbs

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

Some would regard that as an advantage :)

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

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.

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.

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

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 isn't that small, so printf() isn't a huge help, and there's no semihosting.

Cheers

Phil Hobbs

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

Niceties = subtleties, not nice things. ;)

Cheers

Phil Hobbs

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.

ts

not enough layers of abstraction and interpretation to be considered cool ; )

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 Christensen wrote in news: snipped-for-privacy@googlegroups.com:

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.

On a sunny day (Sat, 1 Jun 2019 15:06:46 -0700 (PDT)) it happened "John Miles, KE5FX" wrote in :

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.

Tend to agree, but what can you expect for nothing? OTOH it can be done well. How do you find this C++ and documentation: ?

Clifford Heath.

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.

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

On a sunny day (Sun, 2 Jun 2019 17:55:07 +1000) it happened Clifford Heath wrote in :

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; }

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...

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:

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 wrote in news:qd05h7$as3$ snipped-for-privacy@dont-email.me:

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

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

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.