Arduino code sources?

[Jan Panteltje]

On a sunny day (Mon, 3 Jun 2019 11:00:35 +1000) it happened Clifford Heath
<no.spam@please.net> wrote in <Wi_IE.9351$H55.6004@fx40.iad>:

On 3/6/19 1:05 am, Jan Panteltje wrote:
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>:
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 went wrong is that 'open' failed
... > // if you think he user is a moron, then you can do a test for the
directory chain.

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.

You are very very confused.
In coding you always have to create parts to inform a user if YOU think it is necessary.

What model airplane / manufacturer are you coding for?
I am making a blacklist what not to fly ;-)

Really nothing you say makes sense,
try looking at it from a real user perspective,
not one that thinks like you

From the application you know if you have to add extra info for users that
have no clue.

Even a 12 year old kid knows where to look
if /this/that/ortheother could not be opened.

It is is mostly a case of spelling.

It is a bit like driving a car, well OK there ARE clueless cases,
one such a case was somebody following the instructions of one of those GPS thingies,
'Take next left' and drove into a non existing bridge into the water that is.
You would like to say the thing, 'look sir, not that service road just before the bridge'.
Then you argue about the word 'next' and then you call it lack of respect from the system..
Bull
It is an aspect of a system created for trained users, if you want to write for clueless users
YOU have work to do as I stated before (its easy to do a directory check, examples in libc.info.

Go read libc.info and get a clue.

 

[Jan Panteltje]

On a sunny day (Mon, 3 Jun 2019 10:07:49 +1000) it happened Clifford Heath
<no.spam@please.net> wrote in <txZIE.58596$4O5.24452@fx46.iad>:

On 3/6/19 1:05 am, Jan Panteltje wrote:
libc.info is good.
fI you have never heard of it (it should be on your Linux system)
I have worked with Unix since the 1970s. I have no need of such trinkets.

That is a very very stupid remark.

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.

olala too old to learn?

 

[Jan Panteltje]

On a sunny day (Mon, 3 Jun 2019 00:00:56 -0400) it happened bitrex
<user@example.net> wrote in <ZX0JE.34913$jA4.29688@fx07.iad>:

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.

Although I agree with many other things you tweeted here,
the problem these days, and has perhaps always been, is draw lines between fields.
I hove worked in many different fields from high power to physics to medical to broadcast to
repair to hardware design software design, documentation writing, so much more
translation, always curious about the next field.
Applying what you learned in one field to the other is where the real strength is, invention.
We need more of that,
Not the limited responsibility closed horizons do what the boss says servitude that for example
did lead to that recent Boeing disaster.

There ARE no separation lines, those only exist in illusion.

 

[Clifford Heath]

On 3/6/19 3:21 pm, Jan Panteltje wrote:

On a sunny day (Mon, 3 Jun 2019 11:00:35 +1000) it happened Clifford Heath
no.spam@please.net> wrote in <Wi_IE.9351$H55.6004@fx40.iad>:

On 3/6/19 1:05 am, Jan Panteltje wrote:
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>:
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 went wrong is that 'open' failed
... > // if you think he user is a moron, then you can do a test for the
directory chain.

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.

You are very very confused.
In coding you always have to create parts to inform a user if YOU think it is necessary.

What model airplane / manufacturer are you coding for?
I am making a blacklist what not to fly ;-)

Really nothing you say makes sense,
try looking at it from a real user perspective,
not one that thinks like you

In the last forty years I have sold hundreds of millions of $ worth of
software of my design (I led the teams who wrote three major software
suites over a decade each), and some is still running banks, oil
companies, governments. If I need a TV fixed I will bring it to you, but
I will not ask your opinions on software.

This file open example is just an example. Every error has a context,
and sometimes the parameters to the system call are not enough context;
you need more than just a number to indicate the missing context.

If you have ever sat and watched (without trying to help or interfere)
someone learning any new piece of software, I guarantee you will see
this problem twice in the first few minutes. But I seriously doubt that
you have ever done that. We've even had professionals do it, using video
cameras with eye-tracking to see what the user is looking at as they
explore, to discover where they understand and where they get confused.
People are complicated. They're not morons, they just don't all have the
same kinds of brains. This is a well-known and common practice amongst
those who care about usability, and the data do not lie.

Clifford Heath.

From the application you know if you have to add extra info for users that
have no clue.

Even a 12 year old kid knows where to look
if /this/that/ortheother could not be opened.

It is is mostly a case of spelling.

