rant: filenames...

On a sunny day (Fri, 12 Nov 2021 10:08:39 -0800) it happened John Larkin
<jlarkin@highland_atwork_technology.com> wrote in
<3bbtogh6jstka4039uimng3q8baguk94i3@4ax.com>:

On Fri, 12 Nov 2021 08:09:35 GMT, Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote:

On a sunny day (Thu, 11 Nov 2021 22:01:33 +0000) it happened Peter
nospam@nospam9876.com> wrote in <smk3rt$72m$1@dont-email.me>:

Sometimes one needs to power a circuit from one source or another.

Most LDOs, or indeed most normal regs, feed current back up to the
source. LDOs tend to use a PMOS pass transistor which has a parasitic
diode.

I am doing a design where I am using the Ricoh R1191 for this

https://eu.mouser.com/ProductDetail/Ricoh-Electronic-Devices-Company/R1191N033B-TR-FE?qs=%2Fha2pyFaduhEV6ZG3xOqbaXpStP%2FIzlm74
g8
V5lGNcwdefxpMkR8XA%3D%3D

which has a series diode, so the dropout voltage is about 0.7V.

It\'s not dirt cheap but not crazy-priced either.

I am wondering why this is rare. Is it not possible to make a PMOS
device without the parasitic diode? Or have some other series element
which gets turned off when there is no input? It reminds me of an
active rectifier in switching power supplies, to avoid the Vf of the
diode(s). There is even a circuit for a bridge rectifier, although
that was commercially implemented with a complicated chip to drive the
four gates, IIRC.

One obvious solution is to use a normal LDO and have a diode in series
with the input, so long as you can be sure nothing funny will be
hapenning inside with the ground lead which could still pass negative
current.

IIRC the correct way to parallel 2 voltage regulators is have each one sense its output current
and if too high drive the current reference of the other one higher until both deliver the same current.
If you just parallel voltage controlled ones then one is likely to do all the work
due to minuscule output voltage differences.
For example one could go into current limit at 100% current and the other will then do say 10%.
Much simpler to get or design one bigger one?




You can certainly diode OR the input of a single reg, from two
sources.

Of course, but that is different, and even then the highest input will deliver everything,
although having high internal resistance sources / \'feeble\' diodes would share ..
 
fredag den 12. november 2021 kl. 18.33.10 UTC+1 skrev jla...@highlandsniptechnology.com:
On Fri, 12 Nov 2021 18:10:53 +0200, LM <sala...@mail.com> wrote:

I could use a 100 pin LQFP, but when it is impossible to know what
part is available next week, I cannot.

On Thu, 11 Nov 2021 13:56:52 -0800, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Thu, 11 Nov 2021 23:12:56 +0200, LM <sala...@mail.com> wrote:

If they stay in stock, life is getting better.

Alas, not in our package. But maybe things are breaking.
We use STM32F207IGT6, LQFP176 package, in several products. The
question is whether we should gamble on them becoming available, and
design them into a new product.

why the F207? seems to me the F407 is more common, it is probably pin compatible
just just faster and with an FPU, M4 vs. M3 core
 
fredag den 12. november 2021 kl. 18.33.10 UTC+1 skrev jla...@highlandsniptechnology.com:
On Fri, 12 Nov 2021 18:10:53 +0200, LM <sala...@mail.com> wrote:

I could use a 100 pin LQFP, but when it is impossible to know what
part is available next week, I cannot.

On Thu, 11 Nov 2021 13:56:52 -0800, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Thu, 11 Nov 2021 23:12:56 +0200, LM <sala...@mail.com> wrote:

If they stay in stock, life is getting better.

Alas, not in our package. But maybe things are breaking.
We use STM32F207IGT6, LQFP176 package, in several products. The
question is whether we should gamble on them becoming available, and
design them into a new product.

why the F207? seems to me the F407 is more common, it is probably pin compatible
just just faster and with an FPU, M4 vs. M3 core
 
On 11/15/2021 19:40, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 19:03:50 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smu3tn$8jl$1@dont-email.me>:

On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.

Cool!

Read:
https://unix.stackexchange.com/questions/48770/how-to-match-case-insensitive-patterns-with-ls
to list files ignoring case

You don\'t have to convince me a solution can be programmed to just about
any flaw, including the file naming in unix.


Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.



Their file names are case dependent;

And that is a GOOD thing!
You need to learn how to search with
locate -i
As you likely know mA is not the same as MA and mOhm is not MOhm


