C
Cursitor Doom
Guest
On Sun, 02 Jun 2019 09:39:37 +0000, Jan Panteltje wrote:
> seeplusplush is a crime against humanity.
+1
> seeplusplush is a crime against humanity.
+1
C
Clifford Heath
Guest
On 2/6/19 7:39 pm, Jan Panteltje wrote:
Yes. But they followed the paradigm that you can only return one integer
as an error indication. That's the problem. Functions need a way to
efficiently return more error information. Programmers should not follow
that pattern. But fprintf(stderr...) is unacceptable as well (see below).
int fd = open("/a/b/c/d", 0)
if (fd < 0)
{
// Even after looking at errno, I have no fucking idea what went wrong.
}
What part of the above is difficult for you to understand?
Jan, I've read your code. I've worked in C for 40 years, with many
dozens of good C programmers, and though I think you're a terribly
clever guy, having seen your code, I would never recommend my boss to
hire you. Your code is worse than your pencil-drawn schematics, and
that's really saying something. You get stuff done, but pity the poor
bloke who comes after.
You can't build library code that way. It may be ok for command-line
prototypes and open source trash, but no software product can do that.
I have worked with Unix since the 1970s. I have no need of such trinkets.
Clifford Heath.
Yes. But they followed the paradigm that you can only return one integer
as an error indication. That's the problem. Functions need a way to
efficiently return more error information. Programmers should not follow
that pattern. But fprintf(stderr...) is unacceptable as well (see below).
int fd = open("/a/b/c/d", 0)
if (fd < 0)
{
// Even after looking at errno, I have no fucking idea what went wrong.
}
What part of the above is difficult for you to understand?
Jan, I've read your code. I've worked in C for 40 years, with many
dozens of good C programmers, and though I think you're a terribly
clever guy, having seen your code, I would never recommend my boss to
hire you. Your code is worse than your pencil-drawn schematics, and
that's really saying something. You get stuff done, but pity the poor
bloke who comes after.
You can't build library code that way. It may be ok for command-line
prototypes and open source trash, but no software product can do that.
I have worked with Unix since the 1970s. I have no need of such trinkets.
Clifford Heath.
C
Clifford Heath
Guest
On 2/6/19 6:53 pm, John Miles, KE5FX wrote:
I've not used it yet, and have a report of endian problems, and perhaps
others. Please report issues if you find them
. But I'm proud of the
documentation and testing structure (it took several days studying the
data sheet to design!), and will hopefully get to test it myself soon.
Clifford Heath
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.
I've not used it yet, and have a report of endian problems, and perhaps
others. Please report issues if you find them
. But I'm proud of the documentation and testing structure (it took several days studying the
data sheet to design!), and will hopefully get to test it myself soon.
Clifford Heath
C
Cursitor Doom
Guest
On Sun, 02 Jun 2019 22:57:19 +1000, Clifford Heath wrote:
You should see his soldering!
You should see his soldering!
J
Jan Panteltje
Guest
On a sunny day (Sun, 2 Jun 2019 22:57:19 +1000) it happened Clifford Heath
<no.spam@please.net> wrote in <RIPIE.36172$xY3.34375@fx01.iad>:
What went wrong is that 'open' failed
You the rewite the code like this:
int fd = open("/a/b/c/d", 0)
if (fd < 0)
{
fprintf(stderr, "Could not open file "a/b/c/d for read ");
perror("because");
return ERROR (whatever your logic for error is);
// if you think he user is a moron, then you can do a test for the directory chain.
or if it is some GUI stuff pop up an error message on screen.
in libforms fl_show_alert(),
and also do the stderr,
}
Anyways I would normally use fopen(), quoting libc.info:
The 'open' function is the underlying primitive for the 'fopen'
and 'freopen' functions, that create streams.
Thank you, I see it a bit less that way, but OK, I surrender here (brushes up ego).
Well that is kind of you, one worry less.
Your code is worse than your pencil-drawn schematics, and
Well maybe you have accumulated a bit of rust that causes you to not see other solutions as those are.
I still do not see the problems you claim to exist.
Oh yes it can, and you will be ever so happy if a user has a problem with your code
you can have them execute it from a terminal and send you the text.
That is a very very stupid remark.
<no.spam@please.net> wrote in <RIPIE.36172$xY3.34375@fx01.iad>:
What went wrong is that 'open' failed
You the rewite the code like this:
int fd = open("/a/b/c/d", 0)
if (fd < 0)
{
fprintf(stderr, "Could not open file "a/b/c/d for read ");
perror("because");
return ERROR (whatever your logic for error is);
// if you think he user is a moron, then you can do a test for the directory chain.
or if it is some GUI stuff pop up an error message on screen.
in libforms fl_show_alert(),
and also do the stderr,
}
Anyways I would normally use fopen(), quoting libc.info:
The 'open' function is the underlying primitive for the 'fopen'
and 'freopen' functions, that create streams.
Thank you, I see it a bit less that way, but OK, I surrender here (brushes up ego).
Well that is kind of you, one worry less.
Your code is worse than your pencil-drawn schematics, and
Well maybe you have accumulated a bit of rust that causes you to not see other solutions as those are.
I still do not see the problems you claim to exist.
Oh yes it can, and you will be ever so happy if a user has a problem with your code
you can have them execute it from a terminal and send you the text.
That is a very very stupid remark.
C
Cursitor Doom
Guest
On Sun, 02 Jun 2019 15:05:58 +0000, Jan Panteltje wrote:
That's actually an excellent tip. I must try to remember that for future
use.
--
This message may be freely reproduced without limit or charge only via
the Usenet protocol. Reproduction in whole or part through other
protocols, whether for profit or not, is conditional upon a charge of
GBP10.00 per reproduction. Publication in this manner via non-Usenet
protocols constitutes acceptance of this condition.
That's actually an excellent tip. I must try to remember that for future
use.
--
This message may be freely reproduced without limit or charge only via
the Usenet protocol. Reproduction in whole or part through other
protocols, whether for profit or not, is conditional upon a charge of
GBP10.00 per reproduction. Publication in this manner via non-Usenet
protocols constitutes acceptance of this condition.
B
bitrex
Guest
On 6/2/19 8:09 PM, bitrex wrote:
Or for longer programs close enough to real-time. Modern C/C++ compiler
running on a core i-something class processor are perfectly capable of
compiling and optimizing a 5,000 or 10,000 line small to medium-size uP
project codebase in under a second or two.
You can look thru the steps of the optimization process as it parses the
code down and optimizes it thru multiple passes, in 2019 "multi-pass
compilation" often means dozens or hundreds of passes.
Or for longer programs close enough to real-time. Modern C/C++ compiler
running on a core i-something class processor are perfectly capable of
compiling and optimizing a 5,000 or 10,000 line small to medium-size uP
project codebase in under a second or two.
You can look thru the steps of the optimization process as it parses the
code down and optimizes it thru multiple passes, in 2019 "multi-pass
compilation" often means dozens or hundreds of passes.
B
bitrex
Guest
On 6/1/19 8:13 PM, Tom Gardner wrote:
there are plug-ins for other IDEs you can develop Arduino code with that
will show you the optimized asm your C/C++ code generates for AVR, ARM,
MSP430, MIPS, etc on the fly, in real-time as you type
there are plug-ins for other IDEs you can develop Arduino code with that
will show you the optimized asm your C/C++ code generates for AVR, ARM,
MSP430, MIPS, etc on the fly, in real-time as you type
C
Clifford Heath
Guest
On 3/6/19 1:05 am, Jan Panteltje wrote:
I don't like GNU "info" is all. Or anything that forces me to remember
my rusty EMACs keystrokes. I just use the man pages. "man 2 open" works
pretty well.
I don't like GNU "info" is all. Or anything that forces me to remember
my rusty EMACs keystrokes. I just use the man pages. "man 2 open" works
pretty well.
C
Clifford Heath
Guest
On 3/6/19 10:09 am, bitrex wrote:
I've just hand-built a Makefile for a client's SAMD Arduino project that
allows it to be compiled inside an Atmel Studio project so we can debug
USB re-enumeration issues. Contrary to what it says on the tin, Atmel
Studio cannot create such a Makefile for an Arduino project
automatically - it doesn't even get close, I tried.
I have no idea why the original author thought it was reasonable to
attempt to develop a 10KLOC commercial product using Arduino. Least of
all a SAMD product - the BOSSA code loader is the biggest load of shite
I've come across in years, and the author doesn't seem to even care, so
I'll name-and-shame him:
<https://github.com/shumatech/BOSSA/pull/98>
Clifford Heath.
I've just hand-built a Makefile for a client's SAMD Arduino project that
allows it to be compiled inside an Atmel Studio project so we can debug
USB re-enumeration issues. Contrary to what it says on the tin, Atmel
Studio cannot create such a Makefile for an Arduino project
automatically - it doesn't even get close, I tried.
I have no idea why the original author thought it was reasonable to
attempt to develop a 10KLOC commercial product using Arduino. Least of
all a SAMD product - the BOSSA code loader is the biggest load of shite
I've come across in years, and the author doesn't seem to even care, so
I'll name-and-shame him:
<https://github.com/shumatech/BOSSA/pull/98>
Clifford Heath.
J
Jasen Betts
Guest
On 2019-06-03, Clifford Heath <no.spam@please.net> wrote:
there are other info clients, but I dont read info pages often enough
to reccomend one, I seem to recall that at-least one has a GUI.
--
When I tried casting out nines I made a hash of it.
there are other info clients, but I dont read info pages often enough
to reccomend one, I seem to recall that at-least one has a GUI.
--
When I tried casting out nines I made a hash of it.
C
Clifford Heath
Guest
On 3/6/19 1:05 am, Jan Panteltje wrote:
and duplicate the logic of the kernel "namei" method? Have you ever read
that logic? There is a surprisingly large amount of it. Its madness to
either expect the programmer to reconstruct the failure (hint: it's
possible that all the directories and files exist, but "b" is not
searchable, for example), or to simply expect that every user will know
this logic and be able to determine what went wrong.
The kernel alone knows *precisely* what went wrong and why, but did not
show anyone the basic *respect* of telling them.
"I can't open /a/b/c/d because although /a/b exists, it is not marked as
searchable so I cant see /a/b/c" - there, that wasn't so hard now, was it?
It is this basic lack of *respect* (so endemic in the industry) which
creates the kind of user rage and frustration that is sadly all too
common. The simple principle of *showing respect* to your users can
change that. But you prefer just to call them as morons, because it gets
you off the hook. The fish rots from the head. If the kernel doesn't do
it in syscalls, the programmers just say WTF and give up trying.
Clifford Heath.
and duplicate the logic of the kernel "namei" method? Have you ever read
that logic? There is a surprisingly large amount of it. Its madness to
either expect the programmer to reconstruct the failure (hint: it's
possible that all the directories and files exist, but "b" is not
searchable, for example), or to simply expect that every user will know
this logic and be able to determine what went wrong.
The kernel alone knows *precisely* what went wrong and why, but did not
show anyone the basic *respect* of telling them.
"I can't open /a/b/c/d because although /a/b exists, it is not marked as
searchable so I cant see /a/b/c" - there, that wasn't so hard now, was it?
It is this basic lack of *respect* (so endemic in the industry) which
creates the kind of user rage and frustration that is sadly all too
common. The simple principle of *showing respect* to your users can
change that. But you prefer just to call them as morons, because it gets
you off the hook. The fish rots from the head. If the kernel doesn't do
it in syscalls, the programmers just say WTF and give up trying.
Clifford Heath.
B
bitrex
Guest
On 6/2/19 9:10 PM, Clifford Heath wrote:
I would never try to develop a commercial product that size within the
Arduino IDE/environment, hell no. It's fine for little jobs and
proofs-of-concept.
Large projects I write, prototype and debug all the algorithms and
classes and components, in portable C++, as if I'm writing an
application for a desktop x86 machine.
Then port it over. I often use tools like Compiler Explorer to look at
the generated ASM for the AVR or ARM for some functional component if
I'm unsure of what kind of code will be generated.
Most code even for uPs is processor-agnostic and will comprise only a
tiny fraction of the execution time of a given program so there's no
point to try to heavily optimize it for execution speed. The uP-specific
or Arduino-specific stuff like manipulating pins and reading/writing
from the serial port, and optimizing those parts if necessary, is the
last part I work on, once everything else is debugged, checked for
errors by a static analyzer (as configured by default the Arduino IDE
SUCKS at reporting potentially catastrophic mistakes), and working as
near perfect as possible in a test-driven development situation. And
avr-gcc and arm-gcc tend to generate very compact code, even from
template-heavy C++11.
Obviously keeping in mind the resource limitations of the processor it
will end up running on. that's not very hard to do. You can't just use
dynamically-allocated memory except in certain cases, but sometimes it's
just fine and helpful. Dynamically allocating a small object that's
destroyed/deleted at the end of a function call, where ownership of the
resource-holding pointer isn't transferred anywhere else, isn't really
any more dangerous than a stack allocation even on an 8 bit machine.
A use case is iterators that allow you to iterate over lists of things
of arbitrary size without having to hardcode the list size into the
function call. The dynamically allocated object within a function call
is the Iterator object. C++ doesn't support variable-length arrays. It's
good programming practice to never touch raw storage like C-style arrays
when you just need to look at what is contained, and in C++ it's very
straightforward to write an iterable List class that can hold lists of
arbitrary stuff (use a template) of arbitrary size and is very
efficient, even on 8 bit.
I would never try to develop a commercial product that size within the
Arduino IDE/environment, hell no. It's fine for little jobs and
proofs-of-concept.
Large projects I write, prototype and debug all the algorithms and
classes and components, in portable C++, as if I'm writing an
application for a desktop x86 machine.
Then port it over. I often use tools like Compiler Explorer to look at
the generated ASM for the AVR or ARM for some functional component if
I'm unsure of what kind of code will be generated.
Most code even for uPs is processor-agnostic and will comprise only a
tiny fraction of the execution time of a given program so there's no
point to try to heavily optimize it for execution speed. The uP-specific
or Arduino-specific stuff like manipulating pins and reading/writing
from the serial port, and optimizing those parts if necessary, is the
last part I work on, once everything else is debugged, checked for
errors by a static analyzer (as configured by default the Arduino IDE
SUCKS at reporting potentially catastrophic mistakes), and working as
near perfect as possible in a test-driven development situation. And
avr-gcc and arm-gcc tend to generate very compact code, even from
template-heavy C++11.
Obviously keeping in mind the resource limitations of the processor it
will end up running on. that's not very hard to do. You can't just use
dynamically-allocated memory except in certain cases, but sometimes it's
just fine and helpful. Dynamically allocating a small object that's
destroyed/deleted at the end of a function call, where ownership of the
resource-holding pointer isn't transferred anywhere else, isn't really
any more dangerous than a stack allocation even on an 8 bit machine.
A use case is iterators that allow you to iterate over lists of things
of arbitrary size without having to hardcode the list size into the
function call. The dynamically allocated object within a function call
is the Iterator object. C++ doesn't support variable-length arrays. It's
good programming practice to never touch raw storage like C-style arrays
when you just need to look at what is contained, and in C++ it's very
straightforward to write an iterable List class that can hold lists of
arbitrary stuff (use a template) of arbitrary size and is very
efficient, even on 8 bit.
C
Clifford Heath
Guest
On 3/6/19 12:26 pm, bitrex wrote:
So would I, but that would cover less than a third of the code in this
case, since it's all about hardware access (I2S links to feed audio to a
3G modem, etc) and that's where the bugs are. It probably should have
better device driver testing, but it is what it is, not by my choice.
> ...if I'm unsure of what kind of code will be generated.
Absolutely no need for that in this case.
Yes, exactly.
Plenty of grunt here. This processor was chosen for its peripherals.
The OP
is trying to climb the hill of his first embedded C. More advanced
lessons can come later, but I wanted him to know that Arduino has
definite downsides! Atmel Studio is a much better option.
Clifford Heath.
So would I, but that would cover less than a third of the code in this
case, since it's all about hardware access (I2S links to feed audio to a
3G modem, etc) and that's where the bugs are. It probably should have
better device driver testing, but it is what it is, not by my choice.
> ...if I'm unsure of what kind of code will be generated.
Absolutely no need for that in this case.
Yes, exactly.
Plenty of grunt here. This processor was chosen for its peripherals.
Please, save your programming advice for someone who needs it
The OP is trying to climb the hill of his first embedded C. More advanced
lessons can come later, but I wanted him to know that Arduino has
definite downsides! Atmel Studio is a much better option.
Clifford Heath.
B
bitrex
Guest
On 6/2/19 11:08 PM, bitrex wrote:
<snip> BTW the purpose of the mini-rant isn't to be super-useful advice
to a total beginner, but I think it's worth thinking about when
beginning any endeavor to consider "where do I want to be in two years
time." I think it's worth thinking about how "real code" is written in
the 21st century, or should be, and ideally things will go well and one
won't want to stay in the sandbox forever.
A lot of Arduino-environment code is bad. but the tools are available so
it doesn't have to be that way, so I think it's worth thinking about how
to be at a place where one is writing _good_ code in two years time
simultaneously, code that can earn money, and not just rote-learning the
syntax. and I think that also means learning a bit about software
_engineering_ practices simultaneously and not just code-writing.
<snip> BTW the purpose of the mini-rant isn't to be super-useful advice
to a total beginner, but I think it's worth thinking about when
beginning any endeavor to consider "where do I want to be in two years
time." I think it's worth thinking about how "real code" is written in
the 21st century, or should be, and ideally things will go well and one
won't want to stay in the sandbox forever.
A lot of Arduino-environment code is bad. but the tools are available so
it doesn't have to be that way, so I think it's worth thinking about how
to be at a place where one is writing _good_ code in two years time
simultaneously, code that can earn money, and not just rote-learning the
syntax. and I think that also means learning a bit about software
_engineering_ practices simultaneously and not just code-writing.
B
bitrex
Guest
On 6/2/19 10:37 PM, Clifford Heath wrote:
"Arduino" is just an API. The Arduino-provided IDE sux balls. But you
can use the processor-specific API with an IDE of your choice though,
with a little work, just so you can use e.g. digitalWrite, analogRead,
Serial.begin etc. and not have to muck with setting up all the registers
and interrupts yourself. For many (even "professional") projects they're
fine. So maybe digitalWrite sometimes takes 100 clock cycles. BFD. Fix
it if/when you know you need to flip the pins faster.
On 3/6/19 12:26 pm, bitrex wrote:
On 6/2/19 9:10 PM, Clifford Heath wrote:
I've just hand-built a Makefile for a client's SAMD Arduino project
Large projects I write, prototype and debug all the algorithms and
classes and components, in portable C++, as if I'm writing an
application for a desktop x86 machine.
So would I, but that would cover less than a third of the code in this
case, since it's all about hardware access (I2S links to feed audio to a
3G modem, etc) and that's where the bugs are. It probably should have
better device driver testing, but it is what it is, not by my choice.
...if I'm unsure of what kind of code will be generated.
Absolutely no need for that in this case.
avr-gcc and arm-gcc tend to generate very compact code, even from
template-heavy C++11.
Yes, exactly.
Obviously keeping in mind the resource limitations of the processor it
will end up running on.
Plenty of grunt here. This processor was chosen for its peripherals.
C++ doesn't support...
It's good programming practice to...
in C++ it's very straightforward to...
Please, save your programming advice for someone who needs it
is trying to climb the hill of his first embedded C. More advanced
lessons can come later, but I wanted him to know that Arduino has
definite downsides! Atmel Studio is a much better option.
Clifford Heath.
"Arduino" is just an API. The Arduino-provided IDE sux balls. But you
can use the processor-specific API with an IDE of your choice though,
with a little work, just so you can use e.g. digitalWrite, analogRead,
Serial.begin etc. and not have to muck with setting up all the registers
and interrupts yourself. For many (even "professional") projects they're
fine. So maybe digitalWrite sometimes takes 100 clock cycles. BFD. Fix
it if/when you know you need to flip the pins faster.
B
bitrex
Guest
On 5/31/19 6:48 AM, Terry Pinnell wrote:
A "modern C++" feature that would be very helpful for uP based projects
is a smart pointer. You can't really do dynamic memory
allocation/de-allocation at will on a processor with 2k of RAM. But you
still often need to hold and transfer resources around.
What's a pointer? A pointer holds the address of a _resource_. The
ownership status of a resource must always be well-defined. A "unique
pointer" object defines ownership of a resource - the object that holds
that unique pointer object, which wraps a dumb pointer, "owns" that
resource. Unique pointers cant be copied, only moved. If an object holds
a unique pointer it cannot be copied, either, or else two owners would
exist. Nuh uh.
Sometimes other code needs to hold a reference to a resource. Some logic
would like to see what a data buffer contains, but shouldn't "own" the
buffer. So there can be an "observer pointer". It can only be used for
read-only access to the resource but cannot modify the actual resource's
state in any way. The observer container can be both copied and moved.
They can be passed to functions, even plain-C functions, taking a
const-qualified raw pointer seamlessly but cannot be passed to functions
taking a non-const qualified pointer as that would allow write access to
the resource.
An advantage of C++ is you can write code to define rule-enforcing data
structures like that to, by design, self-enforce safer further design
decisions. Along the same lines raw data types like "int" should never
be used and passed around to represent something like dollars in a bank
account, or velocity. They should be wrapped in an object that enforces
assumptions like class Dollars, or class Velocity. A function that
computes an output velocity from an input velocity should return a
Velocity and take a Velocity argument e.g. Velocity
calc_new_velocity(Velocity v) not int calc_new_velocity(int v).
And no, this almost never "bloats the code" if done intelligently the
compiler and optimizer will figure out that in almost all cases it can
compute a velocity under the hood by just manipulating the raw ints like
it would when compiling C. all the boilerplate is mostly for your
benefit so it can warn you if you try to do something stupid.
A "modern C++" feature that would be very helpful for uP based projects
is a smart pointer. You can't really do dynamic memory
allocation/de-allocation at will on a processor with 2k of RAM. But you
still often need to hold and transfer resources around.
What's a pointer? A pointer holds the address of a _resource_. The
ownership status of a resource must always be well-defined. A "unique
pointer" object defines ownership of a resource - the object that holds
that unique pointer object, which wraps a dumb pointer, "owns" that
resource. Unique pointers cant be copied, only moved. If an object holds
a unique pointer it cannot be copied, either, or else two owners would
exist. Nuh uh.
Sometimes other code needs to hold a reference to a resource. Some logic
would like to see what a data buffer contains, but shouldn't "own" the
buffer. So there can be an "observer pointer". It can only be used for
read-only access to the resource but cannot modify the actual resource's
state in any way. The observer container can be both copied and moved.
They can be passed to functions, even plain-C functions, taking a
const-qualified raw pointer seamlessly but cannot be passed to functions
taking a non-const qualified pointer as that would allow write access to
the resource.
An advantage of C++ is you can write code to define rule-enforcing data
structures like that to, by design, self-enforce safer further design
decisions. Along the same lines raw data types like "int" should never
be used and passed around to represent something like dollars in a bank
account, or velocity. They should be wrapped in an object that enforces
assumptions like class Dollars, or class Velocity. A function that
computes an output velocity from an input velocity should return a
Velocity and take a Velocity argument e.g. Velocity
calc_new_velocity(Velocity v) not int calc_new_velocity(int v).
And no, this almost never "bloats the code" if done intelligently the
compiler and optimizer will figure out that in almost all cases it can
compute a velocity under the hood by just manipulating the raw ints like
it would when compiling C. all the boilerplate is mostly for your
benefit so it can warn you if you try to do something stupid.
B
bitrex
Guest
On 6/1/19 11:32 AM, Phil Hobbs wrote:
The anti-pattern is formally called "blog-driven development."
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
The anti-pattern is formally called "blog-driven development."
B
bitrex
Guest
On 6/1/19 11:30 AM, Phil Hobbs wrote:
The only thing scarier than hardware engineers designing software is
software engineers designing hardware. Leave designing hardware to
physicists. Then the hardware engineers will be free to write software
and the software engineers can do the physics.
On 6/1/19 10:43 AM, Dennis wrote:
On 6/1/19 6:06 AM, 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.
That is because digitalWrite() allows you to dynamically assign the
pin at run time. If you have a fixed pin you want to use and speed is
important, you can use builtin assembler operations (DDRx,PORTx,PINx)
to get your two cycle operation. Most beginner projects are more human
speed so 2 or 200 cycles doesn't make much difference.
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.
Yes some of them are awful, but the more common ones are good and
getting better. For the beginner it lets them easily get something
working even if the dark corners have dragons.
Besides it can be a learning experience going through the library code
to see what is screwed up
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 only thing scarier than hardware engineers designing software is
software engineers designing hardware. Leave designing hardware to
physicists. Then the hardware engineers will be free to write software
and the software engineers can do the physics.
C
Clifford Heath
Guest
On 3/6/19 1:14 pm, bitrex wrote:
Atmel Studio has a much better and more complete API (the ASF), much
better implemented. It's a no-contest if you're on a supported MCU.
Atmel Studio has a much better and more complete API (the ASF), much
better implemented. It's a no-contest if you're on a supported MCU.