On Wed, 31 Jan 2024 08:42:33 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

>tirsdag den 30. januar 2024 kl. 21.37.32 UTC+1 skrev john larkin:
>> On Tue, 30 Jan 2024 20:02:53 +0100, Arie de Muijnck
>> <eternal....@ademu.com> wrote:
>>
>> >On 2024-01-30 06:19, John Larkin wrote:
>> >> On Mon, 29 Jan 2024 22:57:31 -0500 (EST), Martin Rid
>> >> <martin...@verison.net> wrote:
>> >>
>> >>> john larkin <j...@650pot.com> Wrote in message:r
>> >>>> Has anyone used any of the ESP32 parts? That's the Expressif Systemsfamily of uP's.Any comments?
>> >>>
>> >>> I've only seen them on assemblies, and no certification s .
>> >>> Why not an arm? Ti?
>> >>>
>> >>> Cheers
>> >>
>> >> I'm thinking about using the RP2040 in some products, and some of my
>> >> engineers suggested some alternates, including ESP32.
>> >>
>> >> I like the 2040 but it has no floating point hardware and no ethernet
>> >> MAC.
>> >>
>> >> The ESP32 looks dicey to me, but I wondered is anyone has used it. It
>> >> seems aimed at high volume wireless applications.
>> >>
>> >
>> >You want ethernet? I'm looking at the STM32H563ZIT6.
>> >2MB flash, 640kB RAM (who needs more...), 250MHz 32bit ARM Cortx M33, ethernet MAC.
>> >Lots of peripherals. I like the LQFP 144 20X20X1.4mm package.
>> >Very extensive free tool chain. Already ordered a devkit.
>> >
>> >https://estore.st.com/en/stm32h563zit6-cpn.html chip $10 @1pcs
>> >https://estore.st.com/en/nucleo-h563zi-cpn.html dev kit $28
>> >
>> >Arie
>> We use STM32F207IGT6 in a bunch of our products and test sets, and do
>> ethernet with just an external PHY and magnetics. But I really like
>> the Pi 2040 chip.
>
>have you actually used one yet? afaict apart from the PIOs, which seems like an exercise in masochism to program,
>it doesn't do anything the numerous other ARM/RISC-V chips do

One of my guys is playing with a Pi4 as the dev/debug system with a
Pico board as the target. He got a demo program running on the Pico in
a day and wiggled some i/os. It seems to just work.

Each of the pio pins has 6 alternate functions and some have 9 or 10,
which will take a bit of thinking on our first board, the template for
the product line. The pio hardware state machines could be
interesting.

We programmed the STMs bare metal, so we could program the 2040s bare
metal if that's easiest. Basically, it's two ARM cores.

News:

https://arstechnica.com/gadgets/2024/01/raspberry-pi-is-preparing-for-an-ipo-in-london-for-likely-more-than-500m/

I keep meeting people who hang out in maker spaces and use Pi's. This
is a techno-cultural revolution, like ham radio was after WWII.

The maker people visit maker spaces when they go to other cities and
find instant friends.

On 1/31/2024 9:29 AM, David Lesher wrote:
> Don Y <blockedofcourse@foo.invalid> writes:
>
>>> The software guru grouses about the build chain...
>
>> As a "significant" (if not MAJOR) stakeholder, didn't he have
>> a say in the hardware design/processor selection?
>
> Yes. He points out it's such a winner on the price/performance
> window, it can't be ignored. Plus, the NXP boards he'd used
> previously have been disappeared.

REMIND him of his endorsement! :>

And, something about a "free lunch"...

> What BSD-friendly tools for the ESP32 exist?

BSD-hosted? Or, BSD-licensed?