Yeah, good thing you figured out an exception to cling to,
see my comment above.

Then the naming is not the only shortcoming of the unix filesystem,
it (like that of windows) makes worst fit allocation impractical.

You really need to read up on this stuff if you want to use it.
I have NEVER encoutered a problem with Linux file systems, and tried many and use many.

Oh I am sure it works, in its flawed by design way. Not using \"worst
fit\" for allocation brings just more fragmentation than there has to be
which you probably have not even noticed - or did not know there
was life without it.
And you have learned to live with the flawed use of text.

But MS windows crap filesystem as it comes with some USB sticks or is used by my Chinese digital TV receivers
even limit file size to 4293402624 bytes.
4293402624 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_1.ts
41383680 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_2.ts

-> 2^32 = 4294967296

I never intended to compare these two filesystems. The MS approach with
file names is the correct one though, and the unix\' use of text for file
names is the flawed one, that much is obvious.

The latter can be fixed by writing/adopting a well designed filesystem;
the naming flaw cannot be fixed.

You are just blaming the car that you do not know how to drive.

Yeah, what do I know about filesystems. How many filesystems have
you designed.

I know you cannot switch off from fuming mode - your entering of which I
predicted - so I suggest you just let it go, you don\'t really know what
you are talking about.

Have a nice evening.
 
On 11/15/2021 19:40, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 19:03:50 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smu3tn$8jl$1@dont-email.me>:

On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.

Cool!

Read:
https://unix.stackexchange.com/questions/48770/how-to-match-case-insensitive-patterns-with-ls
to list files ignoring case

You don\'t have to convince me a solution can be programmed to just about
any flaw, including the file naming in unix.


Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.



Their file names are case dependent;

And that is a GOOD thing!
You need to learn how to search with
locate -i
As you likely know mA is not the same as MA and mOhm is not MOhm


Yeah, good thing you figured out an exception to cling to,
see my comment above.

Then the naming is not the only shortcoming of the unix filesystem,
it (like that of windows) makes worst fit allocation impractical.

You really need to read up on this stuff if you want to use it.
I have NEVER encoutered a problem with Linux file systems, and tried many and use many.

Oh I am sure it works, in its flawed by design way. Not using \"worst
fit\" for allocation brings just more fragmentation than there has to be
which you probably have not even noticed - or did not know there
was life without it.
And you have learned to live with the flawed use of text.

But MS windows crap filesystem as it comes with some USB sticks or is used by my Chinese digital TV receivers
even limit file size to 4293402624 bytes.
4293402624 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_1.ts
41383680 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_2.ts

-> 2^32 = 4294967296

I never intended to compare these two filesystems. The MS approach with
file names is the correct one though, and the unix\' use of text for file
names is the flawed one, that much is obvious.

The latter can be fixed by writing/adopting a well designed filesystem;
the naming flaw cannot be fixed.

You are just blaming the car that you do not know how to drive.

Yeah, what do I know about filesystems. How many filesystems have
you designed.

I know you cannot switch off from fuming mode - your entering of which I
predicted - so I suggest you just let it go, you don\'t really know what
you are talking about.

Have a nice evening.
 
On 2021-11-15 18:03, Dimiter_Popoff wrote:
On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.
Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.

Now, now Dimiter, just because you can does not mean it\'s a good
idea to do so. But I would resent any filesystem *preventing* me
from doing so. Nothing in UNIX prevents you from naming your all
your files in all upper case, should you want to. Choose your evil.

Jeroen Belleman
 
On 13-Nov-21 2:59 am, John Robertson wrote:
On 2021/11/11 11:31 p.m., Sylvia Else wrote:
On 12-Nov-21 1:01 pm, Jeff Liebermann wrote:
On Thu, 11 Nov 2021 14:48:38 +1100, Sylvia Else <sylvia@email.invalid
wrote:

Bought a couple of oscilloscope probes today to replace those
damaged/lost.

They don\'t fit, because the plastic surround exceeds the specified
diameter for a BNC plug. My scope has a hole in its front plate to
accommodate a standard BNC plug, but it\'s not big enough for this
oversized plastic variant.

This probably saves several cents per probe, but created a problem I
didn\'t need.

Sylvia.

I had a similar problem with some long forgotten piece of SCADA
hardware.  The BNC plugs fit, but they were so close together that
even the official insertion/removal tool didn\'t fit.  However, this
was using a 50 ohm system, not the much higher impedance of a scope
probe.