It is a bit like driving a car, well OK there ARE clueless cases,
one such a case was somebody following the instructions of one of those GPS thingies,
'Take next left' and drove into a non existing bridge into the water that is.
You would like to say the thing, 'look sir, not that service road just before the bridge'.
Then you argue about the word 'next' and then you call it lack of respect from the system..
Bull
It is an aspect of a system created for trained users, if you want to write for clueless users
YOU have work to do as I stated before (its easy to do a directory check, examples in libc.info.

Go read libc.info and get a clue.

 

[Tom Gardner]

On 03/06/19 05:30, Clifford Heath wrote:

On 3/6/19 1:14 pm, bitrex 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.

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.

And peripherals / shields.
And ecosystem including libraries and users.
(And operating system)

Beginners use arduino to glue bits together in simple ways.
It is /sufficient/ for that.

Apart from that, I'm not going to defend arduinos.

 

[Tom Gardner]

On 03/06/19 05:00, bitrex wrote:

On 6/1/19 11:30 AM, Phil Hobbs wrote:
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 for the beginner or faint of heart!).

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.

One of the games I play in pub conversations is to try
to get people to come up with a simple definition of
what's hardware and what's software. Almost all fail
around the boundary, because they have insufficient
understanding of both.

One of the best engineers I knew had taken a 1 year MSc
conversion course after his first degree in biochemistry.

He was an exception, not least because two of his ancestors
had Nobel prizes.

 

[Tom Gardner]

On 03/06/19 04:52, bitrex wrote:

On 6/1/19 11:32 AM, Phil Hobbs wrote:
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."

.... and can be seen in all walks of software and hardware

 

Tom Gardner <spamjunk@blueyonder.co.uk> wrote in
news:Ze4JE.561232$X23.287642@fx38.am4:

On 03/06/19 05:30, Clifford Heath wrote:
On 3/6/19 1:14 pm, bitrex 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.

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.

And peripherals / shields.
And ecosystem including libraries and users.
(And operating system)

Beginners use arduino to glue bits together in simple ways.
It is /sufficient/ for that.

Apart from that, I'm not going to defend arduinos.

Get REAL work done...


<https://www.solid-run.com/>

 

[bitrex]

On 6/3/19 11:33 AM, bitrex wrote:

On 6/3/19 1:52 AM, Jan Panteltje wrote:
On a sunny day (Mon, 3 Jun 2019 00:00:56 -0400) it happened bitrex
user@example.net> wrote in <ZX0JE.34913$jA4.29688@fx07.iad>:

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.

Although I agree with many other things you tweeted here,
the problem these days, and has perhaps always been, is draw lines
between fields.
I hove worked in many different fields from high power to physics to
medical to broadcast to
repair to hardware design software design, documentation writing, so
much more
translation, always curious about the next field.
Applying what you learned in one field to the other is where the real
strength is, invention.
We need more of that,
Not the limited responsibility closed horizons do what the boss says
servitude that for example
did lead to that recent Boeing disaster.
There ARE no separation lines, those only exist in illusion.


I think it's okay to just "do what the boss" says in many circumstances.
It's (ideally) why there are managers, after all. they manage. It's a
job that needs doing.

The problem becomes when for whatever reason nobody feels confident
enough to, from time to time, tell the boss that their idea is dumb
without fear of negative repercussions. That fear is often ingrained in
very rigid hierarchical structures like the way a "legacy company" like
Boeing might be organized.

It's something you see. Design decisions where you think "so this
probably passed through a number of review stages and the fact that this
dumb thing is sitting in front of me, making my life miserable, is
because EVERYONE down that chain signed off on it. Really? but me and
everyone else I've asked has opined 'this is dumb.' Why at no point did
anyone in that chain speak up and also say HEY. THIS IS A DUMB IDEA and
point out the emperor has no clothes? Surely someone must have noticed?"

It's part of why this ng is valuable to me even though it contains, to
my mind, a bunch of assholes who have bad political opinions. I can use
it to get my own bad engineering ideas broken. Great! Bad engineering
ideas at least should be broken at the outset. Saves time that way. Lots
of people here happy to do it!

 

[bitrex]

On 6/3/19 1:52 AM, Jan Panteltje wrote:

On a sunny day (Mon, 3 Jun 2019 00:00:56 -0400) it happened bitrex
user@example.net> wrote in <ZX0JE.34913$jA4.29688@fx07.iad>:

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.

Although I agree with many other things you tweeted here,
the problem these days, and has perhaps always been, is draw lines between fields.
I hove worked in many different fields from high power to physics to medical to broadcast to
repair to hardware design software design, documentation writing, so much more
translation, always curious about the next field.
Applying what you learned in one field to the other is where the real strength is, invention.
We need more of that,
Not the limited responsibility closed horizons do what the boss says servitude that for example
did lead to that recent Boeing disaster.

