I was under the impression that all devices using flash memory had some
kind of wear-levelling logic built into their controllers. But now I hear that the level of sophistication of this varies. Namely, while SSDs, meant for running OS installations and active user filesystems, put the most
effort into prolonging their lives, SD cards and USB sticks do not.
So it makes sense to use some more flash-aware filesystem on the latter devices, to help reduce the wear on them as well. Looking at the Wikipedia list <https://en.wikipedia.org/wiki/Flash_file_system>, it seems like F2FS
is the best bet.
Anybody tried this sort of thing?
Anybody tried this sort of thing?
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Anybody tried this sort of thing?
I did a quick trial. My newish Sony Google/Android/whatsit TV ignored
the f2fs stick, my Samsung phone "helpfully" offered to format the f2fs stick, probably to exFAT. Extra annoying as the phone uses f2fs on its internal storage so the support is there.
So f2fs might be nice and all but it seems, with this experiment, that I can't think of a supported use case for an f2fs formatted USB stick or
SD card.
Did you have some use in mind?
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Anybody tried this sort of thing?
I did a quick trial. My newish Sony Google/Android/whatsit TV ignored
the f2fs stick, my Samsung phone "helpfully" offered to format the f2fs stick, probably to exFAT. Extra annoying as the phone uses f2fs on its internal storage so the support is there.
So f2fs might be nice and all but it seems, with this experiment, that I can't think of a supported use case for an f2fs formatted USB stick or
SD card.
Did you have some use in mind?
On 3/21/25 5:20 AM, Anssi Saari wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
If you want compatibility with 'devices' then you're
kinda stuck with FAT32. USB sticks always come formatted
that way, it's just "the standard".
On 3/20/25 11:04 PM, Lawrence D'Oliveiro wrote:
I was under the impression that all devices using flash memory had some
kind of wear-levelling logic built into their controllers. But now I hear
that the level of sophistication of this varies. Namely, while SSDs,
meant
for running OS installations and active user filesystems, put the most
effort into prolonging their lives, SD cards and USB sticks do not.
So it makes sense to use some more flash-aware filesystem on the latter
devices, to help reduce the wear on them as well. Looking at the
Wikipedia
list <https://en.wikipedia.org/wiki/Flash_file_system>, it seems like
F2FS
is the best bet.
Anybody tried this sort of thing?
Gparted has F2FS as a formatting option ...
"Internet appliances" like some router/firewalls are a
small Linux system under the cover and *sometimes* can
cope with EXT3/EXT4 sticks, but never tried F2FS.
On 2025-03-21 12:31, c186282 wrote:
On 3/21/25 5:20 AM, Anssi Saari wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
If you want compatibility with 'devices' then you're
kinda stuck with FAT32. USB sticks always come formatted
that way, it's just "the standard".
I think I bought one memory card that came in exFAT. Can't be 100% sure, maybe it was the camera that formatted it that way.
On 21/03/2025 07:13, c186282 wrote:
Gparted has F2FS as a formatting option ...
I think you are chasing Unicorns here.
SD cards and thumb drives are designed as limited usage cheap storage,
and no amount of faffing around with filesystems is going to change
that. At some stage no matter what file system is in operation data
needs to be (over) written and blocks need to be erased to do it.
Professional level SSDs are designed to adapt the writes to extract
the best out of a limited block erase life, and that's that, and you
pay for that by using a more conservative memory cell design and
hanging a lot of smarts in front of it.
Since there is no 1:1 correlation between the sector you think you are writing to, and the actual physical RAM on even a thumbdrive, there is nothing you can do at the operating system level other than caching
your writes and doing them in single big chunks in the hope that some
of them end up in the same erase page, and using the DISCARD function.
On 21/03/2025 11:31, c186282 wrote:
"Internet appliances" like some router/firewalls are a
small Linux system under the cover and *sometimes* can
cope with EXT3/EXT4 sticks, but never tried F2FS.
My home Pi's run off SD cards but never in normal use write to them AT ALL. There is a series of configuration you can do that moves logging to RAMdisk and any temporary files to RAMdisk as well - and you turn swap off.
For small applications that is a perfect way to have access to Linux, but not go to the expense of a proper SSD
On 2025-03-21 12:31, c186282 wrote:
On 3/21/25 5:20 AM, Anssi Saari wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
If you want compatibility with 'devices' then you're
kinda stuck with FAT32. USB sticks always come formatted
that way, it's just "the standard".
I think I bought one memory card that came in exFAT. Can't be 100% sure, maybe it was the camera that formatted it that way.
I saved a compressed image of the original card, so I can find out.
cer@Telcontar:/data/storage_b/copias_usb_sticks/vacios/EMTEC C410 -
64GB> file image
image: DOS/MBR boot sector MS-MBR XP english at offset 0x12c "Invalid partition table" at offset 0x144 "Error loading operating system" at
offset 0x163 "Missing operating system", disk signature 0x59f161dc;
partition 1 : ID=0xc, start-CHS (0x0,63,1), end-CHS (0xe2,16,1),
startsector 8064, 121137280 sectors
Ok, so it has a partition table. Long time I don't do this...
Telcontar:/data/storage_b/copias_usb_sticks/vacios/EMTEC C410 - 64GB # mount -o ro,loop=/dev/loop0 image mnt/
mount: mnt/: failed to setup loop device for /data/storage_b/copias_usb_sticks/vacios/EMTEC C410 - 64GB/image.
Huh. This is new. :-?
Telcontar:/data/storage_b/copias_usb_sticks/vacios/EMTEC C410 - 64GB #
fdisk -l image
Disk image: 57,77 GiB, 62026416128 bytes, 121145344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x59f161dc
Device Boot Start End Sectors Size Id Type image1 8064 121145343 121137280 57,8G c W95 FAT32 (LBA) Telcontar:/data/storage_b/copias_usb_sticks/vacios/EMTEC C410 - 64GB #
Trying gparted... it says fat32. Ok, doubt solved :-)
On Fri, 21 Mar 2025, The Natural Philosopher wrote:
On 21/03/2025 11:31, c186282 wrote:
"Internet appliances" like some router/firewalls are a
small Linux system under the cover and *sometimes* can
cope with EXT3/EXT4 sticks, but never tried F2FS.
My home Pi's run off SD cards but never in normal use write to them AT
ALL.
There is a series of configuration you can do that moves logging to
RAMdisk and any temporary files to RAMdisk as well - and you turn swap
off.
For small applications that is a perfect way to have access to Linux,
but not go to the expense of a proper SSD
This is the truth! I do the same thing, and they happily chug along for years.
My other usage is Raspberry Pi SD cards which are two partitions in IIRC
VFAT and EXT4
Had one running a decade that way - old Pi, the one with
fewer GPIO pins - did it's one little job so quietly I
forgot it was there. Anyway, for most Pi uses what you
describe is probably the ideal setup.
And with modern RAM capacities, swap should never be
needed.
On Fri, 21 Mar 2025 19:11:40 +0000, The Natural Philosopher wrote:
My other usage is Raspberry Pi SD cards which are two partitions in IIRC
VFAT and EXT4
That may be inherited from Debian. vfat is used for /boot/firmware or / boot/efi for UEFI compatibility.
Not from Debian, but for the same reason that like UEFI, the RPi
firmware only has drivers for FAT (FAT32, or FAT16 works too, I'm not
sure if any new ones support exFAT).
On Fri, 21 Mar 2025 19:11:40 +0000, The Natural Philosopher wrote:
My other usage is Raspberry Pi SD cards which are two partitions in IIRC
VFAT and EXT4
That may be inherited from Debian. vfat is used for /boot/firmware or / boot/efi for UEFI compatibility.
fwiw when it's mounted the Pico 2 shows as vfat. I assume the Pico does also but the two I have hooked up are running so don't show as a mount.
c186282 <c186282@nnada.net> wrote:
Had one running a decade that way - old Pi, the one with
fewer GPIO pins - did it's one little job so quietly I
forgot it was there. Anyway, for most Pi uses what you
describe is probably the ideal setup.
And with modern RAM capacities, swap should never be
needed.
That depends, the Pi Zeros still have only 512MB and anyway it
depends what you're trying to do. Compressed swap in RAM is a good alternative to a swap file/partition on such hardware, albeit
mainly as a safety net to avoid crashes rather than something to
rely on often.
At present, every Linux I've used, the UEFI stuff is
ALWAYS in a FAT partition. However it's SMALL, not
a prob.
Don't love UEFI at all
c186282 <c186282@nnada.net> wrote:
At present, every Linux I've used, the UEFI stuff is
ALWAYS in a FAT partition. However it's SMALL, not
a prob.
Since you can put live and rescue images in the UEFI partition, I
usually make it 2 Gig or so. That's not SMALL.
Don't love UEFI at all
You should! It's neat.
Frankly I hate the bloody things. I use them as little as possible, My camera has something in it but it talks via USB to the computer so I
have no idea what format it actually is
Ditto my mobile phone
Since there is no 1:1 correlation between the sector you think you are writing to, and the actual physical RAM on even a thumbdrive, there is nothing you can do at the operating system level other than caching your writes and doing them in single big chunks in the hope that some of them
end up in the same erase page, and using the DISCARD function.
On Fri, 21 Mar 2025 19:11:40 +0000, The Natural Philosopher wrote:
My other usage is Raspberry Pi SD cards which are two partitions in IIRC
VFAT and EXT4
That may be inherited from Debian. vfat is used for /boot/firmware or / boot/efi for UEFI compatibility.
fwiw when it's mounted the Pico 2 shows as vfat. I assume the Pico does also but the two I have hooked up are running so don't show as a mount.
rbowman <bowman@montana.com> wrote:
On Fri, 21 Mar 2025 19:11:40 +0000, The Natural Philosopher wrote:
My other usage is Raspberry Pi SD cards which are two partitions in IIRC >>> VFAT and EXT4
That may be inherited from Debian. vfat is used for /boot/firmware or /
boot/efi for UEFI compatibility.
Not from Debian, but for the same reason that like UEFI, the RPi
firmware only has drivers for FAT (FAT32, or FAT16 works too,
I'm not sure if any new ones support exFAT).
To run in a tmpfs, I set up Linux on a FAT partition on an SD
card. No need for a separate EXT* partition if you're not mounting
any as / anyway.
On 3/21/25 8:41 PM, rbowman wrote:Sad but true. I am sure its all frightfully necessary, but for home use
On Fri, 21 Mar 2025 19:11:40 +0000, The Natural Philosopher wrote:
My other usage is Raspberry Pi SD cards which are two partitions in IIRC >>> VFAT and EXT4
That may be inherited from Debian. vfat is used for /boot/firmware or /
boot/efi for UEFI compatibility.
fwiw when it's mounted the Pico 2 shows as vfat. I assume the Pico does >> also but the two I have hooked up are running so don't show as a mount.
At present, every Linux I've used, the UEFI stuff is
ALWAYS in a FAT partition. However it's SMALL, not
a prob.
Don't love UEFI at all ... but these days it's harder
and harder to NOT have that partition.
And with modern RAM capacities, swap should never be
needed.
On 3/21/25 9:47 PM, Computer Nerd Kev wrote:
c186282 <c186282@nnada.net> wrote:
Had one running a decade that way - old Pi, the one with
fewer GPIO pins - did it's one little job so quietly I
forgot it was there. Anyway, for most Pi uses what you
describe is probably the ideal setup.
And with modern RAM capacities, swap should never be
needed.
That depends, the Pi Zeros still have only 512MB and anyway it
depends what you're trying to do. Compressed swap in RAM is a good
alternative to a swap file/partition on such hardware, albeit
mainly as a safety net to avoid crashes rather than something to
rely on often.
512mb is *huge* compared to The Old Days.
My first IBM-PC had, with added memory card, 512 KILObytes.
You had to put all the little chippies into the board by
yourself ... NOT bending the contact legs ......
However 2-4gb is most common now.
Zero's ARE kinda 'special purpose' however ... kinda
aimed at being the middle point between microcontrollers
and 'real computers'. It's a valid niche.
But, stick to the niche - if you NEED swap space then
you're going above and beyond. Compu-Ozempic is required.
On 2025-03-21 20:11, The Natural Philosopher wrote:
Frankly I hate the bloody things. I use them as little as possible,
My camera has something in it but it talks via USB to the computer so
I have no idea what format it actually is
Ditto my mobile phone
Yes, my camera talks via USB to the computer, but it is slower than
directly connecting the card, and uses battery. Linux is very good at handling different filesystems.
On 22/03/2025 08:38, c186282 wrote:
On 3/21/25 8:41 PM, rbowman wrote:Sad but true. I am sure its all frightfully necessary, but for home use
On Fri, 21 Mar 2025 19:11:40 +0000, The Natural Philosopher wrote:
My other usage is Raspberry Pi SD cards which are two partitions in
IIRC
VFAT and EXT4
That may be inherited from Debian. vfat is used for /boot/firmware or / >>> boot/efi for UEFI compatibility.
fwiw when it's mounted the Pico 2 shows as vfat. I assume the Pico
does
also but the two I have hooked up are running so don't show as a mount.
At present, every Linux I've used, the UEFI stuff is
ALWAYS in a FAT partition. However it's SMALL, not
a prob.
Don't love UEFI at all ... but these days it's harder
and harder to NOT have that partition.
you just want to boot the bloody computer, not have to go through all
that rigmarole.
On 2025-03-22 11:21, Marc Haber wrote:
Since you can put live and rescue images in the UEFI partition, I
usually make it 2 Gig or so. That's not SMALL.
That's interesting.
Do you have a link on info on that?
Don't love UEFI at all
You should! It's neat.
Yep.
At present, every Linux I've used, the UEFI stuff is ALWAYS in a FAT
partition. However it's SMALL, not a prob.
Don't love UEFI at all ... but these days it's harder and harder to
NOT have that partition.
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk;
UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot
in Windows 8 it became a major PITA to dual boot before the Linux distros >caught up.
At home, many people boot multiple operating systems from the same disk;
UEFI has made this easier.
The PICO has no filesystem. IN use you hold a button down while powering
up and it's Flash presents itself as a USB drive. You copy a special
binary file of compiled code onto that 'drive', and it reboots and runs
it..
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk;
UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot
in Windows 8 it became a major PITA to dual boot before the Linux distros caught up.
On Sat, 22 Mar 2025 04:38:40 -0400, c186282 wrote:
At present, every Linux I've used, the UEFI stuff is ALWAYS in a FAT
partition. However it's SMALL, not a prob.
Yes, it's /boot and usually under 1 GB.
Don't love UEFI at all ... but these days it's harder and harder to
NOT have that partition.
The Fedora box was pre-UEFI. /boot is ext4 and the rest of the SSD is
btrfs. It had OpenSUSE 13.2 previously which used btrfs for /boot by default. The machine would not start until I selected ext4. At the time
there grub2 couldn't handle btrfs. I don't know if Fedora is playing it
safe.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2025-03-22 11:21, Marc Haber wrote:
Since you can put live and rescue images in the UEFI partition, I
usually make it 2 Gig or so. That's not SMALL.
That's interesting.
Do you have a link on info on that?
You can boot live images via grub, so boot grub via UEFI and point it
towards the iso that also resides on the UEFI partition. The
grml-rescueboot package on Debian-based systems might give some hints.
Don't love UEFI at all
You should! It's neat.
Yep.
I am positively impressed every time my fwupdmgr puts a Firmware
update on the UEFI partition and the next system boot will
transparently install it. From a Linux OS!
You can boot live images via grub, so boot grub via UEFI and point it
towards the iso that also resides on the UEFI partition. The
grml-rescueboot package on Debian-based systems might give some hints.
Dual Boot has always an unstable, fragile PITA.
On 22/03/2025 01:42, Computer Nerd Kev wrote:
rbowman <bowman@montana.com> wrote:Then what are you mounting as / ?
On Fri, 21 Mar 2025 19:11:40 +0000, The Natural Philosopher wrote:
My other usage is Raspberry Pi SD cards which are two partitions in IIRC >>>> VFAT and EXT4
That may be inherited from Debian. vfat is used for /boot/firmware or / >>> boot/efi for UEFI compatibility.
Not from Debian, but for the same reason that like UEFI, the RPi
firmware only has drivers for FAT (FAT32, or FAT16 works too,
I'm not sure if any new ones support exFAT).
To run in a tmpfs, I set up Linux on a FAT partition on an SD
card. No need for a separate EXT* partition if you're not mounting
any as / anyway.
I don't understand Linux needs a root filesystem that accepts linux permissions, VFAT does not
rbowman <bowman@montana.com> wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot
in Windows 8 it became a major PITA to dual boot before the Linux distros >>caught up.
Dual Boot has always an unstable, fragile PITA.
A Pi Zero only has 512MByte
X-windows isn't even going to get out of bed with that.
Marc Haber <mh+usenetspam1118@zugschl.us> writes:
You can boot live images via grub, so boot grub via UEFI and point it
towards the iso that also resides on the UEFI partition. The
grml-rescueboot package on Debian-based systems might give some hints.
But why the EFI partition? Grub can boot images from any partition. I
keep my collection of GRML images on a largish stuff partition on an HD
and the grml-rescueboot adds those to the grub menu.
rbowman <bowman@montana.com> wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same
disk;
UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot
in Windows 8 it became a major PITA to dual boot before the Linux
distros caught up.
Dual Boot has always an unstable, fragile PITA. Thankfully we have Virtualization now which has Dual Boot mostly obsolete.
rbowman <bowman@montana.com> wrote:+1.
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot
in Windows 8 it became a major PITA to dual boot before the Linux distros
caught up.
Dual Boot has always an unstable, fragile PITA. Thankfully we have Virtualization now which has Dual Boot mostly obsolete.
Greetings
Marc
On Sat, 22 Mar 2025 13:35:54 +0000, The Natural Philosopher wrote:
The PICO has no filesystem. IN use you hold a button down while powering
up and it's Flash presents itself as a USB drive. You copy a special
binary file of compiled code onto that 'drive', and it reboots and runs
it..
Okay, you hold down BOOTSEL when plugging it into the USB. Then it shows
up on Files as RP2350. If you click on that you see INDEX.HTM and INFO_UF2.TXT. If you look at Properties it reports 2 items totaling 305
bytes and 134.1 MB free.
df -Th /dev/sda1
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 vfat 128M 8.0K 128M 1% /media/xxxxx/RP2350
Then you can
cp blink.uf2 /media/xxxxx/RP2350/
and, lo and behold, it starts blinking and vanishes from the file system!
I'm lazy so after it blinks 20 times it calls
reset_usb_boot(0, 0);
and miraculously reappears mounted. How does it do all this without a
file system known to Ubuntu? I won't even ask why after copying the CircuitPython uf2 it reboots mounted as CIRCUITPYTHON and you can copy .py files directly.
My comment had nothing to do with the programmatic use of the flash
memory, only how the Pico presents as a mass storage device.
Marc Haber <mh+usenetspam1118@zugschl.us> writes:
Dual Boot has always an unstable, fragile PITA.
I've usually had two or more OSes on my main PC, since from around 1995
or so. Hasn't been unstable, fragile or PITA.
On 2025-03-22 17:29, Marc Haber wrote:
You can boot live images via grub, so boot grub via UEFI and point it
towards the iso that also resides on the UEFI partition. The
grml-rescueboot package on Debian-based systems might give some hints.
Ah. So not directly from uefi. Not much use when it is grub which is
failing.
Don't love UEFI at all
You should! It's neat.
Yep.
I am positively impressed every time my fwupdmgr puts a Firmware
update on the UEFI partition and the next system boot will
transparently install it. From a Linux OS!
I have not done that.
Marc Haber <mh+usenetspam1118@zugschl.us> writes:
You can boot live images via grub, so boot grub via UEFI and point it
towards the iso that also resides on the UEFI partition. The
grml-rescueboot package on Debian-based systems might give some hints.
But why the EFI partition?
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
rbowman <bowman@montana.com> wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot >>>in Windows 8 it became a major PITA to dual boot before the Linux distros >>>caught up.
Dual Boot has always an unstable, fragile PITA.
The only thing that made it unstable for me was when distros
switched to Grub 2. So I started throwing that away in favour of >SysLinux/ExtLinux and things have been easy again.
On 2025-03-22 18:52, rbowman wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot
in Windows 8 it became a major PITA to dual boot before the Linux distros
caught up.
Define "fine".
Like buying a machine and all 4 primaries are in use?
Secure boot is a different beast.
Marc Haber <mh+usenetspam1118@zugschl.us> writes:
Dual Boot has always an unstable, fragile PITA.
I've usually had two or more OSes on my main PC, since from around 1995
or so. Hasn't been unstable, fragile or PITA. Virtualization isn't a
solution for my current use case of having Windows for games, Arch Linux
for seeing how new Linux stuff runs and looks like on my HW and Debian
for everything else.
On 3/22/25 3:39 PM, Carlos E.R. wrote:
On 2025-03-22 18:52, rbowman wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot >>> in Windows 8 it became a major PITA to dual boot before the Linux distros >>> caught up.
Define "fine".
Like buying a machine and all 4 primaries are in use?
Secure boot is a different beast.
One of my major gripes with UEFI is that M$
loved it SO much. As such I suspect evil in
there somewhere. It also just COMPLICATES
boots yet another level.
On 2025-03-21 20:11, The Natural Philosopher wrote:
Frankly I hate the bloody things. I use them as little as possible,
My camera has something in it but it talks via USB to the computer so
I have no idea what format it actually is
Ditto my mobile phone
Yes, my camera talks via USB to the computer, but it is slower than
directly connecting the card, and uses battery. Linux is very good at handling different filesystems.
On 22/03/2025 19:09, rbowman wrote:
On Sat, 22 Mar 2025 13:35:54 +0000, The Natural Philosopher wrote:
The PICO has no filesystem. IN use you hold a button down while powering >>> up and it's Flash presents itself as a USB drive. You copy a special
binary file of compiled code onto that 'drive', and it reboots and runs
it..
Okay, you hold down BOOTSEL when plugging it into the USB. Then it shows
up on Files as RP2350. If you click on that you see INDEX.HTM and
INFO_UF2.TXT. If you look at Properties it reports 2 items totaling 305
bytes and 134.1 MB free.
df -Th /dev/sda1
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 vfat 128M 8.0K 128M 1% /media/xxxxx/RP2350
Then you can
cp blink.uf2 /media/xxxxx/RP2350/
and, lo and behold, it starts blinking and vanishes from the file system!
I'm lazy so after it blinks 20 times it calls
reset_usb_boot(0, 0);
and miraculously reappears mounted. How does it do all this without a
file system known to Ubuntu? I won't even ask why after copying the
CircuitPython uf2 it reboots mounted as CIRCUITPYTHON and you can copy
.py
files directly.
My comment had nothing to do with the programmatic use of the flash
memory, only how the Pico presents as a mass storage device.
Well it spoofs the disk obviously
c186282 <c186282@nnada.net> wrote:
On 3/22/25 3:39 PM, Carlos E.R. wrote:
On 2025-03-22 18:52, rbowman wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>>>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot >>>> in Windows 8 it became a major PITA to dual boot before the Linux distros >>>> caught up.
Define "fine".
Like buying a machine and all 4 primaries are in use?
Secure boot is a different beast.
One of my major gripes with UEFI is that M$
loved it SO much. As such I suspect evil in
there somewhere. It also just COMPLICATES
boots yet another level.
Let me bet: You are a fan of IPv4 and you hate IPv6 because it's so complicated.
People going down this road of argument usually are what we in German
call "Betriebsblind", being accustomed to the quirks of the old way
that they don't see the compelling simplicity of the new way.
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
Marc Haber <mh+usenetspam1118@zugschl.us> writes:
Dual Boot has always an unstable, fragile PITA.
I've usually had two or more OSes on my main PC, since from around 1995
or so. Hasn't been unstable, fragile or PITA.
Then you're lucky. To be able to fix a broken dualboot you need
intimate knowlegde of all platforms. Most people don't have that.
"Carlos E.R." <robin_listas@es.invalid> wrote:
On 2025-03-22 17:29, Marc Haber wrote:
You can boot live images via grub, so boot grub via UEFI and point it
towards the iso that also resides on the UEFI partition. The
grml-rescueboot package on Debian-based systems might give some hints.
Ah. So not directly from uefi. Not much use when it is grub which is
failing.
UEFI grub usually doesn't fail. It a least gets you to a shell. And
you can have a second grub for the rescue image.
Don't love UEFI at all
You should! It's neat.
Yep.
I am positively impressed every time my fwupdmgr puts a Firmware
update on the UEFI partition and the next system boot will
transparently install it. From a Linux OS!
I have not done that.
Just install fwupd and see it working automagically.
On 3/23/25 6:04 AM, Marc Haber wrote:
Let me bet: You are a fan of IPv4 and you hate IPv6 because it's so
complicated.
Yep ! DISABLE it !!! :-)
Though, eventually ......
Actually, just making IPv5, one more set of three,
would have solved The Problem for a LONG time. There
were other fixes as well.
People going down this road of argument usually are what we in German
call "Betriebsblind", being accustomed to the quirks of the old way
that they don't see the compelling simplicity of the new way.
"Old ways" aren't always BAD ways - sometimes they
are just common sense. Young bucks oft try to "do
better", but it's mostly ego and less practical.
In any case, hate, and see little use for, UEFI.
UEFI, on the other hand, is designed to boot multiple systems. Having
the boot signed is a different thing.
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
rbowman <bowman@montana.com> wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot >>>in Windows 8 it became a major PITA to dual boot before the Linux distros >>>caught up.
Dual Boot has always an unstable, fragile PITA.
The only thing that made it unstable for me was when distros
switched to Grub 2. So I started throwing that away in favour of SysLinux/ExtLinux and things have been easy again.
c186282 <c186282@nnada.net> wrote:
One of my major gripes with UEFI is that M$
loved it SO much. As such I suspect evil in
there somewhere. It also just COMPLICATES
boots yet another level.
c186282 <c186282@nnada.net> wrote:
One of my major gripes with UEFI is that M$
loved it SO much. As such I suspect evil in
there somewhere. It also just COMPLICATES
boots yet another level.
For me it's way more simple now, thanks to UEFI. I have no more LILO,
GRUB, rEFInd or anything else. Instead of launching a boot manager which >launches Linux, the UEFI directly launches Linux. So, removing a level in
the boot process isn't complicating things but simplifying them.
c186282 <c186282@nnada.net> wrote:
On 3/22/25 3:39 PM, Carlos E.R. wrote:
On 2025-03-22 18:52, rbowman wrote:
Dual boot worked find for years before UEFI. When MS went to secure
boot in Windows 8 it became a major PITA to dual boot before the
Linux distros caught up.
One of my major gripes with UEFI is that M$
loved it SO much. As such I suspect evil in
there somewhere. It also just COMPLICATES
boots yet another level.
Let me bet: You are a fan of IPv4 and you hate IPv6 because it's so complicated.
People going down this road of argument usually are what we in German
call "Betriebsblind", being accustomed to the quirks of the old way
that they don't see the compelling simplicity of the new way.
Ya know ..... think I'm gonna stay away from Pico's
If I want microcontrollers, there are more traditional straight-up
boards out there. If I want microprocessors there are the straight-up
PIs and beyond.
Did use PICs for a long time ... kinda remember their quirks and
tricks. There are Pico/Nano style boards to be had cheap that use
PICs. Atmel versions also exist.
On Sun, 23 Mar 2025 06:05:34 -0400, c186282 wrote:
Ya know ..... think I'm gonna stay away from Pico's
If I want microcontrollers, there are more traditional straight-up
boards out there. If I want microprocessors there are the straight-up
PIs and beyond.
Did use PICs for a long time ... kinda remember their quirks and
tricks. There are Pico/Nano style boards to be had cheap that use
PICs. Atmel versions also exist.
You pays your money and you makes your choice. You are right, there is a confusing selection of low cost boards compared to 15 or 20 years ago when boards like the Arduino or BeagleBone started to appear.
I still have an old AVR development board. I should get a USB to serial converter to see if it still works. I preferred the AVR instruction set to the PIC's.
Today you have to add a lot of qualifiers. The PIC32MX was based on the
MIPS architecture and was sort of a dead end. The PIC32C is ARM based.
Since Microchip bought Atmel, there are also the ATSAM ARM series. They're also coming out with the PIC64 based on the ARM Cortex A, rather than the Cortex M.
Even the Arduino Uno R4 Minima is a ARM processor. It looks and acts like
a UNO R3, which was the last of the ATMega line. Other Arduinos like the
Nano have moved on to ARM processors too.
Adafruit has the Feather boards some of which use the RP2040 like the
Pico. One of them comes loaded with CircuitPython so you don't even need a IDE. Plug it in, edit main.py, and you're good to go.
Then there are the ESP32 boards with RISC processors or the Pico 2 with 2
ARM cores and 2 RISC-V cores, take your pick.
If you're really a glutton for punishment, there is STM32. They're used
quite a bit in commercial embedded applications. The problem with them is there are a million (okay, not quite) variations with arcane part numbers.
Is it a F403 or a F411? How many pin does it have?
The newer uCs have more memory which means they can support CircuitPython
or MicroPython. Of course you can use a C/C++ SDK for more control and
faster execution but that will differ between processors unlike the more uniform Python abstraction.
Decisions, decisions... Most options are inexpensive, or really cheap if
you don't mind rolling the dice with AliExpress.
Just recently bought two Ards ... the old Uno and a 2560.
Have weather apps in mind and the libs easily do all the funky little
devices and one-wires and such and there's megatons of docs.
SOMEBODY does or did make something that looked a whole lot like a
PI, but used some PIC instead. A Pi is faster,
but the PIC likely uses lots less power and can go almost static
between interrupts. Job, best tool. Note the Ard low-power lib is
pretty damned good too, have used that with solar-powered units
before.
But is Cortex-based REALLY a "PIC" ???
16F84 was a PIC.
My fave PICs are the 12Fxxx 8-pin little lovelies.
So small, so cheap, so versatile. I've even used them to emulate
ordinary logic gates if speed was not super-critical ... that cheap,
and can be most anything you want, even drive a serial display.
However the bigger pain/expense lies in the 'development
systems/boards'. You don't just buy the chip - you have to be able to
program it too. Discourages experimenters.
On Sun, 23 Mar 2025 23:36:04 -0400, c186282 wrote:
Just recently bought two Ards ... the old Uno and a 2560.
Have weather apps in mind and the libs easily do all the funky little
devices and one-wires and such and there's megatons of docs.
Well, you shouldn't run out of pins with the 2560. I've got a few Uno R3s laying around and a couple of Nano 33 BLE Senses. The Nano is used in a
MIT ML course and they picked it because of all the onboard sensors rather than a bunch of loose components. It's based on the Nordic Cortex M4 uc.
SOMEBODY does or did make something that looked a whole lot like a
PI, but used some PIC instead. A Pi is faster,
but the PIC likely uses lots less power and can go almost static
between interrupts. Job, best tool. Note the Ard low-power lib is
pretty damned good too, have used that with solar-powered units
before.
There were quite a few. I used to subscribe to Steve Ciarcia's 'Circuit Cellar' and PIC projects were very popular.
But is Cortex-based REALLY a "PIC" ???
16F84 was a PIC.
My fave PICs are the 12Fxxx 8-pin little lovelies.
So small, so cheap, so versatile. I've even used them to emulate
ordinary logic gates if speed was not super-critical ... that cheap,
and can be most anything you want, even drive a serial display.
I've got some chips with a bunch of little legs that I assume are legacy AVRs. You could do a lot with them,
However the bigger pain/expense lies in the 'development
systems/boards'. You don't just buy the chip - you have to be able to
program it too. Discourages experimenters.
https://www.mikroe.com/easyavr
Yeah, the $215 is a barrier and then you wind up with a dead bug you have
to do something with. Of course you can go a lot cheaper:
https://www.walmart.com/ip/AVR-Development-Board-NO-Chip-Included-DIY- Set-for-8-48-with-USB-Input/2830964591
Walmart? Yeah I'm sure the local superstore has a bunch of them. Must be something similar for PICs or you can roll your own.
Microsoft liking something is not a coherent reason for disliking it.
On 3/22/25 8:52 PM, The Natural Philosopher wrote:
On 22/03/2025 19:09, rbowman wrote:
On Sat, 22 Mar 2025 13:35:54 +0000, The Natural Philosopher wrote:
The PICO has no filesystem. IN use you hold a button down while
powering
up and it's Flash presents itself as a USB drive. You copy a special
binary file of compiled code onto that 'drive', and it reboots and runs >>>> it..
Okay, you hold down BOOTSEL when plugging it into the USB. Then it shows >>> up on Files as RP2350. If you click on that you see INDEX.HTM and
INFO_UF2.TXT. If you look at Properties it reports 2 items totaling 305
bytes and 134.1 MB free.
df -Th /dev/sda1
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 vfat 128M 8.0K 128M 1% /media/xxxxx/RP2350 >>>
Then you can
cp blink.uf2 /media/xxxxx/RP2350/
and, lo and behold, it starts blinking and vanishes from the file
system!
I'm lazy so after it blinks 20 times it calls
reset_usb_boot(0, 0);
and miraculously reappears mounted. How does it do all this without a
file system known to Ubuntu? I won't even ask why after copying the
CircuitPython uf2 it reboots mounted as CIRCUITPYTHON and you can
copy .py
files directly.
My comment had nothing to do with the programmatic use of the flash
memory, only how the Pico presents as a mass storage device.
Well it spoofs the disk obviously
Ya know ..... think I'm gonna stay away from Pico's :-)
If I want microcontrollers, there are more traditional
straight-up boards out there. If I want microprocessors
there are the straight-up PIs and beyond.
Did use PICs for a long time ... kinda remember their
quirks and tricks. There are Pico/Nano style boards to
be had cheap that use PICs. Atmel versions also exist.
On 23/03/2025 18:02, Richard Kettlewell wrote:
Microsoft liking something is not a coherent reason for disliking it.
Well no but....
On 23/03/2025 10:05, c186282 wrote:
On 3/22/25 8:52 PM, The Natural Philosopher wrote:It is a big learning curve. But they are fearfully cheap...small...and
On 22/03/2025 19:09, rbowman wrote:
On Sat, 22 Mar 2025 13:35:54 +0000, The Natural Philosopher wrote:
The PICO has no filesystem. IN use you hold a button down while
powering
up and it's Flash presents itself as a USB drive. You copy a special >>>>> binary file of compiled code onto that 'drive', and it reboots and
runs
it..
Okay, you hold down BOOTSEL when plugging it into the USB. Then it
shows
up on Files as RP2350. If you click on that you see INDEX.HTM and
INFO_UF2.TXT. If you look at Properties it reports 2 items totaling 305 >>>> bytes and 134.1 MB free.
df -Th /dev/sda1
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 vfat 128M 8.0K 128M 1% /media/xxxxx/RP2350 >>>>
Then you can
cp blink.uf2 /media/xxxxx/RP2350/
and, lo and behold, it starts blinking and vanishes from the file
system!
I'm lazy so after it blinks 20 times it calls
reset_usb_boot(0, 0);
and miraculously reappears mounted. How does it do all this without a >>>> file system known to Ubuntu? I won't even ask why after copying the
CircuitPython uf2 it reboots mounted as CIRCUITPYTHON and you can
copy .py
files directly.
My comment had nothing to do with the programmatic use of the flash
memory, only how the Pico presents as a mass storage device.
Well it spoofs the disk obviously
Ya know ..... think I'm gonna stay away from Pico's :-)
light
If I want microcontrollers, there are more traditional
straight-up boards out there. If I want microprocessors
there are the straight-up PIs and beyond.
Did use PICs for a long time ... kinda remember their
quirks and tricks. There are Pico/Nano style boards to
be had cheap that use PICs. Atmel versions also exist.
I looked at those. Many times the price of a pico.
I am slowly making up libraries of Code That Works (as opposed to what
you find plastered around the Web.
On 3/24/25 7:31 AM, The Natural Philosopher wrote:
On 23/03/2025 10:05, c186282 wrote:
On 3/22/25 8:52 PM, The Natural Philosopher wrote:It is a big learning curve. But they are fearfully cheap...small...and
On 22/03/2025 19:09, rbowman wrote:
On Sat, 22 Mar 2025 13:35:54 +0000, The Natural Philosopher wrote:
The PICO has no filesystem. IN use you hold a button down while
powering
up and it's Flash presents itself as a USB drive. You copy a special >>>>>> binary file of compiled code onto that 'drive', and it reboots and >>>>>> runs
it..
Okay, you hold down BOOTSEL when plugging it into the USB. Then it
shows
up on Files as RP2350. If you click on that you see INDEX.HTM and
INFO_UF2.TXT. If you look at Properties it reports 2 items totaling
305
bytes and 134.1 MB free.
df -Th /dev/sda1
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 vfat 128M 8.0K 128M 1% /media/xxxxx/RP2350 >>>>>
Then you can
cp blink.uf2 /media/xxxxx/RP2350/
and, lo and behold, it starts blinking and vanishes from the file
system!
I'm lazy so after it blinks 20 times it calls
reset_usb_boot(0, 0);
and miraculously reappears mounted. How does it do all this without a >>>>> file system known to Ubuntu? I won't even ask why after copying the
CircuitPython uf2 it reboots mounted as CIRCUITPYTHON and you can
copy .py
files directly.
My comment had nothing to do with the programmatic use of the flash
memory, only how the Pico presents as a mass storage device.
Well it spoofs the disk obviously
Ya know ..... think I'm gonna stay away from Pico's :-)
light
If I want microcontrollers, there are more traditional
straight-up boards out there. If I want microprocessors
there are the straight-up PIs and beyond.
Did use PICs for a long time ... kinda remember their
quirks and tricks. There are Pico/Nano style boards to
be had cheap that use PICs. Atmel versions also exist.
I looked at those. Many times the price of a pico.
I am slowly making up libraries of Code That Works (as opposed to what
you find plastered around the Web.
As I was talking about elsewhere, there's the price
of the target CHIPS, and then the price of the
development system/board. The price of the latter
has become rather high in some cases ... can't even
get a good all-purpose PIC programmer anymore that
doesn't require special sockets/libs and such for $$$
MicroChip USED to sell a very useful serial appliance
with a 40-pin ZIF socket. Upgraded it once. You could
stick a large variety of their chips into the thing.
Just specify in their dev app and it'd all work well.
But now .........
If you are an 'experimenter' or small-run person then
the price of the dev/programming crap kinda now makes
it just TOO.
Found people long back who sold an upgraded 8051 (it
was 'fat', had an actual battery in the case to keep
the RAM alive) AND a BASIC-like compiler. The programmer
was a small, kinda bare, PC board - again serial interface.
Not fancy at all - but GOT IT DONE. Made dozens of devices
using that all for almost nothing.
Oh, if a MHz or so is enough, the 8051 is STILL a great chip.
In any case, I *understand* the Pico/Nano approach. It's
"all in one" and no vast other investment required. As
for whether they're good/easy for EVERYTHING, well ....
actually ARDs are still competitive, esp for low-power
applications. Sleep the thing and wait for the next
interrupt ........
On 25/03/2025 05:18, c186282 wrote:
On 3/24/25 7:31 AM, The Natural Philosopher wrote:?. Picos don't need development boards, I mean what are you going to
On 23/03/2025 10:05, c186282 wrote:
On 3/22/25 8:52 PM, The Natural Philosopher wrote:It is a big learning curve. But they are fearfully
On 22/03/2025 19:09, rbowman wrote:
On Sat, 22 Mar 2025 13:35:54 +0000, The Natural Philosopher wrote: >>>>>>
The PICO has no filesystem. IN use you hold a button down while
powering
up and it's Flash presents itself as a USB drive. You copy a special >>>>>>> binary file of compiled code onto that 'drive', and it reboots
and runs
it..
Okay, you hold down BOOTSEL when plugging it into the USB. Then it >>>>>> shows
up on Files as RP2350. If you click on that you see INDEX.HTM and >>>>>> INFO_UF2.TXT. If you look at Properties it reports 2 items
totaling 305
bytes and 134.1 MB free.
df -Th /dev/sda1
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 vfat 128M 8.0K 128M 1% /media/xxxxx/RP2350 >>>>>>
Then you can
cp blink.uf2 /media/xxxxx/RP2350/
and, lo and behold, it starts blinking and vanishes from the file
system!
I'm lazy so after it blinks 20 times it calls
reset_usb_boot(0, 0);
and miraculously reappears mounted. How does it do all this
without a
file system known to Ubuntu? I won't even ask why after copying the >>>>>> CircuitPython uf2 it reboots mounted as CIRCUITPYTHON and you can
copy .py
files directly.
My comment had nothing to do with the programmatic use of the flash >>>>>> memory, only how the Pico presents as a mass storage device.
Well it spoofs the disk obviously
Ya know ..... think I'm gonna stay away from Pico's :-)
cheap...small...and light
If I want microcontrollers, there are more traditional
straight-up boards out there. If I want microprocessors
there are the straight-up PIs and beyond.
Did use PICs for a long time ... kinda remember their
quirks and tricks. There are Pico/Nano style boards to
be had cheap that use PICs. Atmel versions also exist.
I looked at those. Many times the price of a pico.
I am slowly making up libraries of Code That Works (as opposed to
what you find plastered around the Web.
As I was talking about elsewhere, there's the price
of the target CHIPS, and then the price of the
development system/board. The price of the latter
has become rather high in some cases ... can't even
get a good all-purpose PIC programmer anymore that
doesn't require special sockets/libs and such for $$$
hang round them that is so complex? I just go straight to the final PCB.
Works out at maybe $20 for 10 chinese made PCBs...
MicroChip USED to sell a very useful serial appliance
with a 40-pin ZIF socket. Upgraded it once. You could
stick a large variety of their chips into the thing.
Just specify in their dev app and it'd all work well.
But now .........
If you are an 'experimenter' or small-run person then
the price of the dev/programming crap kinda now makes
it just TOO.
?/ What??? The point about a PICO is that it *is* a development board,
if you like, It's all in for $5.
All youi need is s computer running a GCC cross compiler and the free development envir9nmenmt
was 'fat', had an actual battery in the case to keepThat must have been 50 years ago., Things have moved on
the RAM alive) AND a BASIC-like compiler. The programmer
was a small, kinda bare, PC board - again serial interface.
Not fancy at all - but GOT IT DONE. Made dozens of devices
using that all for almost nothing.
Oh, if a MHz or so is enough, the 8051 is STILL a great chip.
In any case, I *understand* the Pico/Nano approach. It'sPICOS essentially the same. Or what I am looking to do is to use an external ultra low power timer to switch the board on after a long
"all in one" and no vast other investment required. As
for whether they're good/easy for EVERYTHING, well ....
actually ARDs are still competitive, esp for low-power
applications. Sleep the thing and wait for the next
interrupt ........
delay, and the board switches itself off when its done its business.
Rinse and repeat
On 3/25/25 7:13 AM, The Natural Philosopher wrote:
On 25/03/2025 05:18, c186282 wrote:
That must have been 50 years ago., Things have moved on
Oh, if a MHz or so is enough, the 8051 is STILL a great chip.
Nah ... a MHz is still good for LOTS of uses !
I know Ards better. More years of libs/examples too.
On 25/03/2025 12:31, c186282 wrote:
On 3/25/25 7:13 AM, The Natural Philosopher wrote:
On 25/03/2025 05:18, c186282 wrote:
Cant program 8051 in C IIRCOh, if a MHz or so is enough, the 8051 is STILL a great chip.That must have been 50 years ago., Things have moved on
Nah ... a MHz is still good for LOTS of uses !
And its bigger than a pi PICO!
On Tue, 25 Mar 2025 14:20:06 +0000, The Natural Philosopher wrote:
On 25/03/2025 12:31, c186282 wrote:
On 3/25/25 7:13 AM, The Natural Philosopher wrote:
On 25/03/2025 05:18, c186282 wrote:
Cant program 8051 in C IIRCOh, if a MHz or so is enough, the 8051 is STILL a great chip.That must have been 50 years ago., Things have moved on
Nah ... a MHz is still good for LOTS of uses !
https://sdcc.sourceforge.net/
afaik there never was a C compiler for the MCS-48 family but the MCS-51 family had a luxurious amount of space (relatively)
And its bigger than a pi PICO!
https://www.keil.com/dd/chips/all/8051.htm
Those aren't your grandfather's 8051s. Your ABS or TPS doesn't need a Cortex-M4.
ANYway, don't diss the '51 ... damned good chip and, for some uses,
STILL. If you can't do ASM and can't find a 'C' compiler there were
some BASIC compilers that'd get the job done nicely.
Oh, if nobody's ever noticed, the Ard UNO has a SOCKETED chip. You
can use the Uno as the programming fixture, put in a new chip,
program it ... stick the chips into your OWN custom boards. Just
enough zap for lots of things (and a good low-power library for like
solar-powered projects).
I read somewhere, long ago, that sticks and memory cards were actually optimized for FAT, by having the pages under the start of the disk significantly smaller. Ie, optimized for having more writes in the FAT
area.
My camera has something in it but it talks via USB to the computer so I
have no idea what format it actually is Ditto my mobile phone
Don't love UEFI at all
You should! It's neat.
No, the only thing that made it unstable was Windows. I don't know how
it is now, but for years, every Windows update removed anything that
wasn't its own boot system.
uefi is a mini operating system developed primarily for the purpose of
making it harder for other operating systems to be used, and to boost pc sales. The attack surface it exposes allows undetectable root kits to
be installed, or machines to be easily bricked just by deleting the
efivars from the nvram.
uefi is marketed as improving security. While it may block amateur
attackers, it is a security nightmare.
People going down this road of argument usually are what we in German
call "Betriebsblind", being accustomed to the quirks of the old way
that they don't see the compelling simplicity of the new way.
... after which the kernel can set up the partition it
wants to use as / and chroot to that.
... pulling the SD card out of the camera is not
something I care to do ...
...and I don't have a reader for that format card
On Wed, 26 Mar 2025 04:22:58 -0400, c186282 wrote:
ANYway, don't diss the '51 ... damned good chip and, for some uses,
STILL. If you can't do ASM and can't find a 'C' compiler there were
some BASIC compilers that'd get the job done nicely.
I would have loved to have had a 51 for one project but in the early '80s lead times for many parts were over a year and the MCS-48, specifically
the 8749 parts, were available.
Oh, if nobody's ever noticed, the Ard UNO has a SOCKETED chip. You
can use the Uno as the programming fixture, put in a new chip,
program it ... stick the chips into your OWN custom boards. Just
enough zap for lots of things (and a good low-power library for like
solar-powered projects).
Usually. Speaking of parts shortages...
https://store.arduino.cc/products/arduino-uno-rev3-smd
On Sat, 22 Mar 2025 11:21:23 +0100, Marc Haber wrote:
Don't love UEFI at all
You should! It's neat.
The idea may seem good, the execution seems to leave something to be
desired. It’s supposed to be OS-independent, but in practice the vendors only test that it boots Windows OK before shipping. So it’s left to the developers of the other OSes (mainly Linux, of course) to add hacks to
work around all the bugs and gaps in their implementations of the spec.
Cant program 8051 in C IIRC
On Sun, 23 Mar 2025 11:58:32 -0400, David W. Hodgins wrote:
uefi is a mini operating system developed primarily for the purpose of
making it harder for other operating systems to be used, and to boost pc
sales. The attack surface it exposes allows undetectable root kits to
be installed, or machines to be easily bricked just by deleting the
efivars from the nvram.
Harsh ... but fair ...
UEFI, imho, was originally promoted by M$ to SCREW
the Linux/Unix world.
Never saw a shortage of UNO chips ......
On Thu, 27 Mar 2025 03:51:30 -0400, c186282 wrote:
Never saw a shortage of UNO chips ......
https://www.seeedstudio.com/blog/2022/05/24/three-alternatives-to- atmega-328p-au-microcontroller-to-bypass-the-chip-crisis/
https://www.youtube.com/watch?v=DA6pHT-2fXs
Those talk about the AU but I believe the PU was also tight. Remember
covid? Climate problems in Texas? The CF in Ukraine disrupting the neon supply?
Reading between the lines there is also validation of the wisdom of not
using a chip in your design that is used in the automotive industry.
They'll suck the well dry.
The Natural Philosopher <tnp@invalid.invalid> writes:
Cant program 8051 in C IIRC
Both Keil and IAR have sold C compilers for it. I don't know if those
are still available.
I do sometimes wonder what people use to develop for their 8051s
today. For example, I bought a little solder-it-yourself desktop clock
kit available for peanuts and it has some Chinese 8051 variant on it.
On 23 Mar 2025 07:49:11 +1000, Computer Nerd Kev wrote:
... after which the kernel can set up the partition it
wants to use as / and chroot to that.
pivot_root(2), not chroot(2).
rbowman <bowman@montana.com> writes:
On Thu, 27 Mar 2025 03:51:30 -0400, c186282 wrote:
Never saw a shortage of UNO chips ......
https://www.seeedstudio.com/blog/2022/05/24/three-alternatives-to-
atmega-328p-au-microcontroller-to-bypass-the-chip-crisis/
https://www.youtube.com/watch?v=DA6pHT-2fXs
Those talk about the AU but I believe the PU was also tight. Remember
covid? Climate problems in Texas? The CF in Ukraine disrupting the
neon supply?
Reading between the lines there is also validation of the wisdom of not
using a chip in your design that is used in the automotive industry.
They'll suck the well dry.
Doesn’t help, vendors will pull production capacity from the chips you
want if they can make more money elsewhere (e.g. automotive).
On Thu, 27 Mar 2025 03:51:30 -0400, c186282 wrote:
Never saw a shortage of UNO chips ......
https://www.seeedstudio.com/blog/2022/05/24/three-alternatives-to- atmega-328p-au-microcontroller-to-bypass-the-chip-crisis/
https://www.youtube.com/watch?v=DA6pHT-2fXs
Those talk about the AU but I believe the PU was also tight. Remember
covid? Climate problems in Texas? The CF in Ukraine disrupting the neon supply?
Reading between the lines there is also validation of the wisdom of not
using a chip in your design that is used in the automotive industry.
They'll suck the well dry.
On Sat, 22 Mar 2025 14:17:25 +0100, Carlos E.R. wrote:
I read somewhere, long ago, that sticks and memory cards were actually
optimized for FAT, by having the pages under the start of the disk
significantly smaller. Ie, optimized for having more writes in the FAT
area.
Not sure how that’s supposed to benefit the wear-levelling algorithm. The whole point of wear-levelling is that successive writes to the same
logical sector do not necessarily end up in the same physical location.
Well, I recently bought a 5-pack of those chips from Amazon for about
$1.25 each ... so I don't see any 'shortage'.
sticks and cards do not have wear levelling.
On Fri, 28 Mar 2025 14:49:02 +0100, Carlos E.R. wrote:
sticks and cards do not have wear levelling.
Then they would benefit from using a filesystem format that integrates wear-levelling in its storage-allocation algorithms, like the
aforementioned F2FS or NilFS2.
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial.
one of your best choices.
On 3/28/25 7:18 PM, The Natural Philosopher wrote:
On 28/03/2025 13:49, Carlos E.R. wrote:
sticks and cards do not have wear levelling.R U sure about that?
. . .
According to the (de-facto ad) from here :
https://www.delkin.com/blog/wear-leveling-usb-flash-drive-basics/
Most thumb drives do not use leveling, instead it's mostly in
SSDs and such. However 'industrial' thumb drives - at least
this corps - DO employ on-chip-controlled leveling algos.
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial. Getting Cmake to
one of your best choices.
do what's wanted is non trivial...
Ok if micropython gives you a hardon, there is that...
On Sat, 29 Mar 2025 13:44:58 +0000, The Natural Philosopher wrote:
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial. Getting Cmake to
one of your best choices.
do what's wanted is non trivial...
"Getting started with Raspberry Pi Pico-series"
https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
If you can't follow that you probably shouldn't be messing with a Pico without adult supervision.
1. Install VS Code
2. Install the Raspberry Pi Pico VS Code Extension
3. Compile and run 'blink'
"The extension will now download the SDK and the toolchain, install them locally, and generate the new project. The first project may take 5-10 minutes to install the toolchain. VS Code will ask you whether you trust
the authors because we’ve automatically generated the .vscode directory
for you. Select yes."
On some Linux distros you may have to install python, git, tar, and build- essentials.
On 29/03/2025 17:20, rbowman wrote:
On Sat, 29 Mar 2025 13:44:58 +0000, The Natural Philosopher wrote:You may follow it., bit it doesn't always work...
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial. Getting Cmake to
one of your best choices.
do what's wanted is non trivial...
"Getting started with Raspberry Pi Pico-series"
https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
If you can't follow that you probably shouldn't be messing with a Pico
without adult supervision.
1. Install VS Code 2. Install the Raspberry Pi Pico VS Code ExtensionAnd cmake ...
3. Compile and run 'blink'
"The extension will now download the SDK and the toolchain, install
them locally, and generate the new project. The first project may take
5-10 minutes to install the toolchain. VS Code will ask you whether you
trust the authors because we’ve automatically generated the .vscode
directory for you. Select yes."
On some Linux distros you may have to install python, git, tar, and
build-
essentials.
Have you actually done this yourself?
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial.
one of your best choices.
Getting Cmake to do what's wanted is non trivial...
Ok if micropython gives you a hardon, there is that...
On 29/03/2025 00:00, c186282 wrote:
On 3/28/25 7:18 PM, The Natural Philosopher wrote:blah blah 'not all usb sticks use wear levelling BUT OURS DOES' is
On 28/03/2025 13:49, Carlos E.R. wrote:
sticks and cards do not have wear levelling.R U sure about that?
. . .
According to the (de-facto ad) from here :
https://www.delkin.com/blog/wear-leveling-usb-flash-drive-basics/
Most thumb drives do not use leveling, instead it's mostly in
SSDs and such. However 'industrial' thumb drives - at least
this corps - DO employ on-chip-controlled leveling algos.
hardly authoritative..:-)
On Sat, 29 Mar 2025 19:59:34 +0000, The Natural Philosopher wrote:
On 29/03/2025 17:20, rbowman wrote:
On Sat, 29 Mar 2025 13:44:58 +0000, The Natural Philosopher wrote:You may follow it., bit it doesn't always work...
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial. Getting Cmake to >>>> do what's wanted is non trivial...
one of your best choices.
"Getting started with Raspberry Pi Pico-series"
https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
If you can't follow that you probably shouldn't be messing with a Pico
without adult supervision.
I'm certain people can figure out how to fuck it up.
1. Install VS Code 2. Install the Raspberry Pi Pico VS Code ExtensionAnd cmake ...
3. Compile and run 'blink'
"The extension will now download the SDK and the toolchain, install
them locally, and generate the new project. The first project may take
5-10 minutes to install the toolchain. VS Code will ask you whether you
trust the authors because we’ve automatically generated the .vscode
directory for you. Select yes."
On some Linux distros you may have to install python, git, tar, and
build-
essentials.
To repeat:
"The first project may take >> 5-10 minutes to install the toolchain."
The toolchain includes cmake.
On 3/29/25 9:44 AM, The Natural Philosopher wrote:
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial.
one of your best choices.
So what's new in ComputerLand ? :-)
Getting Cmake to do what's wanted is non trivial...
Same.
Ok if micropython gives you a hardon, there is that...
Not what I like ... full python is OK though.
In any case, there's a 'C' dev kit for Pico. If
I get into Pico's that'll be the choice.
Examples :
https://www.electronicshub.org/program-raspberry-pi-pico-using-c/
Not what I like ... full python is OK though.
In any case, there's a 'C' dev kit for Pico. If I get into Pico's
that'll be the choice.
Examples :
https://www.electronicshub.org/program-raspberry-pi-pico-using-c/
On 30/03/2025 07:59, c186282 wrote:
On 3/29/25 9:44 AM, The Natural Philosopher wrote:It works, but its a fairly steep learning curve
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial.
one of your best choices.
So what's new in ComputerLand ? :-)
Getting Cmake to do what's wanted is non trivial...
Same.
Ok if micropython gives you a hardon, there is that...
Not what I like ... full python is OK though.
In any case, there's a 'C' dev kit for Pico. If I get into Pico's
that'll be the choice.
Did search Amazon - "industrial flash drive". The
results were unclear, it mostly just brought up
the usual spectrum of thumb drives with no mention
of wear-leveling/toughening. Mostly see "industrial"
related to the old 'wide' flash cards.
Those are still used, mostly in pro cameras. Have
one or two and a USB adapter.
I know 'industrial' versions of various flash DO exist,
had to buy some once for a vendors devices. They tend
to cost twice as much, but have better specs (except,
often, speed).
If you’re thinking of things like F2FS then I doubt it: it is explicitly designed for block devices with a working FTL.
On Sat, 29 Mar 2025 09:13:06 +0000, Richard Kettlewell wrote:
If you’re thinking of things like F2FS then I doubt it: it is explicitly >> designed for block devices with a working FTL.
The article did say that SD cards have that. And presumably USB sticks,
too.
On 30/03/2025 07:59, c186282 wrote:
On 3/29/25 9:44 AM, The Natural Philosopher wrote:It works, but its a fairly steep learning curve
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial.
one of your best choices.
So what's new in ComputerLand ? :-)
Getting Cmake to do what's wanted is non trivial...
Same.
Ok if micropython gives you a hardon, there is that...
Not what I like ... full python is OK though.
In any case, there's a 'C' dev kit for Pico. If
I get into Pico's that'll be the choice.
Examples :
https://www.electronicshub.org/program-raspberry-pi-pico-using-c/
On Sun, 30 Mar 2025 02:59:17 -0400, c186282 wrote:
Not what I like ... full python is OK though.
In any case, there's a 'C' dev kit for Pico. If I get into Pico's
that'll be the choice.
Examples :
https://www.electronicshub.org/program-raspberry-pi-pico-using-c/
I have a couple of versions of the Raspberry Pi Pico SDK documentation.
The older one follows the website steps. The newer one starts with
installing VS Code and the Raspberry Pi Pico extension. The extension
handles most of the heavy lifting, both in downloading the latest version
of the tool chain and in building the project.
The revision history shows "Added documentation on the official Raspberry
Pi Pico VS Code extension." for the 03 May 2024 revision. Pico 2 support
was added 8 August 2024. Subsequent releases are mostly fixing typos like 'VSCode' for 'VS Code'.
MicroPython, Circuitpython, and the Arduino core are not static either. Staying current is helpful.
On Sun, 30 Mar 2025 18:11:16 +0100, The Natural Philosopher wrote:
On 30/03/2025 07:59, c186282 wrote:
On 3/29/25 9:44 AM, The Natural Philosopher wrote:It works, but its a fairly steep learning curve
On 29/03/2025 04:18, c186282 wrote:
For today's uses, esp for newbies, the Pico is likelyGetting the SDK installed and working is non trivial.
one of your best choices.
So what's new in ComputerLand ? :-)
Getting Cmake to do what's wanted is non trivial...
Same.
Ok if micropython gives you a hardon, there is that...
Not what I like ... full python is OK though.
In any case, there's a 'C' dev kit for Pico. If I get into Pico's
that'll be the choice.
Almost everything I've dealt with in the last 50 years has involved a
steep learning curve. Those that can't keep up either become middle
managers or baristas.
When I was a IEEE member most of the people in local chapter were
classical electrical engineers working for Public Service of New
Hampshire. Nice guys and they kept the lights on but they weren't on the cutting edge of anything. I would have been bored shitless.
c186282 <c186282@nnada.net> wrote:
...
Did search Amazon - "industrial flash drive". The
results were unclear, it mostly just brought up
the usual spectrum of thumb drives with no mention
of wear-leveling/toughening. Mostly see "industrial"
related to the old 'wide' flash cards.
Those are still used, mostly in pro cameras. Have
one or two and a USB adapter.
I know 'industrial' versions of various flash DO exist,
had to buy some once for a vendors devices. They tend
to cost twice as much, but have better specs (except,
often, speed).
Do you know which brand and models those were so we can buy them too?
SO ... when to use F2SB and such ? NOT so clear.
If the device has hardware wear-leveling then you
are slowing it down, maybe working contrary.
On 3/30/25 2:26 PM, rbowman wrote:
When I was a IEEE member most of the people in local chapter were
classical electrical engineers working for Public Service of New
Hampshire. Nice guys and they kept the lights on but they weren't on the
cutting edge of anything. I would have been bored shitless.
Well ..... 'classical' here means "Don't Go Nuts For
the 'New Stuff'. What works, works.
So don't EXPECT them to be "exciting" - the JOB is to
do What Works Fer Sure. They WILL stay five+ years
behind the proverbial curve for good reasons.
Le 22-03-2025, Computer Nerd Kev <not@telling.you.invalid> a écrit :
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
rbowman <bowman@montana.com> wrote:
On Sat, 22 Mar 2025 15:26:55 +0100, Carlos E.R. wrote:
At home, many people boot multiple operating systems from the same disk; >>>>> UEFI has made this easier.
Dual boot worked find for years before UEFI. When MS went to secure boot >>>>in Windows 8 it became a major PITA to dual boot before the Linux distros >>>>caught up.
Dual Boot has always an unstable, fragile PITA.
The only thing that made it unstable for me was when distros
switched to Grub 2. So I started throwing that away in favour of
SysLinux/ExtLinux and things have been easy again.
No, the only thing that made it unstable was Windows. I don't know how
it is now, but for years, every Windows update removed anything that
wasn't its own boot system.
"Why risk your computer becoming unusable when we force you to
update ...
Windows doing that always seemed like a "plausibly deniable" way to discourage it, along with WSL. "Why risk your computer becoming unusable
when we force you to update, when you can use our built in Linux?"
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 02:34:32 |
| Calls: | 9,707 |
| Calls today: | 2 |
| Files: | 13,740 |
| Messages: | 6,180,824 |