I created an adapter of sorts to elevate every other connector.  It
was a UG-88C/U plug with BNC panel mount receptacle crammed into the
plug.  A short piece of bare wire connected the center pins and an
ugly solder blob connected the grounds:
https://www.newark.com/amphenol-rf/ug-88c-u/rf-coaxial-bnc-plug-50-ohm-cable/dp/04M6671

https://www.newark.com/amphenol-rf/31-10/connector-bnc-bhd-jack-str-50/dp/38F1322?st=bnc%20panel

The resulting adapter added about 1 inch to the length of the 50 ohm
connection.  Whether the added capacitance will cause problems on your
oscilloscope will need to be determined.

If you want to just see if such an adapter has a chance of working,
try connecting a BNC M-M adapter (UG-491A/U) to a BNC F-F adapter
(UG-914/U).  This will extend the line length by 1.75 inches.  If it
works, build a shorter adaptor.


I bought a male to male adapter and a female to female adapter, and
joined them together. Seems to work OK for the kinds of frequency I
deal with - it\'s only a 20MHz scope anyway.

The extra length of metal attached to the socket does make it easier
to damage the socket though.

Sylvia.

How about just build a short BNC plug and receptacle extension, with a
short length of cable between them? As you say it is only 20mHz...

John :-#)#
Could do, but that would have added yet another thing to the stack of
things I needed to do before I could get on with what I was actually
wanting to do.

Sylvia.
 
On 11/15/2021 19:40, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 19:03:50 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smu3tn$8jl$1@dont-email.me>:

On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.

Cool!

Read:
https://unix.stackexchange.com/questions/48770/how-to-match-case-insensitive-patterns-with-ls
to list files ignoring case

You don\'t have to convince me a solution can be programmed to just about
any flaw, including the file naming in unix.


Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.



Their file names are case dependent;

And that is a GOOD thing!
You need to learn how to search with
locate -i
As you likely know mA is not the same as MA and mOhm is not MOhm


Yeah, good thing you figured out an exception to cling to,
see my comment above.

Then the naming is not the only shortcoming of the unix filesystem,
it (like that of windows) makes worst fit allocation impractical.

You really need to read up on this stuff if you want to use it.
I have NEVER encoutered a problem with Linux file systems, and tried many and use many.

Oh I am sure it works, in its flawed by design way. Not using \"worst
fit\" for allocation brings just more fragmentation than there has to be
which you probably have not even noticed - or did not know there
was life without it.
And you have learned to live with the flawed use of text.

But MS windows crap filesystem as it comes with some USB sticks or is used by my Chinese digital TV receivers
even limit file size to 4293402624 bytes.
4293402624 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_1.ts
41383680 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_2.ts

-> 2^32 = 4294967296

I never intended to compare these two filesystems. The MS approach with
file names is the correct one though, and the unix\' use of text for file
names is the flawed one, that much is obvious.

The latter can be fixed by writing/adopting a well designed filesystem;
the naming flaw cannot be fixed.

You are just blaming the car that you do not know how to drive.

Yeah, what do I know about filesystems. How many filesystems have
you designed.

I know you cannot switch off from fuming mode - your entering of which I
predicted - so I suggest you just let it go, you don\'t really know what
you are talking about.

Have a nice evening.
 
On 13-Nov-21 2:59 am, John Robertson wrote:
On 2021/11/11 11:31 p.m., Sylvia Else wrote:
On 12-Nov-21 1:01 pm, Jeff Liebermann wrote:
On Thu, 11 Nov 2021 14:48:38 +1100, Sylvia Else <sylvia@email.invalid
wrote:

Bought a couple of oscilloscope probes today to replace those
damaged/lost.

They don\'t fit, because the plastic surround exceeds the specified
diameter for a BNC plug. My scope has a hole in its front plate to
accommodate a standard BNC plug, but it\'s not big enough for this
oversized plastic variant.

This probably saves several cents per probe, but created a problem I
didn\'t need.

Sylvia.

I had a similar problem with some long forgotten piece of SCADA
hardware.  The BNC plugs fit, but they were so close together that
even the official insertion/removal tool didn\'t fit.  However, this
was using a 50 ohm system, not the much higher impedance of a scope
probe.

I created an adapter of sorts to elevate every other connector.  It
was a UG-88C/U plug with BNC panel mount receptacle crammed into the
plug.  A short piece of bare wire connected the center pins and an
ugly solder blob connected the grounds:
https://www.newark.com/amphenol-rf/ug-88c-u/rf-coaxial-bnc-plug-50-ohm-cable/dp/04M6671