There ARE no separation lines, those only exist in illusion.

I think it's okay to just "do what the boss" says in many circumstances.
It's (ideally) why there are managers, after all. they manage. It's a
job that needs doing.

The problem becomes when for whatever reason nobody feels confident
enough to, from time to time, tell the boss that their idea is dumb
without fear of negative repercussions. That fear is often ingrained in
very rigid hierarchical structures like the way a "legacy company" like
Boeing might be organized.

It's something you see. Design decisions where you think "so this
probably passed through a number of review stages and the fact that this
dumb thing is sitting in front of me, making my life miserable, is
because EVERYONE down that chain signed off on it. Really? but me and
everyone else I've asked has opined 'this is dumb.' Why at no point did
anyone in that chain speak up and also say HEY. THIS IS A DUMB IDEA and
point out the emperor has no clothes? Surely someone must have noticed?"

 

It's part of why this ng is valuable to me even though it contains, to
my mind, a bunch of assholes who have bad political opinions.

We knew that you weren't here for the usual reasons, for instance to be friendly or helpful.

Cheers

Phil Hobbs

 

On Mon, 3 Jun 2019 00:00:56 -0400, bitrex <user@example.net> wrote:

On 6/1/19 11:30 AM, Phil Hobbs wrote:
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 for the beginner or faint of heart!).

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.

When I left Lockheed Martin (a decade ago, give or take), the group
was about to consolidate their FPGA (VHDL) engineers into their
software group. Scary indeed! Scary place, all around.

 

[bitrex]

On 6/3/19 7:29 PM, pcdhobbs@gmail.com wrote:

It's part of why this ng is valuable to me even though it contains, to
my mind, a bunch of assholes who have bad political opinions.

We knew that you weren't here for the usual reasons, for instance to be friendly or helpful.

Cheers

Phil Hobbs

I've been helpful plenty of times, likely not to you but that's the way
it goes.

Sucking up isn't my department, though, which does tend to irritate
people who expect it.

 

[bitrex]

On 6/3/19 7:29 PM, pcdhobbs@gmail.com wrote:

It's part of why this ng is valuable to me even though it contains, to
my mind, a bunch of assholes who have bad political opinions.

We knew that you weren't here for the usual reasons, for instance to be friendly or helpful.

Cheers

Phil Hobbs

PS: you really gotta let this condescending-sarcastic-Internet-man act
go, Dr. Phil. it's not becoming of a doctor. it's not a good look for u.

 

[Don Kuenz, KB7RPU]

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

<snip>

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

Background:

My Altoids audio mixer [1] is in the middle of a makeover. The new iso
transformer front end's already finished and sounds heavenly. New
components made my circuit outgrow the tiny Altoids tin, so now
everything's housed in a small Bud box. The new circuit utilizes a
TEA2025 stereo audio amplifier [2], among other things. That beast can
output up to 1.5 A, which far exceeds the capabilities of the TLE2426
"rail splitter" [3] that ultimately powers the new circuit. So the "rail
splitter" will drive a BUF634A buffer [4] instead, which can supply up
to 250 mA.


Spot the app note error:

My original intention was to use app notes to cobble the buffer on to
the output of the "rail splitter," easy peasy. You inspired me to spend
a little bit more time to look deeper into those app notes. Any wisdom
that you, or others, can impart on my quest to "spot the app note error"
is appreciated.

Note.

1. http://crcomp.net/electronic/altoidsmixer/index.php
2. https://media.digikey.com/pdf/Data%20Sheets/ST%20Microelectronics%20PDFS/TEA2025.pdf
3. http://www.ti.com/lit/ds/symlink/tle2426.pdf
4. http://www.ti.com/lit/ds/symlink/buf634.pdf

Thank you, 73,

--
Don Kuenz KB7RPU
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

 

[Phil Hobbs]

On 6/4/19 12:03 PM, Don Kuenz wrote:> Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

snip

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

Background:

My Altoids audio mixer [1] is in the middle of a makeover. The new iso
transformer front end's already finished and sounds heavenly. New
components made my circuit outgrow the tiny Altoids tin, so now
everything's housed in a small Bud box. The new circuit utilizes a
TEA2025 stereo audio amplifier [2], among other things. That beast can
output up to 1.5 A, which far exceeds the capabilities of the TLE2426
"rail splitter" [3] that ultimately powers the new circuit. So the "rail
splitter" will drive a BUF634A buffer [4] instead, which can supply up
to 250 mA.


Spot the app note error:

My original intention was to use app notes to cobble the buffer on to
the output of the "rail splitter," easy peasy. You inspired me to spend
a little bit more time to look deeper into those app notes. Any wisdom
that you, or others, can impart on my quest to "spot the app note error"
is appreciated.

