01:00:41
##forth
<tpnix>
+1
01:03:28
##forth
<tpnix>
for instance on small Cortex-M0+ STM32 mcu's such as the STM32G030 which has 64KB flash, a RTOS won't fit, so it's not used. C is used, assembly is used, plus Forth or Basic to a vastly lesser degree
01:05:04
##forth
<tpnix>
Mecrisp-Stellaris is designed for such targets as it only uses 20KB for the image, leaving a healthy 44KB for the Dictionary
06:49:16
##forth
<M-Sci>
AFAICS lisbeths is a carbon-based LLM.
09:20:29
##forth
<veltas>
RTOS's in embedded often are brought in to cover up other fundamental issues and don't solve an awful lot on their own
09:20:59
##forth
<veltas>
FreeRTOS can get pretty tinsy, way under 64KB of flash I think?
09:22:00
##forth
<veltas>
I just see it as a library for scheduling, that's all it really is, but frankly most embedded problems are best served with a simple loop, interrupts, maybe some queues if you want better throughput; don't need an RTOS
09:22:18
##forth
<veltas>
I'd use an RTOS if I was writing some kind of larger safety critical thing
09:31:42
##forth
<tpnix>
Ive never used a RTOS myself as the mcu's I use are far too small to run one, I have used a simple scheduler in a recent Forth powered device and that seems reliable
09:32:08
##forth
<tpnix>
lol, even a simple scheduler takes up a lot of flash
09:33:18
##forth
<tpnix>
in that case I used the multitasker Word with Mecrisp-Stellaris and it worked pretty well, I feel I nailed the main requirements with that one
10:15:51
##forth
<veltas>
Supposedly you can run FreeRTOS with 32K flash
10:16:12
##forth
<veltas>
I'm assuming that's disabling a lot of stuff, and with very small application code
10:16:26
##forth
<veltas>
And optimised code output
10:21:55
##forth
<tpnix>
veltas, a friend tried it on 32kb flash and said there was nothing left for the application
10:23:18
##forth
<tpnix>
freertos looks to be very complex to me, but Ive never run it
10:23:44
##forth
<veltas>
I don't doubt the forum post I saw claiming they had, I also don't doubt it would require a lot of tweaking and be pointless yes
10:23:59
##forth
<veltas>
And no or little room for app
10:24:34
##forth
<veltas>
FreeRTOS is actually quite well designed and lightweight, and not too complicated, but it's just not necessary at all for most embedded apps
10:24:41
##forth
<veltas>
People just throw it in because they want to play with it
10:24:51
##forth
<tpnix>
I mean I wouldnt even bother with Mecrisp-Stellaris on 32kb, while only 20kb is needed, I feel there arent enough resources left
10:24:58
##forth
<veltas>
And in embedded everything you don't need is bloat
10:25:29
##forth
<tpnix>
true
10:27:09
##forth
<tpnix>
I dont get why some people feel compelled to try big systems on small devices ? I mean RTOS is fine on a suitably larger system, be fun and reliable to use etc
10:27:59
##forth
<tpnix>
Id use it on a STM32H750 as it has 2MB flash etc, 400Mhz clock, would be impressive if one likes C and RTOS
10:28:38
##forth
<tpnix>
myself, I love the simplicity of Mecrisp-Stellaris Forth on cortec-m0 with 64kb flash
10:29:18
##forth
<tpnix>
but I only do simple devices, thats where my interest lays
10:39:49
##forth
<veltas>
I don't understand it at all, I came into embedded because I was interested in how things work, last thing I want to do is throw an OS abstraction on top of stuff
10:40:22
##forth
<veltas>
I wanted to know how software actually *did* stuff, not 'how to use an OS' which I'd already done enough of
10:42:32
##forth
<veltas>
I think a lot of people think an OS is really fundamental to computers, but the reality is that lots of computers operate without an OS just fine (albeit more practical if you don't need loads of drivers and a network stack)
10:43:18
##forth
<veltas>
If you're working on an MCU then often there's very little bare metal code required to do most projects, especially just involving GPIO or simpler peripherals
10:45:34
##forth
<veltas>
One of my favourite things I did at work was rewriting bare metal boot firmware in PPC assembly for a system-on-chip, although certain init things were quite thankless like initialising DDR
10:53:28
##forth
<tpnix>
we think somewhat alike then
10:54:15
##forth
<tpnix>
the first commercial device I ever made was a hospital liquids (normal saline) bottle filling machine controller, back in 1984
10:55:10
##forth
<tpnix>
it used a Intel 8085 cpu, and I programmed everything in machine code, with only a hex keypad and 7 seg led displays
10:55:31
##forth
<tpnix>
no os, no nothing, just machine code
10:57:23
##forth
<tpnix>
I learned embedded design building a prototype radioative sensor iron ore flow guage with a National PACE 16 bit cpu in 1976
10:57:47
##forth
<tpnix>
that used the National Semi assembler, teletype and paper tape etc
10:58:27
##forth
<tpnix>
but I was only the tech building it under the design of the lead engineer, I had no clue how much of it worked
10:59:32
##forth
<tpnix>
I built all of it by hand, boards I hand made, pressed in solder turret pins etc, all the other S100 boards were wire wrapped
11:00:35
##forth
<tpnix>
and finally I installed it at the top of a huge iron ore crusher building in Port Hedland in 1977
11:01:52
##forth
<tpnix>
it worked bu using two radioactive sources to measure the thickness of a falling curtain of iron ore and compute the flow in tons per minute
11:02:59
##forth
<tpnix>
it was I guess a legondary introduction to embedded. I was about 20 years old at the timer
11:37:57
##forth
<veltas>
All the older embedded engineers I know have stories like this, it's fascinating
11:46:00
##forth
<tpnix>
they were fascinating days for me
11:47:43
##forth
<tpnix>
Ive been lucky to have such experience being australian
13:16:39
##forth
<KipIngram>
Oh, I think the latter part of the twentieth century was the most fascinating time to be in the profession. I have my own share of stories and interesting products I've had the privilege of working on over the years.
13:17:01
##forth
<KipIngram>
It feels to me like it's all become rather "sterile" by comparison these days.
13:17:30
##forth
<KipIngram>
Maybe it's just that the steep parts of learning curves are always the most fun.
13:19:07
##forth
<KipIngram>
Take those first years of the microprocessor era. I missed those - I was a little too young. But those had to be heady days.