2023-08-04 03:01:15 <KipIngram   > xelxebar: Mecrisp across is a really well conceived offering.
2023-08-04 03:01:38 <KipIngram   > Gives you the "feel" of an interactive Forth on a target that couldn't possibly support one.
2023-08-04 03:02:00 <KipIngram   > And for embedded design work, that interactivity is one of Forth's strongest attributes.
2023-08-04 03:07:01 <KipIngram   > So, on the 32655 I think I want to next just play some with this hello world project.  Meander around the chip a little bit and tinker with some things.  But then I want to poke some machine code bytes into an array and rig up a way to execute them, starting with just a return instruction.  Then play some more with the chip resources, using that method.
2023-08-04 03:08:44 <KipIngram   > Do that until I think I've got code together that will bring up the UART from scratch.  My first "real" goal is still a binary that brings up the serial port as an "echo box."
2023-08-04 03:15:15 <KipIngram   > Then start systematically growing that echo box into a Forth.
2023-08-04 03:17:28 <KipIngram   > xelxebar: Others here have commented very favorably on the extent to which mecrisp across optimizes the code it burns onto the target.
2023-08-04 03:18:36 <KipIngram   > My understanding is that when you're working interactively it doesn't actually program the part - it holds it in a reset state and uses jtag to manipulate its output pins, read its input pins, and so on.  Using some kind of emulation it runs on the host.
2023-08-04 03:18:57 <KipIngram   > You do that until you're happy with your work, and THEN you burn the part.
2023-08-04 03:19:20 <KipIngram   > That also has the advantage of not using up your program/erase cycles with a lot of development iteration.
2023-08-04 03:56:30 <xelxebar    > Ooooo. That's really nice. My understanding is that the dev loop on small micros like this involves lots of iterative burning, so having an repl accesible to play sounds kind of revolutionary.
2023-08-04 04:08:56 <gordonjcp   > xelxebar: bear in mind that on modern parts, "burning" the code onto it is basically just copying a file across over USB
2023-08-04 05:09:10 <KipIngram   > Yeah, mecrisp across struck me as kind of revolutionary too.  It just smacked of "the right idea."
2023-08-04 05:10:24 <KipIngram   > gordonjcp: Yes, but the point isn't the labor involved.  All flash storage has a limited number of program/erase cycles.  Programming and erasing the part subjects it to wear, and it will eventually wear out.  In some cases the number is quite large, but it can also be small.  So anything that "conserves p/e cycles" is a good thing.
2023-08-04 05:11:17 <KipIngram   > In the case of these tiny micros, there's no particularly huge incentive to try to make the p/e count large - the vast majority of those parts will be programmed once as they're built into some piece of equipment and then never again.
2023-08-04 05:11:47 <KipIngram   > On the other hand, a flash memory chip for data storage would probably have a higher p/e count, just because of how it's intended to be used.
2023-08-04 05:12:17 <KipIngram   > This is on a per-block basis; it's not a global thing for the whole chip.  The block you erase/program is the one that gets the wear.
2023-08-04 05:12:47 <xelxebar    > Also, `2+2 .` is way easier than 1. edit source, 2. build, 3. copy file to folder.
2023-08-04 05:12:49 <KipIngram   > We monitor for rising bit error rates in our flash blocks, and when a block starts to show sufficiently frequent errors we retire it.
2023-08-04 05:13:02 <xelxebar    > s/2+2/2 + 2/
2023-08-04 05:13:39 <xelxebar    > Lowering the psychological barrier for making small, exploratory changes is huge.
2023-08-04 05:13:59 <KipIngram   > Yes it is.
2023-08-04 05:14:18 <KipIngram   > We offer a certain amount of space to the user in each of our drives, but we hold some back for our own housekeeping use.
2023-08-04 05:14:29 <KipIngram   > As we retire blocks, we take that out of our scratch space.
2023-08-04 05:14:52 <KipIngram   > The result of that is a gradual degradation of write performance as the scratch space shrinks.
2023-08-04 05:15:17 <KipIngram   > The scratch space is used as part of the garbage collection process.
2023-08-04 05:15:38 <KipIngram   > Our word for that scratch space is "overprovisioning."
2023-08-04 05:16:14 <KipIngram   > Prior to the customer filling up their space, we use all of their unused space as scratch as well, so when a customer first gets a drive it will really sizzle.
2023-08-04 05:16:23 <KipIngram   > But it will slow down as they fill it up.
2023-08-04 05:16:58 <KipIngram   > I always worry that our sales people likely don't educate customers very well about that - I figure it probably sometimes gets noticed and irritates those customers.
2023-08-04 05:24:10 <KipIngram   > It's just kind of hard for me to imagine a sales critter saying to a customer "In the future your drive won't be as fast."
2023-08-04 05:25:34 <KipIngram   > Truth is most of the sales people probably don't even know this themselves - I feel like I'm constantly explaining it to people.
2023-08-04 05:26:14 <KipIngram   > The root cause of the whole business is the fact that in all NAND flash chips the "unit of erasure" is much larger than the "unit of writing."
2023-08-04 05:26:41 <KipIngram   > Erasing takes a long time - so they ammortize that by erasing a whole bunch of pages in one shot.
2023-08-04 05:27:08 <KipIngram   > But you can't arbitrarily select those page - they come in pre-defined groups.
2023-08-04 05:29:05 <KipIngram   > xelxebar: I think I'm with you.  It's nice that mecrisp across is kind to the chip on the p/e front, but the REAL beauty of it is in the streamlined user experience.
2023-08-04 05:29:19 <KipIngram   > As you said - anything that makes for good psychology in such work is a real boon.
2023-08-04 05:29:46 <KipIngram   > A smooth workflow is a wonderful thing, especially when an iterative process is involved.
2023-08-04 05:45:11 <KipIngram   > It's my understanding that some development systems preserve p/e/ cycles by not programming the flash when you download a "debug" image - instead it puts it directly into RAM and executes it there.  If that's feasible on the chip involved.  Then when you send over a "release" image, that goes into flash.
2023-08-04 05:59:22 <gordonjcp   > KipIngram: that's not really true
2023-08-04 05:59:50 <gordonjcp   > KipIngram: you will never wear out the flash in a microcontroller, at least not one built in the past 20 years
2023-08-04 06:00:06 <gordonjcp   > they have millions of erase/write cycles
2023-08-04 06:21:40 <veltas      > Bought "the book" on Kaizen because people are banging on about it at work and the original was under a fiver
2023-08-04 06:21:54 <veltas      > Ready to learn nothing
2023-08-04 06:22:57 <veltas      > Really doesn't impact software, things like 'agile' make more sense. But I suppose it's only fair we adapt to hardware processes after they've been forced to pretend to do agile for years
2023-08-04 06:30:33 <MrMobius    > gordonjcp: how do you mean? Sometimes data sheets say 10,000 or even 1,000 writes
2023-08-04 06:30:45 <gordonjcp   > MrMobius: for ancient parts
2023-08-04 06:31:15 <gordonjcp   > veltas: "poka yoke" is more important tbh
2023-08-04 06:31:22 <gordonjcp   > veltas: awesome example on my car
2023-08-04 06:32:03 <gordonjcp   > the fusebox is connected to the battery by one thick lead that goes onto an M8 stud, three leads going onto M6 studs, and six multipin connectors
2023-08-04 06:32:29 <gordonjcp   > the six multipin connectors are the same size with the same number of pins, but they're colour-coded with the corresponding colours stamped onto the bottom of the fusebox
2023-08-04 06:32:57 <gordonjcp   > then, each multipin connector has a T or U shaped pin in the centre in one of three orientations, so they physically cannot fit the wrong socket
2023-08-04 06:33:02 <MrMobius    > Looks like atmega328 is 10,000. Is that ancient?
2023-08-04 06:33:35 <gordonjcp   > then, the fusebox can only go on its bracket one way, and the wiring harness to the plugs is designed so that the plugs clearly line up with the correct sockets
2023-08-04 06:33:39 <gordonjcp   > MrMobius: jurassic
2023-08-04 06:34:07 <MrMobius    > lol
2023-08-04 06:34:21 <MrMobius    > that's a bit of a high bar then
2023-08-04 06:34:59 <gordonjcp   > they found the original masks for the first atmega328s in the Callovian mudstones on Staffin Beach, along with a bunch of ammonites bitching about Atmel Studio
2023-08-04 06:37:00 <MrMobius    > 10K for some stm32 parts too
2023-08-04 06:37:48 <MrMobius    > gordonjcp: so "built in the last 20 years" really means first built not currently built?
2023-08-04 06:47:54 <Zarutian_iPad> dont recall but FRAM does not have this same issue as flash, yes?
2023-08-04 07:13:14 <Zarutian_iPad> I am thinking about using https://www.infineon.com/dgdl/Infineon-FM18W08_256-Kbit_(32_K_8)_Wide_Voltage_Bytewide_F-RAM_Memory-DataSheet-v06_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ec89b424117&utm_source=cypress&utm_medium=referral&utm_campaign=202110_globe_en_all_integration-files instead of the eeprom flash in Ben Eaters 6502 breadboard computer
2023-08-04 07:13:58 <Zarutian_iPad> but that requires me to bind a 28 pin soic to dip adapter board
2023-08-04 07:14:13 <Zarutian_iPad> I think adafruit has such
2023-08-04 07:29:27 <crc         > adafruit has FRAM modules with spi interface (https://www.adafruit.com/product/4719) or i2c (https://www.adafruit.com/product/1895)
2023-08-04 08:17:08 <KipIngram   > Sure, some of them have millions.  They vary.
2023-08-04 08:18:28 <KipIngram   > Yeah, I don't know the current numbers.  But I do remember 10k ones from the past.
2023-08-04 08:24:49 <gordonjcp   > MrMobius: designed, really
2023-08-04 08:40:22 <KipIngram   > It's also worth noting that often parts that had flash for programs and also EEPROM for small non-volatile data storage would have different p/e counts for those; the eeprom usually had more.
2023-08-04 08:49:55 <veltas      > FRAM lasts for a hundred years+, but has a destructive read, so each read can corrupt the data
2023-08-04 08:50:16 <veltas      > But you can work around that
2023-08-04 08:50:32 <veltas      > But there are FRAM chips where if the interface is used slightly out of spec it will wipe random bits
2023-08-04 08:50:37 <KipIngram   > Errors can accrue in NAND flash with it just sitting there.
2023-08-04 08:50:47 <veltas      > Yeah especially on a hot day
2023-08-04 08:50:54 <veltas      > This is what checksums are for
2023-08-04 08:51:05 <veltas      > You need to know the options and the associated workarounds
2023-08-04 08:51:15 <veltas      > Depending on your criteria FRAM could be perfect or useless
2023-08-04 08:51:18 <MrMobius    > they are rated to 10^13 or 10^14 cycles usually. If you do the math, you can hit that in a few years if you're reading the same addresses 24/7 like a hot loop waiting for something to happen
2023-08-04 08:51:22 <KipIngram   > We use error detection and correction on ours, and we also run a housekeeping process that sifts through all of it and checks error counts.  When a page gets above a certain error threshold we re-write it somewhere new to reset the error count.
2023-08-04 08:51:39 <KipIngram   > Because our algorithm can only correct a certain number of errors.
2023-08-04 08:51:53 <MrMobius    > TI used to market their fram parts as lasting practically forever or something like that then quietly changed their claim at some point
2023-08-04 08:52:11 <veltas      > MrMobius: Yeah wear is not the issue, you can corrupt on day 1 depending on the chip if the interface is used slightly wrong even while *reading*
2023-08-04 08:52:34 <MrMobius    > veltas: fair enough but in that case wear is still an issue
2023-08-04 08:52:35 <veltas      > And some FRAM chips are very susceptible to magnetic fields, although none of the ones I've used are
2023-08-04 08:53:01 <veltas      > I've just heard of this being a thing, probably not the case with most FRAM parts now
2023-08-04 08:54:23 <KipIngram   > We use FRAM in our drives too, but I'm not sure exactly what we do with it.  And also something called MRAM, which has been an annoyance.
2023-08-04 08:54:48 <veltas      > Do you detect physical stress?
2023-08-04 08:55:13 <veltas      > That's a common thing now to have devices that detect drops and shock, so you can point the finger at someone else if it's dropped and gets returned
2023-08-04 08:55:37 <KipIngram   > I don't think we have that.  At least I've not heard of it.
2023-08-04 08:55:52 <veltas      > Yeah probably not much point for enterprise SSd's
2023-08-04 08:55:58 <KipIngram   > We sell these things installed in rack mount units.  We don't sell bare drives.
2023-08-04 09:09:32 <KipIngram   > I've been pretty impressed with our EDC.  We use code pages around 8kB, and can correct over a hundred bit errors in a page.
2023-08-04 09:24:21 <veltas      > Nice
2023-08-04 10:02:17 <KipIngram   > What's really cool is that all those fancy math algorithms are implemented in FPGA, not software.
2023-08-04 10:34:53 <veltas      > That's the right way to do it, but I do regret the separation between software and FPGA-ware
2023-08-04 10:35:22 <veltas      > Specifically for me it's annoying when there's something wrong with FPGA code and it isn't easy to work around in software, and really it would be easier if it was all just software
2023-08-04 10:35:39 <veltas      > But it's better to use FPGA, I wish I understood it better and had all the tools etc
2023-08-04 10:35:45 <KipIngram   > The guy that owned Texas Memory Systems before IBM bought us was absolutely fanatic about "no software in the good data path."
2023-08-04 10:35:49 <veltas      > I think our software people should be more aware of it
2023-08-04 10:35:53 <KipIngram   > Only for error handling.
2023-08-04 10:36:21 <veltas      > I think I understand why he said that
2023-08-04 10:36:34 <KipIngram   > IBM hasn't kept it totally that pure, but it's close.
2023-08-04 10:36:38 <veltas      > Only software engineers build a house starting with the roof
2023-08-04 10:37:16 <veltas      > When we're done we're happy even if we forgot walls, and the house can collapse if more than 5 people enter at once
2023-08-04 10:37:27 <KipIngram   > I'm fine with that, as long as you don't find yourself boxed into less than optimal solutions by the time you get to the foundation.
2023-08-04 10:37:39 <thrig       > and customers pay large sums of money and keep doing so for such houseware
2023-08-04 10:38:21 <veltas      > To know in advance i.e. do design work, which is pretty much required for the best-in-class solutions
2023-08-04 10:38:29 <veltas      > And you might even see it for an SSD
2023-08-04 10:38:34 <veltas      > But not for most software projects
2023-08-04 10:38:38 <KipIngram   > ^ yes
2023-08-04 10:38:44 <thrig       > e.g. $70 billion in profits and Azure is apparently a security dumpster fire
2023-08-04 10:39:20 <veltas      > Azure is apparently a colour
2023-08-04 10:39:21 <Zarutian_iPad> thrig: What do you expect? It is a MicroSoft product/servicd
2023-08-04 10:39:48 <Zarutian_iPad> no security Azure-ances, eh?