https://www.newark.com/amphenol-rf/31-10/connector-bnc-bhd-jack-str-50/dp/38F1322?st=bnc%20panel

The resulting adapter added about 1 inch to the length of the 50 ohm
connection.  Whether the added capacitance will cause problems on your
oscilloscope will need to be determined.

If you want to just see if such an adapter has a chance of working,
try connecting a BNC M-M adapter (UG-491A/U) to a BNC F-F adapter
(UG-914/U).  This will extend the line length by 1.75 inches.  If it
works, build a shorter adaptor.


I bought a male to male adapter and a female to female adapter, and
joined them together. Seems to work OK for the kinds of frequency I
deal with - it\'s only a 20MHz scope anyway.

The extra length of metal attached to the socket does make it easier
to damage the socket though.

Sylvia.

How about just build a short BNC plug and receptacle extension, with a
short length of cable between them? As you say it is only 20mHz...

John :-#)#
Could do, but that would have added yet another thing to the stack of
things I needed to do before I could get on with what I was actually
wanting to do.

Sylvia.
 
On Monday, November 15, 2021 at 9:00:15 AM UTC-8, bitrex wrote:
On 11/13/2021 5:37 PM, Ed Lee wrote:
On Saturday, November 13, 2021 at 2:29:51 PM UTC-8, bitrex wrote:
On 11/13/2021 4:09 PM, Peter wrote:

bitrex <us...@example.net> wrote

On 11/13/2021 2:09 AM, Klaus Kragelund wrote:
11.11.21 22:12, LM wrote:
If they stay in stock, life is getting better.

Yes, also other sites are showing stock

Maybe we are soon getting back to normal. Will be interesting to see if
prices go back to normal
--
Klaus

Pandemic shortages made a lot of manufacturers of various products
realize \"ugh we\'ve been selling this stuff way too cheap all along\" I think

I doubt it; this is just the usual cyclic thing, where a shorateg is
artifically created (by various events, which usually merge into the
distis telling everybody that x is on allocation, upon which the users
shit themselves and multi-order everything they can) and then
collapses a year or so later.

This will go the same way.

I have quite enjoyed designing out parts by Mr Ripoff (Maxim) and
replacing them with ST parts, and some TI parts.


Herr Ripoff:

https://www.motor1.com/news/532591/mercedes-bmw-keep-prices-high/

\"We could lower them again but why\"

It\'s the same for all auto makers. They can keep price high as long as everybody is doing it. Anyway, we have to adjust to having less cars. There is no need for 1.88 car per household.

Not every luxury/performance manufacturer is doing great I don\'t think:

Tesla is pretty much eating up other luxury sales.

2021 2020 (est)
Revenue $34B $20B
Income $3B $1B
Margin 11% 10%

Both GM and Ford are doing better with less unit sales.

Earning year to date (Sept)

2021 2020
GM
Revenue $93.4B $84.9B
Income $8.3B $3.5B
Margin 8.9% 4.2%

Ford
Revenue $98.7B $91.2B
Income $5.7B $1.5B
Margin 5.7% 1.7%
 
On Monday, November 15, 2021 at 9:00:15 AM UTC-8, bitrex wrote:
On 11/13/2021 5:37 PM, Ed Lee wrote:
On Saturday, November 13, 2021 at 2:29:51 PM UTC-8, bitrex wrote:
On 11/13/2021 4:09 PM, Peter wrote:

bitrex <us...@example.net> wrote

On 11/13/2021 2:09 AM, Klaus Kragelund wrote:
11.11.21 22:12, LM wrote:
If they stay in stock, life is getting better.

Yes, also other sites are showing stock

Maybe we are soon getting back to normal. Will be interesting to see if
prices go back to normal
--
Klaus

Pandemic shortages made a lot of manufacturers of various products
realize \"ugh we\'ve been selling this stuff way too cheap all along\" I think

I doubt it; this is just the usual cyclic thing, where a shorateg is
artifically created (by various events, which usually merge into the
distis telling everybody that x is on allocation, upon which the users
shit themselves and multi-order everything they can) and then
collapses a year or so later.

This will go the same way.

I have quite enjoyed designing out parts by Mr Ripoff (Maxim) and
replacing them with ST parts, and some TI parts.


Herr Ripoff:

https://www.motor1.com/news/532591/mercedes-bmw-keep-prices-high/

\"We could lower them again but why\"

It\'s the same for all auto makers. They can keep price high as long as everybody is doing it. Anyway, we have to adjust to having less cars. There is no need for 1.88 car per household.

