<tp>
tabemann, you wouldnt belIeve how hard it is to get CTS working under C in a stm32f103
<tp>
if I was cool on C before, I hate it now
<tabemann>
C abstracts the hardware away more than forth does
<tp>
doing it in Forth is dead easy. easy to impliment, easy to instrument
<tabemann>
forth, well, you take the address, and you @ or ! it
<tabemann>
C, well, you could do that, but usually everything is hidden away in layers of structs
<tp>
Ive decided that Forths mission is information hiding
<tp>
Ive been working on the blackmagic probe source, written in C using libopencm3, and it's a nightmare to me
<tp>
I think people who have to do that stuff for a living must hate their lives
<tp>
I know the hardware, I know Forth well enough, but searching thru layers and layers of doxygen doc is frustrating
<tp>
Embedded C should have been drowned at birth, it's the stillborn mutant spawn of the devil
<tp>
system C is fine, I use it for pc software
<tp>
it's probably one of the best choices there
<tabemann>
the thing is that for embedded programming by necessity you are close to the hardware
<tabemann>
and C acts to abstract that away
<tp>
it sure does
<tp>
deliberately, on purpose
<tp>
it's just insane
<tp>
USART2 becomes "USART" as tho there four other usarts dont exist on the chip
<tp>
the abstraction is a gigantic foobar in itself, then you get the contortions and machinations the C system does to provide all that abstraction and the pages of useless comp generated documentation to provide 'apis' with scant info
<tp>
Forth doesnt have to have any of that
<tp>
Id have implemented CTS a day ago with Forth
<tabemann>
in Forth it's look up the registers, copy them from the svd2forth or just write them directly, then plug in the values
<tabemann>
it's all registers and bitfields
<tp>
yep
<tp>
as far as config goes
<tp>
after that you can start on the hll stuff
<tabemann>
but ultimately, if you need to, you just look at your original words, and everything's there as is
<tabemann>
whereas with C you have to decipher layer upon layer of structs
<tp>
I'm still not there getting CTS handshaking on a blackmagic probe
<tp>
code, flash, try, repeat
<tp>
it's about 20x longer than my Forth dev cycle
<tabemann>
and there's like major abstracting things away
<tp>
yeah
<tp>
you have to dig thru #defines etc
<tp>
i'll have to start using GDB to find out what the registers have
<tp>
one guy on a forumn runs Forth as a RTOS task to debug his C programs!
<tabemann>
which RTOS?
<tp>
dunno, probably freertos
<tp>
it's a good idea
<tabemann>
going to the freertos site is weird
<tabemann>
because on one hand their product seems über-commercial
<tp>
it seems to be very popular in oss embedded
<tabemann>
but on the other it's free software
<tp>
it's pretty much M4 territory tho
<tp>
too big for a F0
<tabemann>
yeah, somehow I imagine it's hard to fit something like anything beyond a minimal IP stack on an F0 (of course, then, Contiki managed to fit an IPv6 stack on machines like the C64)
<tp>
unlike the f4 the f0 has no ethernet peripheral
<tp>
if someone wanted ethernet, theyd use a m3 or m4
<tp>
the f0 isnt designed for any of that stuff
<tp>
STMicro has hundreds of different model cortex-m, theyre all similar so the designer can just use the one that best suits
<tp>
no need to make the f0 do stuff beyond it's design
kevin` has joined #forth
<tabemann>
back
<MrMobius>
heh I heard a podcast where they said you need at least 100k for a tcp stack :P
<MrMobius>
guessing they werent on a c64
<tabemann>
my bad
Rakko has quit [Quit: Leaving]
<MrMobius>
I mean Im saying the guys on the podcast were not 100% accurate
<tabemann>
Contiki provides multitasking and a built-in Internet Protocol Suite (TCP/IP stack), yet needs only about 10 kilobytes of random-access memory (RAM) and 30 kilobytes of read-only memory (ROM).[1] A full system, including a graphical user interface, needs about 30 kilobytes of RAM.[5]
<tp>
I have a PIC chip here with tcp facilities, it makes a very slow webserver
<tabemann>
okay, I should get to bed
<tabemann>
(I'm falling asleep anyways)
<tabemann>
g'night guys
<tp>
tabemann, night
jsoft has joined #forth
kevin` has quit [Remote host closed the connection]
gravicappa has joined #forth
jedb has quit [Ping timeout: 260 seconds]
mtsd has joined #forth
jedb has joined #forth
xek has joined #forth
andrei-n has joined #forth
<andrei-n>
Do Forth programmers typically write programs without using a debugger?
<tp>
andrei-n, Forth is 'interactive' so it has it's own debugger built in
<tp>
thats why I find C so hard, no interactivity
<andrei-n>
But what if you use linked lists and so on? I mean things that are not easy to initialize?
<tp>
I'm an embedded technician, to me debugging is all about hardware
<tp>
I ahve no idea what a linked list is or where it would be useful. My devices have little ram and flash, they control things like a washing machine etc
<tp>
I can easily use a buffer or an array in Forth tho
<andrei-n>
Well, I'm writing a text editor. And a text editor on Linux, ed, uses linked lists to store lines. So I wanted to do the same...
<tp>
thats programer stuff ;-) Im just a technician
<tp>
there are two classes of Forth I think, one is for a PC, the other for small embedded and they are used quite differently
<tp>
for instance, my editor is on the PC, it's called GVIM ;-)