Note.

1. http://crcomp.net/electronic/altoidsmixer/index.php
2.
https://media.digikey.com/pdf/Data%20Sheets/ST%20Microelectronics%20PDFS/TEA2025.pdf
3. http://www.ti.com/lit/ds/symlink/tle2426.pdf
4. http://www.ti.com/lit/ds/symlink/buf634.pdf

Thank you, 73,

One of the usual appnote sins is to use gold-plated parts (their own,
naturally). This is one of those--you're using a $10 BUF634 and a $2
TLE2426 instead of a $1 TCA0372 and two resistors. (See George's thread.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[bitrex]

On 6/4/19 12:03 PM, Don Kuenz wrote:

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

snip

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

Background:

My Altoids audio mixer [1] is in the middle of a makeover. The new iso
transformer front end's already finished and sounds heavenly. New
components made my circuit outgrow the tiny Altoids tin, so now
everything's housed in a small Bud box. The new circuit utilizes a
TEA2025 stereo audio amplifier [2], among other things. That beast can
output up to 1.5 A, which far exceeds the capabilities of the TLE2426
"rail splitter" [3] that ultimately powers the new circuit. So the "rail
splitter" will drive a BUF634A buffer [4] instead, which can supply up
to 250 mA.


Spot the app note error:

My original intention was to use app notes to cobble the buffer on to
the output of the "rail splitter," easy peasy. You inspired me to spend
a little bit more time to look deeper into those app notes. Any wisdom
that you, or others, can impart on my quest to "spot the app note error"
is appreciated.

Note.

1. http://crcomp.net/electronic/altoidsmixer/index.php
2. https://media.digikey.com/pdf/Data%20Sheets/ST%20Microelectronics%20PDFS/TEA2025.pdf
3. http://www.ti.com/lit/ds/symlink/tle2426.pdf
4. http://www.ti.com/lit/ds/symlink/buf634.pdf

Thank you, 73,

why does an audio mixer need 1.5A of available output current?

 

[Don Kuenz, KB7RPU]

bitrex <user@example.net> wrote:

On 6/4/19 12:03 PM, Don Kuenz wrote:
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

snip

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

Background:

My Altoids audio mixer [1] is in the middle of a makeover. The new iso
transformer front end's already finished and sounds heavenly. New
components made my circuit outgrow the tiny Altoids tin, so now
everything's housed in a small Bud box. The new circuit utilizes a
TEA2025 stereo audio amplifier [2], among other things. That beast can
output up to 1.5 A, which far exceeds the capabilities of the TLE2426
"rail splitter" [3] that ultimately powers the new circuit. So the "rail
splitter" will drive a BUF634A buffer [4] instead, which can supply up
to 250 mA.


Spot the app note error:

My original intention was to use app notes to cobble the buffer on to
the output of the "rail splitter," easy peasy. You inspired me to spend
a little bit more time to look deeper into those app notes. Any wisdom
that you, or others, can impart on my quest to "spot the app note error"
is appreciated.

Note.

1. http://crcomp.net/electronic/altoidsmixer/index.php
2. https://media.digikey.com/pdf/Data%20Sheets/ST%20Microelectronics%20PDFS/TEA2025.pdf
3. http://www.ti.com/lit/ds/symlink/tle2426.pdf
4. http://www.ti.com/lit/ds/symlink/buf634.pdf

why does an audio mixer need 1.5A of available output current?

It morphed into a mixer-amp. All will be revealed in the upcoming
webpage.

Thank you, 73,

--
Don Kuenz KB7RPU
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

 

[Don Kuenz]

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

<snip>

One of the usual appnote sins is to use gold-plated parts (their own,
naturally). This is one of those--you're using a $10 BUF634 and a $2
TLE2426 instead of a $1 TCA0372 and two resistors. (See George's thread.)

The mixer opamps are on a daughterboard in order to facilitate
experimentation. You convinced me that the power circuit also deserves
its own daughterboard. That way, those two expensive parts can go right
back into inventory if they offer little, if any, improvement.

73,

--
Don Kuenz, KB7RPU

 

[Don Kuenz, KB7RPU]

Winfield Hill <winfieldhill@yahoo.com> wrote:

Don Kuenz, KB7RPU wrote...

why does an audio mixer need 1.5A of available
output current?

It morphed into a mixer-amp. All will be revealed
in the upcoming webpage.

The AMP portion should be BTL, that way there'd
be no rail-splitter mid-supply ground current.

The TEA2025 drives two separate stereo speakers, a left and a right.

Thank you, 73,

--
Don Kuenz KB7RPU
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.