Not every luxury/performance manufacturer is doing great I don\'t think:

Tesla is pretty much eating up other luxury sales.

2021 2020 (est)
Revenue $34B $20B
Income $3B $1B
Margin 11% 10%

Both GM and Ford are doing better with less unit sales.

Earning year to date (Sept)

2021 2020
GM
Revenue $93.4B $84.9B
Income $8.3B $3.5B
Margin 8.9% 4.2%

Ford
Revenue $98.7B $91.2B
Income $5.7B $1.5B
Margin 5.7% 1.7%
 
On Monday, November 15, 2021 at 9:00:15 AM UTC-8, bitrex wrote:
On 11/13/2021 5:37 PM, Ed Lee wrote:
On Saturday, November 13, 2021 at 2:29:51 PM UTC-8, bitrex wrote:
On 11/13/2021 4:09 PM, Peter wrote:

bitrex <us...@example.net> wrote

On 11/13/2021 2:09 AM, Klaus Kragelund wrote:
11.11.21 22:12, LM wrote:
If they stay in stock, life is getting better.

Yes, also other sites are showing stock

Maybe we are soon getting back to normal. Will be interesting to see if
prices go back to normal
--
Klaus

Pandemic shortages made a lot of manufacturers of various products
realize \"ugh we\'ve been selling this stuff way too cheap all along\" I think

I doubt it; this is just the usual cyclic thing, where a shorateg is
artifically created (by various events, which usually merge into the
distis telling everybody that x is on allocation, upon which the users
shit themselves and multi-order everything they can) and then
collapses a year or so later.

This will go the same way.

I have quite enjoyed designing out parts by Mr Ripoff (Maxim) and
replacing them with ST parts, and some TI parts.


Herr Ripoff:

https://www.motor1.com/news/532591/mercedes-bmw-keep-prices-high/

\"We could lower them again but why\"

It\'s the same for all auto makers. They can keep price high as long as everybody is doing it. Anyway, we have to adjust to having less cars. There is no need for 1.88 car per household.

Not every luxury/performance manufacturer is doing great I don\'t think:

Tesla is pretty much eating up other luxury sales.

2021 2020 (est)
Revenue $34B $20B
Income $3B $1B
Margin 11% 10%

Both GM and Ford are doing better with less unit sales.

Earning year to date (Sept)

2021 2020
GM
Revenue $93.4B $84.9B
Income $8.3B $3.5B
Margin 8.9% 4.2%

Ford
Revenue $98.7B $91.2B
Income $5.7B $1.5B
Margin 5.7% 1.7%
 
On Monday, November 15, 2021 at 9:00:15 AM UTC-8, bitrex wrote:
On 11/13/2021 5:37 PM, Ed Lee wrote:
On Saturday, November 13, 2021 at 2:29:51 PM UTC-8, bitrex wrote:
On 11/13/2021 4:09 PM, Peter wrote:

bitrex <us...@example.net> wrote

On 11/13/2021 2:09 AM, Klaus Kragelund wrote:
11.11.21 22:12, LM wrote:
If they stay in stock, life is getting better.

Yes, also other sites are showing stock

Maybe we are soon getting back to normal. Will be interesting to see if
prices go back to normal
--
Klaus

Pandemic shortages made a lot of manufacturers of various products
realize \"ugh we\'ve been selling this stuff way too cheap all along\" I think

I doubt it; this is just the usual cyclic thing, where a shorateg is
artifically created (by various events, which usually merge into the
distis telling everybody that x is on allocation, upon which the users
shit themselves and multi-order everything they can) and then
collapses a year or so later.

This will go the same way.

I have quite enjoyed designing out parts by Mr Ripoff (Maxim) and
replacing them with ST parts, and some TI parts.


Herr Ripoff:

https://www.motor1.com/news/532591/mercedes-bmw-keep-prices-high/

\"We could lower them again but why\"

It\'s the same for all auto makers. They can keep price high as long as everybody is doing it. Anyway, we have to adjust to having less cars. There is no need for 1.88 car per household.

Not every luxury/performance manufacturer is doing great I don\'t think:

Tesla is pretty much eating up other luxury sales.

2021 2020 (est)
Revenue $34B $20B
Income $3B $1B
Margin 11% 10%

Both GM and Ford are doing better with less unit sales.

Earning year to date (Sept)

2021 2020
GM
Revenue $93.4B $84.9B
Income $8.3B $3.5B
Margin 8.9% 4.2%