Dunno about the ESP32; I work with bigger SoC's, nowadays
(ARMv8's) -- or, super tiny devices that I code in ASM
(used as "hardware emulators").

For the former, Eclipse/gcc under NetBSD and ARM's toolchain
under Windows -- build under two different toolchains as a
sanity check for non-portable constructs (I also build under
Slowaris targeting SPARC just to REALLY stress my implementation!)

Plus, proprietary tools to give me a peek into running systems
(it's hard to trace program execution using conventional tools
when it spans multiple processors!)

On 2024-01-30, john larkin <jl@650pot.com> wrote:
> The spi chips are mac+phy and handle entire packets and protocols.
> That's a nice idea.

That probably works fine for not too-high traffic in a friendly environment.
If someone starts sending lots of packets your way, these parts will
probably drown and drop your intended traffic, too.

It depends on your use case if this is a problem or not.

cu
Michael
--
Some people have no respect of age unless it is bottled.

On 2024-01-29, john larkin <jl@650pot.com> wrote:
>
> Has anyone used any of the ESP32 parts? That's the Expressif Systems
> family of uP's.
>
> Any comments?

We have used them for a product just for the bluetooth function because an
ESP32-based module was way cheaper than other pure bluetooth modules we
looked at.

I have some running hobby projects, mainly sensor stuff (CO2, temp, rh) -
the ESP32 directly pushes the collected data to my MQTT server via wireless
LAN. Programming them using platformIO (and the arduino libraries) works
great to get started, for a commercial product, you may instead want to use
the ESP-IDF framework directly.

They do have some quirks, but provide decent performance for the money.

cu
Michael
--
Some people have no respect of age unless it is bottled.

On 8 Feb 2024 20:27:46 GMT, Michael Schwingen
<news-1513678000@discworld.dascon.de> wrote:

>On 2024-01-30, john larkin <jl@650pot.com> wrote:
>> The spi chips are mac+phy and handle entire packets and protocols.
>> That's a nice idea.
>
>That probably works fine for not too-high traffic in a friendly environment.
>If someone starts sending lots of packets your way, these parts will
>probably drown and drop your intended traffic, too.
>
>It depends on your use case if this is a problem or not.
>
>cu
>Michael

One of my guys is learning about using the WizNet chip with the
Raspberry Pi Pico, namely the RP2040 chip. He got a web page server up
in about a day.

The Wiz chip will wait around until it has an incoming packet ready,
and then interrupt. That's pretty cool.

Our box will occasionally get a query, like "what's the angular
position?" and will then reply. The sender should wait for the reply,
so I don't expect to be overwhelmed with traffic.

We are doing timing measurements to see how long bits of code, c or
their micro Python, take to run.

On 2/8/2024 1:27 PM, Michael Schwingen wrote:
> On 2024-01-30, john larkin <jl@650pot.com> wrote:
>> The spi chips are mac+phy and handle entire packets and protocols.
>> That's a nice idea.
>
> That probably works fine for not too-high traffic in a friendly environment.
> If someone starts sending lots of packets your way, these parts will
> probably drown and drop your intended traffic, too.

Exaactly. You can't control the *other* traffic on the wire.
So, can effectively experience a DoS even with average wire
rates well below the maximum bandwidth. (Think Slowloris
*without* even involving your stack!)

> It depends on your use case if this is a problem or not.

It depends on your *future* use cases, as well. It's
relatively easy for folks to fall into the trap of THINKING
it works -- in one scenario/environment -- and believing
they can move it to another with similar results.

The IPv6 stack I've put in my "network sugarcube" (originally
the basis for a one-port terminal server that now sees a dozen
or more applications -- once you have a good/robust stack, the
possibilities) exposes statistics about the "superfluous"
traffic that the device opted not to pass up to the application
layer. This allows the application to determine if it is in
a hostile environment, the probability that traffic intended
for it have been dropped or "muscled" out, failed attempts
to break IPsec, etc.

Nowadays, you don't even need to take out a soldering iron to
(attempt to) hack a device -- just throw packets at it as it
was likely designed not to consider the possibility of
hostile/malevolent traffic. Can you guarantee your customers
won't deploy your device in such an environment? Then, blame
YOU (after a lengthy analysis of THEIR environment) when
it doesn't perform as expected?

