<crest>
abusing the fact that gpio ports are 1024 bytes appart in the memory map
<tp>
youre retreading a well worn path
<crest>
premature optimization
<tp>
the last programmer before you that I know off was jeelabs
<crest>
the question is if its worth it to be this "clever"
<tp>
he spent about a year building up a site and doing his best to make Forth like C, in the end he gave it all up and left his many readers with a dead site
<crest>
i don't want to turn forth into c
<tp>
apparently he needed some major internal changes within Mecrisp-Stellaris to reach his goal and Matthias refused
<crest>
is that discussion publicly archived somewhere?
<tp>
you have more chance of moving heaven and hell than changing Matthias mind
<tp>
no
<crest>
maybe i can get him drunk at a ccc event
<tp>
goof luck :)
<tp>
hes already drunk on life I think
<tp>
you can ask him all about it next time you see him
<crest>
but sofar i see no reason to change something fundamental about mecrisp stellaris
<tp>
once jeelabs announced easy programming and libraries, his site became very popular
<crest>
even if local variables would have made the code more readable
<crest>
but local variables would make the compiler's life harder
<tp>
personaly, and I this is only my own opinion, I think jeelabs seeing the massive monetisation of arduino on stm32f103, decided to see if he could make the same kind of system with forth instead
<crest>
was it a license discussion?
<tp>
I've told you all I know
<tp>
I was never privy to more
<tp>
but Forth can be like a wolverine if you try and change it's nature
<crest>
i wanted a word to configure a gpio pin
<crest>
that worked for all gpio ports, pins, and modes
<tp>
I wanted, a million bucks, true love and happiness, oh and a donkey
<crest>
you shouldn't act on your passion for your donkey :-P
<tp>
i never even got the donkey
<tp>
haha
<tp>
in the end I found out I was the donkey
<crest>
and it took me about an hour to fight mecrisp into submission
<crest>
now cr! works
<tp>
what a lot of programmers dont realise about embedded is that the gpios are just a few bitfields among about 4000 in the case of the STM32F103
<tp>
and gpios arent special
<tp>
theyre just bitfields
<crest>
but you have port a-g
<tp>
yes, and about 4000 other bitfields
<tp>
the ports send data too and from peripherals
<tp>
and there are
<crest>
if you define a word for every bitfield 128kB flash aren't much
<tp>
53 peripherals in the mcu
<crest>
its hard to resist refactoring that
<tp>
lol, youd need well over a MB
<rdrop-exit>
I wonder why the jeelabs guy didn't just write his own Forth instead
<tp>
absolutely hard to resist refactoring for legendary Forth programmers
<crest>
rdrop-exit: its hard to write a forth like mecrisp st with an optimizing compiler
<crest>
it's
<tp>
crest, ask tabemann hes done most of it
<tabemann>
hey guys
<tp>
crest, his Forth is available right now, all you have to do is bend over before the God of Git
<tp>
het tabemann, legendary programmer and creator of Zeptoforth
<rdrop-exit>
the optimizing compiler could have come later, especially if his target market was Arduino users
<tabemann>
the main difference between mecrisp-stellaris and my forth his matthias's does all kinds of magical optimization whereas zeptoforth, well, it inlines and doesn't do much else
<rdrop-exit>
hi tabemann
<tp>
tabemann, matthias took a few years to produce the RA variant
<crest>
it would probably be easier to get arduino users hooked on micropython on an even bigger core
<tp>
crest, absolutely
<crest>
just throw more hardware at the problem
<crest>
maybe even a dual core arm
<rdrop-exit>
vroom vroom
<crest>
and put low latency helper code in c or asm on one core
<tabemann>
that's called a raspberry pi
<tp>
tabemann, and I think matthias was inspired after attending one of the chaos conferences and had a big session on optimisation
<crest>
tabemann: take a look at the nanopi neo(2)
<tp>
and 900 MHz!
<tp>
crest, but forget that for chip/noard Forth
<tp>
crest, but forget that for chip/board for Forth
<crest>
a quad 1.5ghz cortex a53
<tp>
the Nanopi at 600 Mhz is of course incredibly fast
* tabemann
owns a raspberry pi - he hasn't taken it out of the packaging
<rdrop-exit>
a pi could be interesting as a host rather than a target
<tabemann>
I heard someone complaining that the rpi takes way too much power and generates way too much heat these days
<crest>
tabemann: they are inefficient compared to other arm boards
<crest>
the rpi 4b+ really bends over backward to maintain compatibilty to older pis
<crest>
and they added a cheap but power hungry usb 3.0 chip
<tabemann>
I'm sticking with Cortex-M4 boards
* tabemann
just realized he chose instructions in such a manner as to completely break compatibility with Cortex-M0 without doing a major refactoring of his code
<tabemann>
like my code is littered with instances of TST rX, #Y - which turns out to be a Thumb-2 instruction
<crest>
tp: how do you deal with all the bitfields?
<crest>
do you just autogenerate them all and copy and paste them as needed?
<tp>
Teensy Arduino does 600 Mhz even 1000MHz just dont forget that heat sink
<tp>
crest autogenerate them all and copy and paste them as needed
<crest>
there are even amd ryzen quad core boards with an atmega added to the mini itx mainboard to appease the arduino crowed
<tp>
tabemann, I wouldnt worry about it, the mo is a totally different mcu anyway
<crest>
*crowd
<tp>
crest, my editor searches all open files to copy and paste lines, and my project manager opens the bitfields file after it generates it
<tabemann>
the arduino people... I don't even know what to say about them
<tp>
crest, so for me, 10's of thousands of bitfields can be instantly pasted into my code
<tp>
tabemann, yeah, I'm the same re arduino
<tp>
crest, this is a possible tile for a future rant "Why do programmers feel the need to turn "GPIOC_BSRR_BR15" into "15 port-c gpio-unset-pin" ?
<crest>
because they want to expose the problem's structure
<crest>
and just duplicating the code is boring
<tp>
it's a good question
<tp>
and of course only programmers know the answer
<crest>
that's what came to mind
<tp>
mhh, my rant biorythms are peaking this month
<crest>
most good programmers take pride in their work
<tp>
I think I'll do 'The five stages of embedded C programmer grief"
<tp>
crest, absolutely
<crest>
and duplicating code just feels like delivering shoddy work
jsoft has quit [Ping timeout: 246 seconds]
<tp>
crest, and what comes before a 'fall' ? ;-)
<crest>
.oO( hubris comes before the fall )
<tp>
crest, could it also be the NIH problem ?
<tp>
touche'
<crest>
but programmers are often hurt by bad apis
<tp>
i think that Forth will save all programmers in the end as long as they stay the course
<crest>
and want to create the "perfect" api
<tp>
crest, I have no trouble believing that
<crest>
stuff like what happend to me this night
<crest>
why don't won't these two pins obey me
<tp>
I think thats a excellent point
<crest>
the datasheet doesn't reference afio configuration
<crest>
a short warning would have saved me a lot of time
<tp>
they do
<tp>
but there are a 'few' datasheets one needs
<tp>
about 5 as a minimum
<crest>
it says alternate function i/o in the cnf and mode bitfiels
<tp>
the alternate functions are always described in the 'electrical' datacheet
<tp>
crest, it does, but thats only a part of it
<crest>
it is reasonable to assume that if you pick gpio instead of alternate function i/o you get access to the pin
<crest>
good documentation is linked in *both* directions
<tp>
whatever the tech sheet says is what you will get
<tp>
never assume with this stuff
<crest>
i don't
<crest>
instead i assumed that either something is special about those pins
<tp>
also, Im no F103 expert as I dont use it except in 2 projects
<crest>
or damaged two pins
<tp>
and you were right, swd or jtag or oscillator, or reset or a few others
<tp>
those MCUs are virtually indestructable
<tp>
they are the opposite of 'fragile'
<tp>
I've subjected them to all kinds of horrors
<tp>
and so far have failed to kill one other than during a boring flash operation
<crest>
let me get my 240V mains power, a bridge rectifier and 400V capacitors
<tp>
virtually indestructable
<tp>
that kinda stuff blows up the worlds most highly developed switching semis every day
<tp>
know what happens if you connect a led forectly to a gpio pin and 0v with no resistor on a PSU with lots of grunt ?
<tp>
the MCU gets very hot
<tp>
90C
<crest>
the magic smoke escapes?
<tp>
no
<tp>
the mcu survives
<tp>
they are incredibly robust
<tp>
crest, and you bring up a excellent point re embedded
<crest>
i do?
<tp>
I think the BEST thing a programmer can do when getting into embedded is hook up the hardware asap AND BUILD A BLINKY
<tp>
ultimately one can have all the theories in the world, but when that blinky wont work, reality must be confronted
<tp>
and the blinking of the light shall lead ye to the truth!
<crest>
the next step is let the leds turn into nice blinken lights
<crest>
maybe fade a bit from left to right and back again
<tp>
now it's true in the embedded world that a blinky is the equivalent of 'hello world' in a programmers world
<crest>
without wasting a significant amount of of the cpu cycles on it
<tp>
and when you guys think how easy 'hello world' is, you may wonder so whats the equivalent of a FFT ?
<crest>
?
<tp>
crest, thats a MASSIVE jump from a on off blinky
<tp>
fading
<tp>
will you do it in software, systick or interrupt and timer
<crest>
i don't want (software) pwm
<tp>
good
<tp>
thats childs play for a programemr
<crest>
just shift a bitfield in odr once per second
<crest>
with systick and multitasking
<tp>
eww
<crest>
why?
<tp>
thats perverted
<tp>
enbedded uses timers for that, which is why the F103 has 7 of them
<tp>
hardwae timers
<crest>
maybe because of my unix background i think of timers as something you do in software
<tp>
sure
<crest>
by multiplexing one of the few hardware timers you have
<tp>
but we dont do that in embedded
<crest>
build a nice datastructure for oneshot and interval timers
<tp>
why have a dog, and do the barking yourself ?
<crest>
configure the timer to wake you up when there something to do
<crest>
woof
<tp>
the chip has *7* hardware timers, just for you
<crest>
because there are *just* 7 timers
<tp>
only on your old chip
<tp>
time hasnt stood still since 2004
<crest>
a single timer is enough to animate the leds on a single port
<tp>
for pulse width control two timers may need to be synced depending
<crest>
just avoid data dependend control flows in the timer interrupt handler
Zarutian_HTC has quit [Remote host closed the connection]
TCZ has joined #forth
xek has quit [Ping timeout: 256 seconds]
<tp>
crest, that's it! ... I see the hardware configuration much like preparing the ground to lay concrete, it's messy, ugly, smelly, but has to be done correctly or the beautiful building that sits upon it may fall over later on
Zarutian_HTC has joined #forth
gravicappa has quit [Ping timeout: 240 seconds]
dave0 has joined #forth
TCZ has quit [Quit: Leaving]
<tabemann>
hey guys
<tp>
hey tabemann
<tabemann>
for some reason the disassembler is trying to treat the first halfword of a 32-bit BL instruction as a 16-bit instruction...
<tp>
have you taken the dissasembler out behind the woodshed and given it a good thrashing ?
<tabemann>
lol
<tp>
sometimes thats the only way
<tp>
dissasembler rebellion cant be tolerated!
<tp>
tabemann, check this out, I finally realised that bis! isnt needed with the BSRR words http://dpaste.com/3T14DQ0
<tp>
you can clearly see the mask operation with bis!
<tabemann>
back
<tp>
tabemann, I because so used to using bis! I tended to use it everywhere
<tp>
and never stopped to think about it not being required for setting/resetting gpio bits
<tp>
tabemann, so now my svd2forth does this:
<tp>
\ GPIOB_BSRR (write-only) Reset:0x00000000
<tp>
: GPIOB_BSRR_BS0 ( -- ) 0 bit GPIOB_BSRR ! ; \ GPIOB_BSRR_BS0, Set bit 0
<tp>
: GPIOB_BSRR_BS1 ( -- ) 1 bit GPIOB_BSRR ! ; \ GPIOB_BSRR_BS1, Set bit 1