Ford
Revenue $98.7B $91.2B
Income $5.7B $1.5B
Margin 5.7% 1.7%
 
On Fri, 12 Nov 2021 14:07:53 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

fredag den 12. november 2021 kl. 18.33.10 UTC+1 skrev jla...@highlandsniptechnology.com:
On Fri, 12 Nov 2021 18:10:53 +0200, LM <sala...@mail.com> wrote:

I could use a 100 pin LQFP, but when it is impossible to know what
part is available next week, I cannot.

On Thu, 11 Nov 2021 13:56:52 -0800, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Thu, 11 Nov 2021 23:12:56 +0200, LM <sala...@mail.com> wrote:

If they stay in stock, life is getting better.

Alas, not in our package. But maybe things are breaking.
We use STM32F207IGT6, LQFP176 package, in several products. The
question is whether we should gamble on them becoming available, and
design them into a new product.

why the F207? seems to me the F407 is more common, it is probably pin compatible
just just faster and with an FPU, M4 vs. M3 core

I don\'t know. Some people selected it last year, as a replacement for
an EOL NXP part for new designs. It seems plenty fast.

The applications are mostly bare-metal, fairly undemanding instrument
controllers. An FPGA often does the heavy lifting.

We still ship products with 68332\'s, still available. It is older than
some of my engineers.

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon
 
On Fri, 12 Nov 2021 14:07:53 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

fredag den 12. november 2021 kl. 18.33.10 UTC+1 skrev jla...@highlandsniptechnology.com:
On Fri, 12 Nov 2021 18:10:53 +0200, LM <sala...@mail.com> wrote:

I could use a 100 pin LQFP, but when it is impossible to know what
part is available next week, I cannot.

On Thu, 11 Nov 2021 13:56:52 -0800, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Thu, 11 Nov 2021 23:12:56 +0200, LM <sala...@mail.com> wrote:

If they stay in stock, life is getting better.

Alas, not in our package. But maybe things are breaking.
We use STM32F207IGT6, LQFP176 package, in several products. The
question is whether we should gamble on them becoming available, and
design them into a new product.

why the F207? seems to me the F407 is more common, it is probably pin compatible
just just faster and with an FPU, M4 vs. M3 core

I don\'t know. Some people selected it last year, as a replacement for
an EOL NXP part for new designs. It seems plenty fast.

The applications are mostly bare-metal, fairly undemanding instrument
controllers. An FPGA often does the heavy lifting.

We still ship products with 68332\'s, still available. It is older than
some of my engineers.

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon
 
On Fri, 12 Nov 2021 14:07:53 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

fredag den 12. november 2021 kl. 18.33.10 UTC+1 skrev jla...@highlandsniptechnology.com:
On Fri, 12 Nov 2021 18:10:53 +0200, LM <sala...@mail.com> wrote:

I could use a 100 pin LQFP, but when it is impossible to know what
part is available next week, I cannot.

On Thu, 11 Nov 2021 13:56:52 -0800, John Larkin
jlarkin@highland_atwork_technology.com> wrote:

On Thu, 11 Nov 2021 23:12:56 +0200, LM <sala...@mail.com> wrote:

If they stay in stock, life is getting better.

Alas, not in our package. But maybe things are breaking.
We use STM32F207IGT6, LQFP176 package, in several products. The
question is whether we should gamble on them becoming available, and
design them into a new product.

why the F207? seems to me the F407 is more common, it is probably pin compatible
just just faster and with an FPU, M4 vs. M3 core

I don\'t know. Some people selected it last year, as a replacement for
an EOL NXP part for new designs. It seems plenty fast.

The applications are mostly bare-metal, fairly undemanding instrument
controllers. An FPGA often does the heavy lifting.

We still ship products with 68332\'s, still available. It is older than
some of my engineers.

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon
 
On a sunny day (Mon, 15 Nov 2021 20:03:14 +0200) it happened Dimiter_Popoff
<dp@tgi-sci.com> wrote in <smu7d3$emg$1@dont-email.me>:

On 11/15/2021 19:40, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 19:03:50 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smu3tn$8jl$1@dont-email.me>:

On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.

Cool!

Read:
https://unix.stackexchange.com/questions/48770/how-to-match-case-insensitive-patterns-with-ls
to list files ignoring case

You don\'t have to convince me a solution can be programmed to just about
any flaw, including the file naming in unix.



Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.



Their file names are case dependent;

And that is a GOOD thing!
You need to learn how to search with
locate -i
As you likely know mA is not the same as MA and mOhm is not MOhm