I.e., if you don't make guarantees about your functionality in
a particular environment, then you'd best be able to verify that
you aren't *in* that environment!

[How many designs will function correctly if the processor bus
was exposed to an outside agent? The network has a similar
function in newer designs]

On Thursday 8 February 2024 at 21:32:26 UTC, Don Y wrote:
> On 2/8/2024 1:27 PM, Michael Schwingen wrote:
> > On 2024-01-30, john larkin <j...@650pot.com> wrote:
> >> The spi chips are mac+phy and handle entire packets and protocols.
> >> That's a nice idea.
> >
> > That probably works fine for not too-high traffic in a friendly environment.
> > If someone starts sending lots of packets your way, these parts will
> > probably drown and drop your intended traffic, too.
> Exaactly. You can't control the *other* traffic on the wire.
> So, can effectively experience a DoS even with average wire
> rates well below the maximum bandwidth. (Think Slowloris
> *without* even involving your stack!)
> > It depends on your use case if this is a problem or not.
> It depends on your *future* use cases, as well. It's
> relatively easy for folks to fall into the trap of THINKING
> it works -- in one scenario/environment -- and believing
> they can move it to another with similar results.
>
> The IPv6 stack I've put in my "network sugarcube" (originally
> the basis for a one-port terminal server that now sees a dozen
> or more applications -- once you have a good/robust stack, the
> possibilities) exposes statistics about the "superfluous"
> traffic that the device opted not to pass up to the application
> layer. This allows the application to determine if it is in
> a hostile environment, the probability that traffic intended
> for it have been dropped or "muscled" out, failed attempts
> to break IPsec, etc.
>
> Nowadays, you don't even need to take out a soldering iron to
> (attempt to) hack a device -- just throw packets at it as it
> was likely designed not to consider the possibility of
> hostile/malevolent traffic. Can you guarantee your customers
> won't deploy your device in such an environment? Then, blame
> YOU (after a lengthy analysis of THEIR environment) when
> it doesn't perform as expected?
>
> I.e., if you don't make guarantees about your functionality in
> a particular environment, then you'd best be able to verify that
> you aren't *in* that environment!
>
>
> [How many designs will function correctly if the processor bus
> was exposed to an outside agent? The network has a similar
> function in newer designs]

There are a few sources of legitimate packets that can easily overwhelm a
small device. They come from some ip cameras and screen sharing software
which uses multicasts so every device on the network may be swamped with
video.
If the network uses WiFi, then multicasts are transmitted at the speed
of the slowest device on the WiFi network. This can quickly saturate
the wireless bandwidth if there is one device with a very slow connection speed.
Most switches and WiFi access points have settings that reduce the impact
of large amounts of multicast traffic, but you can't assume they will all be
appropriately set up.
John