Yeah, good thing you figured out an exception to cling to,
see my comment above.

Then the naming is not the only shortcoming of the unix filesystem,
it (like that of windows) makes worst fit allocation impractical.

You really need to read up on this stuff if you want to use it.
I have NEVER encoutered a problem with Linux file systems, and tried many and use many.

Oh I am sure it works, in its flawed by design way. Not using \"worst
fit\" for allocation brings just more fragmentation than there has to be
which you probably have not even noticed - or did not know there
was life without it.
And you have learned to live with the flawed use of text.


But MS windows crap filesystem as it comes with some USB sticks or is used by my Chinese digital TV receivers
even limit file size to 4293402624 bytes.
4293402624 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_1.ts
41383680 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_2.ts

-> 2^32 = 4294967296

I never intended to compare these two filesystems. The MS approach with
file names is the correct one though, and the unix\' use of text for file
names is the flawed one, that much is obvious.


The latter can be fixed by writing/adopting a well designed filesystem;
the naming flaw cannot be fixed.

You are just blaming the car that you do not know how to drive.


Yeah, what do I know about filesystems. How many filesystems have
you designed.

I know you cannot switch off from fuming mode - your entering of which I
predicted - so I suggest you just let it go, you don\'t really know what
you are talking about.

Have a nice evening.

I am not in fuming mode, just trying to teach you, but
you seemingly just post insults to get a response as you feel so lonely (your own words in previous posts)
Maybe get a cat or dog ? Or go to bar and try it there?

So you almost qualify for the filter now.
 
On a sunny day (Mon, 15 Nov 2021 20:03:14 +0200) it happened Dimiter_Popoff
<dp@tgi-sci.com> wrote in <smu7d3$emg$1@dont-email.me>:

On 11/15/2021 19:40, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 19:03:50 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smu3tn$8jl$1@dont-email.me>:

On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.

Cool!

Read:
https://unix.stackexchange.com/questions/48770/how-to-match-case-insensitive-patterns-with-ls
to list files ignoring case

You don\'t have to convince me a solution can be programmed to just about
any flaw, including the file naming in unix.



Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.



Their file names are case dependent;

And that is a GOOD thing!
You need to learn how to search with
locate -i
As you likely know mA is not the same as MA and mOhm is not MOhm


Yeah, good thing you figured out an exception to cling to,
see my comment above.

Then the naming is not the only shortcoming of the unix filesystem,
it (like that of windows) makes worst fit allocation impractical.

You really need to read up on this stuff if you want to use it.
I have NEVER encoutered a problem with Linux file systems, and tried many and use many.

Oh I am sure it works, in its flawed by design way. Not using \"worst
fit\" for allocation brings just more fragmentation than there has to be
which you probably have not even noticed - or did not know there
was life without it.
And you have learned to live with the flawed use of text.


But MS windows crap filesystem as it comes with some USB sticks or is used by my Chinese digital TV receivers
even limit file size to 4293402624 bytes.
4293402624 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_1.ts
41383680 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_2.ts

-> 2^32 = 4294967296

I never intended to compare these two filesystems. The MS approach with
file names is the correct one though, and the unix\' use of text for file
names is the flawed one, that much is obvious.


The latter can be fixed by writing/adopting a well designed filesystem;
the naming flaw cannot be fixed.

You are just blaming the car that you do not know how to drive.


Yeah, what do I know about filesystems. How many filesystems have
you designed.

I know you cannot switch off from fuming mode - your entering of which I
predicted - so I suggest you just let it go, you don\'t really know what
you are talking about.

Have a nice evening.

I am not in fuming mode, just trying to teach you, but
you seemingly just post insults to get a response as you feel so lonely (your own words in previous posts)
Maybe get a cat or dog ? Or go to bar and try it there?

So you almost qualify for the filter now.
 
On a sunny day (Mon, 15 Nov 2021 20:03:14 +0200) it happened Dimiter_Popoff
<dp@tgi-sci.com> wrote in <smu7d3$emg$1@dont-email.me>:

On 11/15/2021 19:40, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 19:03:50 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smu3tn$8jl$1@dont-email.me>:

On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.

Cool!

Read:
https://unix.stackexchange.com/questions/48770/how-to-match-case-insensitive-patterns-with-ls
to list files ignoring case

You don\'t have to convince me a solution can be programmed to just about
any flaw, including the file naming in unix.



Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.



Their file names are case dependent;

And that is a GOOD thing!
You need to learn how to search with
locate -i
As you likely know mA is not the same as MA and mOhm is not MOhm


Yeah, good thing you figured out an exception to cling to,
see my comment above.

Then the naming is not the only shortcoming of the unix filesystem,
it (like that of windows) makes worst fit allocation impractical.

You really need to read up on this stuff if you want to use it.
I have NEVER encoutered a problem with Linux file systems, and tried many and use many.

Oh I am sure it works, in its flawed by design way. Not using \"worst
fit\" for allocation brings just more fragmentation than there has to be
which you probably have not even noticed - or did not know there
was life without it.
And you have learned to live with the flawed use of text.


But MS windows crap filesystem as it comes with some USB sticks or is used by my Chinese digital TV receivers
even limit file size to 4293402624 bytes.
4293402624 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_1.ts
41383680 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_2.ts

-> 2^32 = 4294967296

I never intended to compare these two filesystems. The MS approach with
file names is the correct one though, and the unix\' use of text for file
names is the flawed one, that much is obvious.


The latter can be fixed by writing/adopting a well designed filesystem;
the naming flaw cannot be fixed.

You are just blaming the car that you do not know how to drive.


Yeah, what do I know about filesystems. How many filesystems have
you designed.

I know you cannot switch off from fuming mode - your entering of which I
predicted - so I suggest you just let it go, you don\'t really know what
you are talking about.

Have a nice evening.

I am not in fuming mode, just trying to teach you, but
you seemingly just post insults to get a response as you feel so lonely (your own words in previous posts)
Maybe get a cat or dog ? Or go to bar and try it there?

So you almost qualify for the filter now.
 
On a sunny day (Mon, 15 Nov 2021 20:03:14 +0200) it happened Dimiter_Popoff
<dp@tgi-sci.com> wrote in <smu7d3$emg$1@dont-email.me>:

On 11/15/2021 19:40, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 19:03:50 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smu3tn$8jl$1@dont-email.me>:

On 11/15/2021 17:51, Jan Panteltje wrote:
On a sunny day (Mon, 15 Nov 2021 17:35:02 +0200) it happened Dimiter_Popoff
dp@tgi-sci.com> wrote in <smtun7$6v6$1@dont-email.me>:

The unix filenaming system is broken by design.

It is super good!


Yeah, you can have 512 files named Panteltie using different cases.

Cool!

Read:
https://unix.stackexchange.com/questions/48770/how-to-match-case-insensitive-patterns-with-ls
to list files ignoring case

You don\'t have to convince me a solution can be programmed to just about
any flaw, including the file naming in unix.



Very advanced, how stupid people have been to stick to the Latin
alphabet for millenia.



Their file names are case dependent;

And that is a GOOD thing!
You need to learn how to search with
locate -i
As you likely know mA is not the same as MA and mOhm is not MOhm


Yeah, good thing you figured out an exception to cling to,
see my comment above.

Then the naming is not the only shortcoming of the unix filesystem,
it (like that of windows) makes worst fit allocation impractical.

You really need to read up on this stuff if you want to use it.
I have NEVER encoutered a problem with Linux file systems, and tried many and use many.

Oh I am sure it works, in its flawed by design way. Not using \"worst
fit\" for allocation brings just more fragmentation than there has to be
which you probably have not even noticed - or did not know there
was life without it.
And you have learned to live with the flawed use of text.


But MS windows crap filesystem as it comes with some USB sticks or is used by my Chinese digital TV receivers
even limit file size to 4293402624 bytes.
4293402624 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_1.ts
41383680 Jul 8 2020 /mnt/sda2/video/satellite/magnum_3x_part_2.ts

-> 2^32 = 4294967296

I never intended to compare these two filesystems. The MS approach with
file names is the correct one though, and the unix\' use of text for file
names is the flawed one, that much is obvious.


The latter can be fixed by writing/adopting a well designed filesystem;
the naming flaw cannot be fixed.

You are just blaming the car that you do not know how to drive.


Yeah, what do I know about filesystems. How many filesystems have
you designed.

I know you cannot switch off from fuming mode - your entering of which I
predicted - so I suggest you just let it go, you don\'t really know what
you are talking about.

Have a nice evening.

I am not in fuming mode, just trying to teach you, but
you seemingly just post insults to get a response as you feel so lonely (your own words in previous posts)
Maybe get a cat or dog ? Or go to bar and try it there?

So you almost qualify for the filter now.
 

Welcome to EDABoard.com

Sponsor

Back
Top