On 2/9/2024 4:44 AM, John Walliker wrote:
> On Thursday 8 February 2024 at 21:32:26 UTC, Don Y wrote:
>> On 2/8/2024 1:27 PM, Michael Schwingen wrote:
>>> On 2024-01-30, john larkin <j...@650pot.com> wrote:
>>>> The spi chips are mac+phy and handle entire packets and protocols.
>>>> That's a nice idea.
>>>
>>> That probably works fine for not too-high traffic in a friendly environment.
>>> If someone starts sending lots of packets your way, these parts will
>>> probably drown and drop your intended traffic, too.
>> Exaactly. You can't control the *other* traffic on the wire.
>> So, can effectively experience a DoS even with average wire
>> rates well below the maximum bandwidth. (Think Slowloris
>> *without* even involving your stack!)
>>> It depends on your use case if this is a problem or not.
>> It depends on your *future* use cases, as well. It's
>> relatively easy for folks to fall into the trap of THINKING
>> it works -- in one scenario/environment -- and believing
>> they can move it to another with similar results.
>>
>> The IPv6 stack I've put in my "network sugarcube" (originally
>> the basis for a one-port terminal server that now sees a dozen
>> or more applications -- once you have a good/robust stack, the
>> possibilities) exposes statistics about the "superfluous"
>> traffic that the device opted not to pass up to the application
>> layer. This allows the application to determine if it is in
>> a hostile environment, the probability that traffic intended
>> for it have been dropped or "muscled" out, failed attempts
>> to break IPsec, etc.
>>
>> Nowadays, you don't even need to take out a soldering iron to
>> (attempt to) hack a device -- just throw packets at it as it
>> was likely designed not to consider the possibility of
>> hostile/malevolent traffic. Can you guarantee your customers
>> won't deploy your device in such an environment? Then, blame
>> YOU (after a lengthy analysis of THEIR environment) when
>> it doesn't perform as expected?
>>
>> I.e., if you don't make guarantees about your functionality in
>> a particular environment, then you'd best be able to verify that
>> you aren't *in* that environment!
>>
>> [How many designs will function correctly if the processor bus
>> was exposed to an outside agent? The network has a similar
>> function in newer designs]
>
> There are a few sources of legitimate packets that can easily overwhelm a
> small device. They come from some ip cameras and screen sharing software
> which uses multicasts so every device on the network may be swamped with
> video.

There are other protocols that also use broadcasts; you can't "know"
when such a packet(s) will come along -- nor if the devices using
the protocols will conspire or cooperate.

Or, jumbo packets.

(How are runts handled?)

> If the network uses WiFi, then multicasts are transmitted at the speed
> of the slowest device on the WiFi network. This can quickly saturate
> the wireless bandwidth if there is one device with a very slow connection speed.
> Most switches and WiFi access points have settings that reduce the impact
> of large amounts of multicast traffic, but you can't assume they will all be
> appropriately set up.

And, does nothing to inhibit packets *directed* to the specific host
(either out of ignorance/misconfiguration OR malevolence). If your
stack can't even *see* the presence of this extra traffic, then
you are doubly hosed as you never are aware of the lost bandwidth.

People think "it's got an 8P8C and this OTHER device has an 8P8C
so I should be able to let them all talk together". Or, they
alter the fabric that you have CAREFULLY put in place and
effectively rejigger the traffic. (you can just daisy chain
switches, "indefinitely", right? :> )

Falling back on "blaming the user's environment" is a huge copout,
especially if the induced traffic causes *your* device to fail.
(And, how eager do you think the user will be to troubleshoot
a problem that YOUR device is exhibiting, regardless of the cause?
Likely about as keen as YOU will be to visit the site and do
your own troubleshooting: "Well, it works in OUR lab...")

My current design uses a custom switch, dedicated/unique tunnels
for each device, bandwidth monitoring, etc. I.e., it verifies the
network is providing *exactly* the level of service that the device
requires; if not, obviously something isn't correct -- broken
or under attack!

If N% of your processor bus's bandwidth was "stolen", how would you
know? Would your device keep operating as expected with that reduction
in resources? (Ans: you don't allow folks to put stuff on that bus!)

On Thu, 8 Feb 2024 14:32:10 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 2/8/2024 1:27 PM, Michael Schwingen wrote:
>> On 2024-01-30, john larkin <jl@650pot.com> wrote:
>>> The spi chips are mac+phy and handle entire packets and protocols.
>>> That's a nice idea.
>>
>> That probably works fine for not too-high traffic in a friendly environment.
>> If someone starts sending lots of packets your way, these parts will
>> probably drown and drop your intended traffic, too.
>
>Exaactly. You can't control the *other* traffic on the wire.
>So, can effectively experience a DoS even with average wire
>rates well below the maximum bandwidth. (Think Slowloris
>*without* even involving your stack!)

It's not my box's fault of the network is overloaded. In the real
world, my customers mostly use private ethenet networks and control
the traffic by design. We don't expose our critical systems to the
world and neither do they.