<rdrop-exit> before the PC there were Apple, Commodore, TRS-80, and various other microcomputer Forth implementations
<tp> logand, Forth has been utterly malleable for me, and FLOSS has allowed me to build whatever I wanted
<logand> i am worried, that after i write something in forth and come back to it after a while, i'll have a hard time to understand what i wrote
<tp> rdrop-exit, good point, I guess my technician outlook is showing again
<tp> logand, unlike Perl ?
<tp> ;-)
<logand> is that a general problem or does it get better with experience?
<logand> tp: i dont write perl:-)
<rdrop-exit> factoring is the key
<logand> rather, unlike lisp, or c
<rdrop-exit> unreadable forth usually comes from insufficient factoring
<logand> yes, that's what i've been telling myself to build up motivation to dive into forth
tpbsd has joined #forth
<tpbsd> logand, Forth is no different to any other language as regards poorly documented code in my opinion
<tp> logand, the 'write only' accusation always levied against Forth is by non Forth users imho
tp has quit [Remote host closed the connection]
<rdrop-exit> it's not just a question of documentation
<tpbsd> logand, if youre using Forth on a pc, I recommend you try 'Retro' http://forth.works/book.html#retro-a-modern-pragmatic-forth
<tpbsd> rdrop-exit, thats what programmers always say!
<logand> tpbsd: yes pc, i'll have a look at retro
<rdrop-exit> if you need an explanatory comment *inside* a definition, then you should have factored
<tpbsd> rdrop-exit, I knew a incredibly smart programmer, he was the chief software architect for a massive firm, and he would always say 'good code is self documenting' which I still think is a load of crap
<tpbsd> as a tech still learning forth I heavily comment all my Forth code
<rdrop-exit> there a different levels of documentation, what you're trying to avoid is to have to document within the definitions
<tpbsd> inside and outside of definitions
<tpbsd> I'm not trying to do that at all
jsoft has joined #forth
<rdrop-exit> you should be
<rdrop-exit> for example
<rdrop-exit> : foo ( -- )
<rdrop-exit> .... \ frobinate the umbilator
<tpbsd> it seems to me that's very common advice from programmers who don't do embedded Forth
<rdrop-exit> should be replaced with
<rdrop-exit> ... umbilator frobinate
<tpbsd> sure, thats fair
<rdrop-exit> has nothing to do with embedded or not embedded
<tpbsd> but what about this case ?
<tpbsd> \ pa12 Open Drain
<tpbsd> : GPIOA_CRH_MODE12 ( %XX -- ) 16 lshift GPIOA_CRH bis! ; \ GPIOA_CRH_MODE12 Port n.12 mode bits
<tpbsd> thats a automatically generated Word
<rdrop-exit> there's no comment within the word in you're example, there's a comment about the word
<logand> tpbsd: should be replaced with pa12 open drain :-)
<tpbsd> the comment is automatically taken from the CMSIS 'description' field to help avoiding the need for a massive PDF technical manual to be open on the PC as well
<rdrop-exit> but as I said, I'm talking about comments *inside* definitions
<tpbsd> rdrop-exit, oops, apologies, but I have plenty of those as well
<tpbsd> logand, I have constants for that kind of thing, ie
<tpbsd> OUTPUT GPIOA_CRH_MODE12
<tpbsd> (not strictly true in this example as it's from a cortex-m3 which is a PITA to configure the GPIO's imho)
<logand> ok, why not GPIOA_CRH_MODE12 OUTPUT?
<tpbsd> : pa12-pulse ( -- ) \ Blue Pill PA12 normally HIGH, pulse LOW for 1ms
<tpbsd> PA12-LOW
<tpbsd> 10 ms.delay \ = 1ms (intervals are 0.1ms)
<tpbsd> PA12-HIGH
<tpbsd> ;
<tpbsd> that's a example of my comments within a Word
<tpbsd> logand, anything is possible, but OUTPUT GPIOA_CRH_MODE12 is easier and simpler imho
<logand> 10 is that fixed point?
<logand> or somehow different unit?
<tpbsd> logand, no, but Mecrisp-Stellaris has fixed point and I do use it
<tpbsd> logand, the 10 is just a decimal number
<rdrop-exit> that's a cofusing line, why does 10 ms.delay mean 1 ms?
<logand> ok i thought it was something like 10ms delay scaled down by 10
<tpbsd> probably because my comment is old and wrong ?
<logand> ah
<tpbsd> it should read \ = 10 ms (intervals are 0.1ms)
<tpbsd> but I'm working on this code right now and it's changing a lot
<logand> so it would actually be better without the comment
<tpbsd> the comment is to remind me that the systick is set to 0.1ms 'ticks'
<tpbsd> logand, it would be better like this \ intervals are 0.1ms
<tpbsd> but again, Im a technician not a programmer
<logand> or define a constant and write it explicitly in the code?
<rdrop-exit> until you change the intervals, then the comment will be wrong again
<logand> 10 ms.delay -> 10 ticks would be better?
<logand> : 1ms 10 ticks ;
tpbsd has quit [Remote host closed the connection]
tp___ has joined #forth
tp___ has joined #forth
tp___ has quit [Changing host]
<tp___> apologies for the dropouts, I think the Internet has the Corona virus atm
tp___ is now known as tp
<tabemann_> hey guys
<rdrop-exit> hi tabemann
<tp> hey tabemann_ !
<tp> logand, I really recommend Retro, it's well thought out, has it's own Literate Programming solution and compiles on everything Ive tried
<logand> tp: ok, it looks quite different from forth
<tp> logand, retro has persuaded me to try it instead of Perl as a PC 'glue' solution here
<tp> logand, but that's the essence of forth!
<rdrop-exit> 12 pa clear 10 ticks 12 pa set
<logand> ok, i'm thinking about doing some projects in forth instead of c so i'll see how it goes
<tp> logand, even the creator of Forth when asked 'what is Forth replied 'I can't say for sure, but I know it when I see it'
<tp> rdrop-exit, and what does your PA12 config look like ?
<logand> rdrop-exit: that is very readable
<tabemann_> if you're feeling ambitious you can write your own forth, and then you get to make it however you want!
<tp> clear but meaningless by itself
<rdrop-exit> tp, does it matter?
<tp> rdrop-exit, it's absolutely critical
<logand> tp: yeah but he had decades to think about one line, i dont have that much time
<tp> PA12 as default after a reboot is set to 'input', 'floating' mode
<tp> PA12 without prior config wont send any data out
<rdrop-exit> I have no idea what a PA12 is
<tabemann_> all I know is PA12 is some hardware register
<logand> tp: you can give it desired meaning
<tp> thats technician slang for GPIO-A-12 but has been in common use for the last 20 years or more
<tp> PA12 is pronounced "port a pin 12"
<tp> and as all ports are general purpose input output anyway, we abbreviate GPIOA12 to PA12
<rdrop-exit> so why can't your code look similar to that?
<rdrop-exit> a port 12 pin set
<tp> it certainly can with Forth
* tabemann_ is mesmerized by his blinky
tabemann_ is now known as tabemann
<tp> thats the awesome thing about forth, and why every Forth is different, it can be whatever you want it to be :)
<rdrop-exit> you should only have numbers as part of names in special cases
<tp> tabemann is to be congratulated for his 'zeptoforth' blinky milestone especially as he's a programmer nd not a tech like me
<tabemann> you've already congratulated me for that! lol
<rdrop-exit> for example if it's a primitive, e.g. 16@ 32@
<tp> tabemann, I know, now Im telling everyone *else*
<rdrop-exit> kudos tabemann
<logand> good night & thanks for ideas!
<tabemann> one thing I did this morning was factor out my "driver" code from my non-driver code amongst my Forth (rather than kernel) codebase
<tabemann> g'night
<tp> rdrop-exit, but in embedded names and numbers in a single word are the default
<rdrop-exit> good night logand
<tp> tabemann, night-o
<tp> oops
<tabemann> I was saying 'night to logand
<tabemann> lol
<tp> logand, night-o, great speaking, please return!
<tabemann> *g'night
<rdrop-exit> tp, it depends
<tp> rdrop-exit, if you look in the MCU datasheet youll see that register names and numbers are as one, for example
<rdrop-exit> sure, but the 12th pin of a register is the 12th pin
dave0 has joined #forth
<tp> RCC_APB1ENR
<rdrop-exit> of a port I mean
<tp> actually the 12 pin is usually bit 13 as pins start at 1 and bits at 0
<tp> theer is never a pin 0
<rdrop-exit> sure, but the 12th pin is the 12th pin\
<tp> rdrop-exit, thats academic, in the real world gpio pins are specified by port and number
<rdrop-exit> so that's how you should specify them in your forth, by port and number, no?
<tp> there may be 180 pins on a mcu
<rdrop-exit> so?
<tp> and I have above
<rdrop-exit> hmm
<rdrop-exit> I think we're talking past each other
<tp> : GPIOA_BSRR_BS0 %1 0 lshift GPIOA_BSRR ; \ GPIOA_BSRR_BS0 Set bit 0
<tp> probably, it's very easy to do when one knows littel about software and the other little about hardware :)
<rdrop-exit> 0 bit gpio-bsrr set
<rdrop-exit> 1 bit gpio-bsrr set
<rdrop-exit> 0 bit gpio-bsrr clear
<tp> no because the factory naming convention is CMSIS-SVD and used automatically in my definition
<tp> you have also omitted the actual port
<rdrop-exit> doesn't my code do the same as yours?
<tp> ports number from A to H in some models with sufficient pins
<tp> your code is the same as "go to the shop and buy 10"
<tp> 10 what ?
<rdrop-exit> my code does exactly the same as yours
<tabemann> except you forgot the A
<tp> not only that, but unless your unknown port is configured as a OUTPUT your code will do nothing
<rdrop-exit> ok fine,
<tp> or the B
<tp> :)
<tp> or the H :)
<rdrop-exit> 0 bit a port gpio-bsrr set
<tp> rdrop-exit, this very GPIOX situation drives C coders into conniptions
<rdrop-exit> or if you prefer
<tp> rdrop-exit, now is that port a input or a output ? is it open collector or push-pull ?
<rdrop-exit> look at the docs
<tp> rdrop-exit, does it have a pull-up or a pull-down ?
tp has quit [Remote host closed the connection]
tpbsd has joined #forth
tpbsd has quit [Changing host]
tpbsd has joined #forth
<tabemann> I assumed you weren't oone to ragequit -lol
<tpbsd> these kind of issues cause C coders to create stuff like this:
<tpbsd> void gpio_init(){
<tpbsd> GPIO_InitTypeDef GPIO_InitStructure;
<tpbsd> RCC_AHBPeriphClockCmd (RCC_AHBPeriph_GPIOC | RCC_AHBPeriph_GPIOA,ENABLE);
<tpbsd> RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
<tpbsd> GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_8 ;
<tpbsd> GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
<tpbsd> GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
<tpbsd> GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
<tpbsd> GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
<tpbsd> GPIO_Init(GPIOC, &GPIO_InitStructure);
<tpbsd> }
<tpbsd> tabemann, no definitely not :)
<tpbsd> I have never lost my temper in the 65 years I remember
<tpbsd> sadly my Internet connection is up and down like a yoyo today
<tpbsd> rdrop-exit, this very issue has been very interesting to me, how to present the hardware configuration of *every* GPIO in a readable and logical manner in Forth
<rdrop-exit> you exploit the regularities
<tpbsd> rdrop-exit, Im still working thru it, since 2014
<tpbsd> rdrop-exit, sure, but there are *so many* regularities
<tpbsd> look at *one* of the C solutions above ?
<rdrop-exit> that's a good thing, many irregularities would be bad
<tabemann> that C solution seems... overengineered
<tpbsd> some of them are dangerous to even look at for me, I have to make sure I dont have a mouthfull of coffee when I read them on my screen ;-)
<rdrop-exit> it's best not to even look at the C solution, it's fairly irrelevant to the Forth solution
<tpbsd> tabemann, every C 'solution' Ive seen has been very overengineered
<tpbsd> rdrop-exit, not so :(
<rdrop-exit> I prefer to study the specs than someone's C code
<tpbsd> rdrop-exit, wait until you actually want to *use* a peripheral and the technical manual is ambiguous ...
<rdrop-exit> oh I'm well aware there are ambiguities
<tpbsd> you know there is a problem because the peripheral isnt doing what you wanted after you read the manual several times
<rdrop-exit> Forth is great for testing the ambiguities
<tpbsd> I *don't* want to go anywhere near C code, but sometimes a person gets desperate after multiple failures 'mistakes were made!'
<tpbsd> rdrop-exit, thats so true, but even the near god like realtime testing can;'t help you sometimes
<rdrop-exit> the problem with looking at someone's C solution is that it unduly influences your Forth solution
<tpbsd> KipIngram, nice one :)
<rdrop-exit> the code ends up looking like a translation from C
<tabemann> KipIngram, the paper products aisle was absolutely empty aside from a misplaced roll of aluminum when I went past there today
<tpbsd> rdrop-exit, not in my case, no way
<tabemann> *aluminum foil
<tpbsd> rdrop-exit, the need to look at the C code is *only* to find what super sekret config was needed
<rdrop-exit> C solutions often have combinatorial explosion built-in
<rdrop-exit> e.g., defining constants for every combination instead of exploting regularity
<tpbsd> the top code is obviously C, the bottom code is my actual Forth code
<rdrop-exit> 0 lshift ?
<tpbsd> rdrop-exit, in the MCU in question there are 53 peripherals 722 registers and 4833 bitfields and every single one is different
<tpbsd> rdrop-exit, automatically generated code
<rdrop-exit> I understand there are many peripherals and many registers and many bitfields
<rdrop-exit> there are also many exploitable regularities
<tpbsd> and you understand that they are ALL different ?
<rdrop-exit> do you understand that there are regularities, even if they are all different?
<tpbsd> rdrop-exit, your eagle eye spotting the "0 lshift" is a good reminder to me, I need to recode my parse to get rid of those cases
<tpbsd> rdrop-exit, I'm sure I do not do so anywhere near as well as you :)
<rdrop-exit> what is the definition of TSC_CR in your example?
<tpbsd> rdrop-exit, my most recent improvement to my parser has changed all cases where there is only one bit to change from ": RCC_APB2ENR_IOPAEN %1 2 lshift RCC_APB2ENR bis! ; \ RCC_APB2ENR_IOPAEN I/O port A clock enable" to "17 bit RCC_AHBENR \ RCC_AHBENR_IOPAEN, I/O port A clock enable"
<tpbsd> so I'm slowly improving it, but it's all XML parsing via XLST
<tpbsd> there is no "TSC_CR"
<rdrop-exit> : TSC_CR_PGPSC ( %XXX -- ) 12 lshift TSC_CR ;
<tpbsd> oh ok
<tpbsd> the TSC_CR is a peripheral register
<rdrop-exit> what's the definition?
<tpbsd> and the TSC_CR_PGPSC is a bitfield in that register
<rdrop-exit> it must be more than just a number since it consumes an argument
<tpbsd> TSC control register (TSC_CR)
<rdrop-exit> what is the definition?
<tpbsd> thats it
<rdrop-exit> I mean the Forth definition
<tpbsd> $40024000 constant TSC ( Touch sensing controller )
<tpbsd> TSC $0 + constant TSC_CR ( control register )
<rdrop-exit> cannot be
<tpbsd> sorry about the delays replying it involves looking up the data sheets etc
<rdrop-exit> in you TSC_CR_PGPSC definition TSC_CR consumes the result of the 12 lshift
<tpbsd> it is I assure you
<rdrop-exit> : TSC_CR_PGPSC ( %XXX -- ) 12 lshift TSC_CR ;
<rdrop-exit> note the stack picture ( %XXX -- )
<tpbsd> thats a bitfield named "PGPSC" which is a bit in the TSC_CR
<tpbsd> ok, it's actually a group of 3 bits in the TSC_CR
<rdrop-exit> there's something on the stack, it then gets shifted by 12, and then gets consumed by TSC_CR since the ending stack picture has nothing on it "-- )"
<tpbsd> : TSC_CR_PGPSC ( %XXX -- ) 12 lshift TSC_CR ; \ TSC_CR_PGPSC, pulse generator prescaler
<tpbsd> Bits 14:12 PGPSC[2:0]: Pulse generator prescaler
<tpbsd> These bits are set and cleared by software.They select the AHB clock divider used to generate
<tpbsd> the pulse generator clock (PGCLK).
<tpbsd> 000: fHCLK
<tpbsd> 001: fHCLK /2
<tpbsd> 010: fHCLK /4
<tpbsd> 011: fHCLK /8
<tpbsd> 100: fHCLK /16
<tpbsd> 101: fHCLK /32
<tpbsd> 110: fHCLK /64
<tpbsd> 111: fHCLK /128
<tpbsd> Note: These bits must not be modified when an acquisition is ongoing.
<tpbsd> Note: Some configurations are forbidden. Please refer to the Section 16.3.4: Charge transfer
<tpbsd> acquisition sequence for details.
<tpbsd> thats a paste from the technical pdf
<rdrop-exit> you're not getting what I asked
<tpbsd> apologies for the crappy layout
<tpbsd> what specifically are you asking me for ?
<tpbsd> your last comment was not a question
<rdrop-exit> there's something on the stack, it then gets shifted by 12, and then gets consumed by TSC_CR since the ending stack picture has nothing on it "-- )"
<rdrop-exit> you just said TSC_CR was a constant, I said cannot be since it consumes something off the stack
<tpbsd> there is no suitable stack end picture that I can see
<rdrop-exit> ( %XXX -- )
<tpbsd> TSC_CR is a constant'
<tpbsd> TSC_CR_PGPSC is not
<rdrop-exit> that stack picture implies TSC_CR_PGPSC consumes what's on the stack
<rdrop-exit> when it's done there's one less entry on the stack
<tpbsd> TSC_CR_PGPSC is my current solution for configuring bit(s) in a register such as TSC_CR
<tpbsd> yes, it does
<tpbsd> Im quite proud of that stage of my svd2forth evolution
<rdrop-exit> ok so lets walk through it and see if what you're saying is possible
<tpbsd> please do :)
<rdrop-exit> the stack starts with %XXX on it
<tpbsd> I appreciate your laser like Forth focus on this
<tpbsd> correct
<rdrop-exit> 12 lshift shifts it over, so you still have one thing on the stack
<rdrop-exit> then
<rdrop-exit> TSC_CR is constant
<rdrop-exit> so you now have 2 things on the stack
<rdrop-exit> which contradicts your stack picture ( %XXX -- )
<tpbsd> if you read down the page a bit you will see: \ 1. CONFIGURE TCS With a charge transfer around 2.5 µs
<tpbsd> %101 TSC_CR_PGPSC bis! \ a. Select fPGCLK = fHCLK/32. fPGCLK = fHCLK/32, 101: fHCLK /32
<rdrop-exit> it says you have one less thing on the stack at the end
<rdrop-exit> do you see the contradiction I am pointing out?
<tpbsd> not yet, but Im trying
<tpbsd> perhaps the stack ens could be: "TSC_CR_PGPSC ( %XXX -- TSC_CR)" ?
<tpbsd> stack end
<rdrop-exit> let's take an example, lets say I start with an empty data stack and I type "123 TSC_CR_PGPSC" what is on the stack now?
<tpbsd> it would fail
<rdrop-exit> your stack comment says there should be nothing on the stack
<tpbsd> because it's awaiting a binary
<tpbsd> of three bits
<rdrop-exit> ok fine, then type "7 TSC_CR_PGPSC"
<rdrop-exit> if I start with an empty stack and type that, your stack comment says I should end up with an empty stack again
<rdrop-exit> ( %XXX -- )
<tpbsd> and you will because 7 will be moved into that bitfield known as PGPSC
<rdrop-exit> can you try it please
<tpbsd> which is a part of TSC_CR
<rdrop-exit> I thought TSC_CR was just a constant, that's what you said
<tpbsd> it is
<tpbsd> all registers are just constants
<rdrop-exit> constants don't consume items off the stack
<rdrop-exit> they push an item onto the stack
<tpbsd> sounds reasonable :)
<rdrop-exit> If I have nothing on the stack, after a constant, I have something on the stack
<rdrop-exit> so how do you end up with nothing ( %XXX -- )<===
<tpbsd> : TSC_CR_PGPSC ( %XXX -- ) 12 lshift TSC_CR ; is how
<rdrop-exit> lets say I have 7 on the stack
<rdrop-exit> ---> 7
<tpbsd> there is a Word action missing that is present in the next stage of that configuration
<tpbsd> ok
<rdrop-exit> I then push 12
<tpbsd> ok
<rdrop-exit> ---> 7 12
<tpbsd> sure
<rdrop-exit> I then lshift
<tpbsd> ok
<rdrop-exit> ---> 28672
<tpbsd> yes
<tpbsd> and thats where the second word is used
<rdrop-exit> I then have the constant TSC_CR, for arguments sake, lets say it's 100
<tpbsd> because it contains a 'bis!' action
<rdrop-exit> so it's not a constant then?
<rdrop-exit> what is TSC_CR's definition please
<tpbsd> TSC_CR is certainly a constant
<rdrop-exit> what's it's value
<tpbsd> $40024000 constant TSC ( Touch sensing controller )
<tpbsd> TSC $0 + constant TSC_CR ( control register )
<tpbsd> same as when you asked last time
<tpbsd> :)
<rdrop-exit> ok so after it gets executed:
<rdrop-exit> ---> 28672 $40024000
<rdrop-exit> that's your stack
<rdrop-exit> it's not empty as ( %XXX -- ) is telling us
<tpbsd> ahh I think I see where youre going
<tpbsd> and youre responsible for that anyway !
<tpbsd> hahahah
<rdrop-exit> grrr :)
<tpbsd> that Word previously had : TSC_CR_PGPSC ( %XXX -- ) 12 lshift TSC_CR BIS! ;
<rdrop-exit> aha
<tpbsd> but after you mentioned that the action was better used later, I removed it
<tpbsd> and it's used here
<tpbsd> %101 TSC_CR_PGPSC bis! \ a. Select fPGCLK = fHCLK/32. fPGCLK = fHCLK/32, 101: fHCLK /32
<rdrop-exit> You could do this instead:
<rdrop-exit> %101 PGPSC TSC_CR bis!
<tpbsd> at the time when you mentioned it, my code would have been "%101 TSC_CR_PGPSC" which always worried me anyway
<tpbsd> as it looked incomplete
<tpbsd> it's too bad tabemann is asleep, this info will be very relevant to him
<rdrop-exit> : PGSPC ( mask -- x ) 12 lshift ;
<tpbsd> I dont like that because it doesnt indicate how many bits in the mask
<rdrop-exit> ok then
<tpbsd> and whats a "x" ?
<tpbsd> please forgive my ignorance here
<rdrop-exit> : PGSPC ( %xxx --- x ) 12 lshift ;
<rdrop-exit> x just means an a generic something
<tpbsd> : TSC_CR_PGPSC ( %XXX -- ) 12 lshift TSC_CR ;
<tpbsd> hmm
<tpbsd> : PGSPC ( %xxx --- x ) 12 lshift ; is definitely no good
<tpbsd> reason ?
<tpbsd> there may be TWO or more PGSPC and theyre all different
<tpbsd> sadly the CMSIS-SVD was never run thru a program to detect bitfields with the same name
<tpbsd> when STM designed the bitfield names
<rdrop-exit> that's a shame, you can only exploit the regularities that exist
<tpbsd> it would have made my solution a lot easier
<tpbsd> lol, in my first iterations I did assume that all bitfield names were unique
<tpbsd> and that worked fine until I discovered they wern't
<tpbsd> :(
<rdrop-exit> I usually use dot notation in that case
<tpbsd> and if that was the only problem it would have been ok
<rdrop-exit> tsc-cr.pgspc
<rdrop-exit> if its a mask I usually start the name with a percent sign
<rdrop-exit> %tsc-cr.pgspc
<tpbsd> I was tempted to use that strategy
<tpbsd> but it's a matter of viewpoint here
<rdrop-exit> I hate underscores in names, like C uses
<tpbsd> your's is a programmers perstective, mine is a tech
<tpbsd> yeah, I also avoid underscores generally
<tpbsd> you see TSC_CR_PGPSC as a mask, I dont
<rdrop-exit> 0 source RV32 - CPU Regs - CSRs - D-Mode - csr.dcsr 1|2
<rdrop-exit> 1
<rdrop-exit> 2 $ 7b0 constant csr.dcsr
<tpbsd> I see it as a bitfield
<rdrop-exit> 4 31 28 bits constant %csr.dcsr.xdebugver
<rdrop-exit> 3
<rdrop-exit> 5 \ 27 16 bits hardwired 0
<rdrop-exit> 6 15 bit constant %csr.dcsr.ebreakm
<rdrop-exit> 7 \ 14 bit hardwired 0
<rdrop-exit> 8 13 bit constant %csr.dcsr.ebreaks
<rdrop-exit> 9 12 bit constant %csr.dcsr.ebreaku
<rdrop-exit> a 11 bit constant %csr.dcsr.stepie
<rdrop-exit> b 10 bit constant %csr.dcsr.stopcount
<rdrop-exit> c 9 bit constant %csr.dcsr.stoptime
<rdrop-exit> d 8 6 bits constant %csr.dcsr.cause
<rdrop-exit> e \ 5 bit hardwired 0
<rdrop-exit> 0 source RV32 - CPU Regs - CSRs - D-Mode - csr.dcsr 2|2
<rdrop-exit> 1
<rdrop-exit> 2 4 bit constant %csr.dcsr.mprven
<rdrop-exit> 3 3 bit constant %csr.dcsr.nmip
<rdrop-exit> 4 2 bit constant %csr.dcsr.step
<rdrop-exit> 5 1 0 bits constant %csr.dcsr.prv
<rdrop-exit> that's how I define bitfield masks for registers
<rdrop-exit> that's a 32 bit debug control and status register
<tpbsd> it's awesome to see your perspective and method
<rdrop-exit> the source is from a forth screen block, the digits on the extreme left are just the line numbers 0-f
<tpbsd> I note that in this example each bitfield is limited to one bit ?
<rdrop-exit> no look again
<rdrop-exit> 8 6 bits constant %csr.dcsr.cause
<tpbsd> ahh!
<rdrop-exit> that defines a constant that has bits 8,7,6 set
<tpbsd> so %csr.dcsr.cause uses bits 8,7,6 ?
<rdrop-exit> yes
<rdrop-exit> its value is therefore % 111000000
<rdrop-exit> onlu bits 8..6 are set
<rdrop-exit> * only
<tpbsd> and do you intend to supply these for every MCU you support ?
<tpbsd> GD32VF103Cx 46 peripherals1074 registers7713 bitfields
<rdrop-exit> sure but you don't use all of them
<tpbsd> and the only definitions are in ARM CMSIS-SVD
<tpbsd> ??
<rdrop-exit> I normally just define what I need as I read the spec
<tpbsd> but you may use any ONE of them ?
<rdrop-exit> as I said, I define *what I need* as I read the spec
<tpbsd> well youre a programmer, but I found that hand transcribing from the data sheets to code is fraught with errors, thats why I automated the provess
<tpbsd> and thats what every embedded user of Mecrisp-Stellaris was doing before I designed my svd2forth
<tabemann> back
<tpbsd> welcome back! tabemann
<rdrop-exit> that's why I use notations that are less error prone, I just type them in as I read them
<tpbsd> it resulted in many different names for the same things and total code incompatibility
<tpbsd> my experience tells me youre painting yourself into a corner
<tpbsd> it's definitely the Forth way to do it tho :)
<rdrop-exit> nope, no matter how you define them, you need to test them before you use them
<tpbsd> I cant help but think that the full meaning of "GD32VF103Cx 46 peripherals 1074 registers 7713 bitfields" hasn't yet fully sunk in for you yet
<rdrop-exit> but I'll never use all of those, I only ever bother with what I am using
<tpbsd> just a quick test, can you please count out loud from 1 to 7713 for me ?
<tpbsd> and let me know when youve finished ?
<tabemann> : foo 7713 1 do i . loop ;
<tabemann> foo
<tpbsd> you dont have to uae all of them
<tpbsd> hahah
<rdrop-exit> If I need a frombulator, I read the frombulator spec, and type in the constants as I read it
<tpbsd> and fair enough
<tpbsd> tabemann, YOU CHEAT!
<rdrop-exit> I'm so used to doing it that way, it's second nature
<tpbsd> rdrop-exit, I can see that
<rdrop-exit> anything I don't need, I'm not going to bother with
<tpbsd> rdrop-exit, I do see now that my stack picture is incomplete tho :)
<rdrop-exit> cool :)
<tpbsd> rdrop-exit, thanks for taking the time to get that thru my thick techs head
<tabemann> with zeptoforth I've only used small pieces of the device space, so I've haven't had the need to use the converted SVD file you sent me tp
<tpbsd> tabemann, of course not, it's still early days
<tpbsd> tabemann, wait until you want to build say ... a capacitance touch sensor
<tabemann> right now all I've needed to do is A) set up the processor clock B) set up the USART C) read and write to the flash D) read and write to the USART and E) turn on and off LEDs
<tabemann> *write and erase the flash
<tpbsd> tabemann, youve made a blinky and that requires you do all the config required, so now you have 1) read the tech data and assimilated it, 2) written the code, 3) verified it works by the flashing of the led ... so you have covered all the important aspects
<tabemann> actually I stole the LED driver code from Matthias Koch - lol
<tpbsd> that's ok, not important
<rdrop-exit> here's a JTAG Test Access Point for a RISC-V
<rdrop-exit> 0 source RV32 - Debug Translator - TAP DRs - tap.dtmcs 2|2
<rdrop-exit> 2 \ 31 18 bits hardwired 0
<rdrop-exit> 1
<rdrop-exit> 3 17 bit constant %tap.dtmcs.dmihardreset
<rdrop-exit> 4 16 bit constant %tap.dtmcs.dmireset
<rdrop-exit> 5 \ 15 bit hardwired 0
<rdrop-exit> 6 14 12 bits constant %tap.dtmcs.idle
<rdrop-exit> 7 11 10 bits constant %tap.dtmcs.dmistat
<rdrop-exit> 8 9 4 bits constant %tap.dtmcs.abits
<rdrop-exit> 9 3 0 bits constant %tap.dtmcs.version
<rdrop-exit> a
<rdrop-exit> b
<rdrop-exit> or rather that's a TAP data register
<rdrop-exit> (the Debug Translator Module Control and Status Test Access Point data register to be exact)
<rdrop-exit> oops Debug Transport Module, not Translator Module
<tpbsd> rdrop-exit, the reason I didn't use "." as a peripheral.register.bitfield" separator was because I do a LOT of grepping and it's just easier to use a "-" as the separator when searching
<rdrop-exit> Ah, I use my block editor's search
<tpbsd> personally I prefer the "." as a separator
<tpbsd> it's just neater
<tpbsd> tabemann, what's vitally important is you go thru the process from code to making a led blink
<rdrop-exit> I typed those bitfields as I was reading one of those register bitfield diagrams from the RISC-V spec
<tpbsd> tabemann, then you understand what is needed when you have to configure a peripheral with *hundreds* of bitfields that must be individually configured
<tabemann> even the minimal peripherals I deal with are non-obvious to initialize
<tpbsd> rdrop-exit, and that's fine, I did, as does any Mecrisp-Stellaris user who isnt using my svd2forth but it's very error prone, and time consuming
<tabemann> and really all I'm initialize are the clock, the USART, the flash, and the LEDs
<tpbsd> tabemann, *exactly*
<tpbsd> from experience I can see rdrop-exit wondering why a peripheral isnt doing what he wants. He has to check his code AND his hand typed manual to code config
<tpbsd> while riscv is undoubtedly 'better' than STM32, it's documentation is *utter shit* in comparison to STM
<tpbsd> STM doc looks like it was written by Ghods tech dept after reading the GD32VF103 doc
<rdrop-exit> the time consuming part is testing, the typing I do as I read the spec, I also find typing code and comments as I read helps me grok the spec
<tpbsd> rdrop-exit, I'm convinced that nothing you do is not well thought out first
<tpbsd> rdrop-exit, but the tyranny of configs makes the grocking it all simply beyond everyone
<rdrop-exit> I not only type the bitfields but each shadow comment too:
<rdrop-exit> 0 shadow RV32 - DMRs - dmr.dmstatus 1|12
<rdrop-exit> 2 dmr.dmstatus
<rdrop-exit> 3 Offset from a DM's base DMI bus address of its dmr.dmstatus
<rdrop-exit> 1
<rdrop-exit> 4 (Debug Module Status) DMR (32-bit, R/O).
<rdrop-exit> 5 This DMR reports status for the overall DM as well as the
<rdrop-exit> 6 currently selected harts, as defined in hasel.
<rdrop-exit> 7
<rdrop-exit> 8 %dmr.dmstatus.impebreak
<rdrop-exit> 9 Bit mask for isolating the dmr.dmstatus impebreak bit (R/O,
<rdrop-exit> a preset).
<rdrop-exit> b When the corresponding DMR bit is set it indicates that there
<rdrop-exit> c is an implicit ebreak instruction at the non-existent word
<tpbsd> there are those that disdain standards such as CMSIS-SVD but I dont think they understand the tyrany of ARM configs either
<rdrop-exit> d immediately after the Program Buffer.
<rdrop-exit> e
<tpbsd> youre a artisan rdrop-exit !
<tpbsd> in my case it takes 0.1 second to create all the Words for every bitfield in any MCU with a CMSIS-SVD
<tpbsd> some may generate 1MB of text
<tpbsd> sure, my system is far from perfect, but the things that stop my projects working arent due to manufacturer spec errors
<rdrop-exit> I can't grok anything in 0.1s
<tpbsd> theyre the usual problems of not grocking a *complex* peripheral, not realising that some register has a "guard register" and nothing I do will work until that is satisfied, and a million other reasons
<tabemann> back
<tabemann> tp: I'm gonna create a scheduler to use with my multitasker
<tpbsd> nor can I, but my time is spent under`standing the peripheral, not hand writing the registers
<tabemann> where each scheduled "action" is just a word called round robin
<tabemann> with no separate stack
<tabemann> the scheduler can be used with or without the multitasker
<tpbsd> tabemann, mine is even simpler, just task1 ... task2 etc
<rdrop-exit> My strategy is to read the spec and take notes that happen to be usable as code, then to test my assumptions
<tpbsd> with the limited resources of my MCU I have to be careful to conserve them
<tabemann> my motivation is that each task is kinda heavy-weight, and what I'm trying to do is going to result in a bunch of tasks
<tpbsd> rdrop-exit, mine is similar, I just dont have to hand code the memory maps and bitfields
<tpbsd> tabemann, aha, makes sense
<tabemann> whereas most of these don't actually require their own stacks
<tabemann> just a function that is called repeatedly
<tpbsd> same here
<rdrop-exit> If they don't need their own stacks, then they're coroutines rather than tasks
<rdrop-exit> that's the main differentiator between a task and a coroutine
<tpbsd> in my most recent touch sensor, I call the task that activates the peripheral every 100ms, but 10ms after the first task, another one prints the results
<tpbsd> rdrop-exit, thats not suitable for me as the word 'coroutine' is far too long!
<tpbsd> :)
<tpbsd> courotine-1 ... thats exhausting to type!
<rdrop-exit> you don't need a "coroutine" word, just a yield word
<tpbsd> task1 I can handle
<tpbsd> i only have a scheduler, theer is no yield
<tpbsd> it's not a multitasker
<tabemann> a yield requires saving a PC
<tabemann> I don't intend to save a PC
<tpbsd> there is no stack for every task
<tabemann> I intend to just call a function again and again and again
<rdrop-exit> a coroutine yield only requires a primitive that swaps the TOS with the TOR
<tpbsd> it's just a timed sequence, much like Boeings recent failed space capsule uses ...
<rdrop-exit> what Chuck calls EX in Color Forth
<rdrop-exit> TOS <-> TOR
<tabemann> what I am planning on doing in ways is more elaborate than that, because the scheduler also pauses between actions so that the main prompt functions
<rdrop-exit> YIELD is just like PAUSE but for coroutines
<tabemann> (it's meant to be used with the multitasker)
<tabemann> anyway, swapping the TOS and TOR only works when you have two coroutines
<tabemann> whereas I envision having arbitrary numbers of them
<rdrop-exit> you can have as many as you want, but you have to be <Elmer Fudd voice> very very careful
<rdrop-exit> Coroutines are much more delicate to work with than tasks
<rdrop-exit> Since coroutines are sharing the tasks you can only yield at stack neutral points
<rdrop-exit> * sharing the stacks (not tasks)
<rdrop-exit> they're most useful for polling devices intermittently from a mainline
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit> I'm trying to find the Chuck's page that discusses the instruction, my Google-fu is not up to snuff today
<rdrop-exit> the EX instruction appears also in this Green Arrays flyer:
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
<rdrop-exit> Found it!
<rdrop-exit> scroll down to the opcode 01, the "ex" instruction on this page:
<rdrop-exit> My description should have said eexchange the IP with the TOR
<rdrop-exit> IP <--> TOR
<rdrop-exit> brain fart
<rdrop-exit> If you're going to have a subroutine YIELD you might as well also have conditional variants ?YIELD and 0YIELD
<rdrop-exit> as well
<rdrop-exit> yield ()( r: ra -- ip )
<rdrop-exit> 0yield ( x|0 -- )( r: ra -- ra|ip )
<rdrop-exit> ?yield ( x|0 -- )( r: ra -- ip|ra )
<rdrop-exit> yield Yield to coroutine.
<rdrop-exit> 0yield Yield on zero.
<rdrop-exit> ?yield Yield on non-zero.
<tpbsd> bak, sorry the worlds most awesome daughter phoned me:)
<rdrop-exit> why are my daughters phoning you?
<tpbsd> hahah, I knew that was coming
<rdrop-exit> ;)
<tpbsd> I cant say more because I don't want to shatter any fathers illusions :)
<rdrop-exit> :-p
<tpbsd> I'm pretty sure that you have the worlds 2nd most awesome daughter tho
<rdrop-exit> well I have 2 daughters
<rdrop-exit> tabemann, you might find "Patters of Time-Triggered Embedded Systems" by Michael J. Pont an interesting read, the examples are all 8051 based, but the patterns are more or less generic
dys has quit [Ping timeout: 264 seconds]
<rdrop-exit> * Patterns for Time-Triggered Embedded Systems
<tpbsd> I have 2 daughters but only one that I run to the phone if I know it's her
<dzho> dang
<rdrop-exit> I have 4 kids, boy, girl, boy, girl, and 1 grand-daughter
<tpbsd> I have 6 kids, 4 boys, 2 girls
<tpbsd> and 4 grandkids
<tabemann> back
<rdrop-exit> you're a braver man than I tp
<rdrop-exit> dzho, dang?
<tpbsd> rdrop-exit, your chats are always very instructive, and naturally a massive assistance to my Forth understanding and designs
<tabemann> I have one daughter
<rdrop-exit> thanks tp
<tpbsd> rdrop-exit, I wanted 4, my ex wife wanted lots more and forget to mention it. Shes now had 7
<tpbsd> rdrop-exit, I dont find our chats confrontational at all, and besides, I'm a utterly steady fellow
<tabemann> 1 was enough for me
<tpbsd> my main characteristic is ignorance
<dzho> rdrop-exit: just a big difference is all
<tpbsd> tabemann, perfectly understandable (these days)
<rdrop-exit> Our fifth didn't make it to term, which was not easy for my wife, so we stopped
<tpbsd> that would be very hard
<tpbsd> Ive been luckym, the eldest is 42 and theyre all still in good health
<tpbsd> tho a zillion close shaves
<rdrop-exit> excellent
logand` has joined #forth
<rdrop-exit> bbiab, have to walk the poor dogs on the roof because of quarantine
<tpbsd> I saved the life of my fav daughter once, she was weighed down by a huge backpack as we headed to the airport, she was bound for Thailand or some where (I can't remember) and as we crossed a green pedestrian light in Perth I saw a car coming straight thru the lights without stopping and headed right towards my daughter! I grabbed her backpack and physically threw her out of the path of the car which had just hit the skids but was still moving fast
logand has quit [Ping timeout: 250 seconds]
<tpbsd> Ive constantly reminded her of the fact that she owes me her life but she just ignores me !
<tpbsd> haha, 400 laps around the roof ?
<tpbsd> the car would have run her over for sure
<rdrop-exit> back
<rdrop-exit> here's a legal free download of the book I mentioned earlier:
<tpbsd> rdrop-exit, awesome! thanks
<tpbsd> I'll definitely be reading that
<rdrop-exit> My pleasure, although I think you already know this stuff inside-out
<tpbsd> probably not, I've never done anything but big loop stuff
<tpbsd> simple stuff
<rdrop-exit> It's an almost 20 year old book, and he uses 8051 in the examples. Parts C, F, and H are the interesting ones.
<rdrop-exit> That's where he covers schedulers.
<tabemann> back
<rdrop-exit> Time-Triggered scheduling is all about minimizing reliance on non-timer based interrupts for safety critical systems.
<tpbsd> ah cool
* tabemann got a blinker working using his new scheduler
<rdrop-exit> kudos tabemann
<rdrop-exit> tabemann, I posted a download link for the book I mentioned earlier
iyzsong has joined #forth
<tpbsd> tho one of the criticisms of the deadly Toyota Camry EMU was it's use of patting the watchdog using the systick hardware timer
<rdrop-exit> eek
<rdrop-exit> Koopman, who wrote the stack machine book, is now an expert in automotive and safety critical embedded systems
<tpbsd> and it was he who wrote that criticism
<tpbsd> it's riveting reading
<rdrop-exit> I have his "Better Embedded System Software Book"
<rdrop-exit> It has good checklists
<tabemann> I really need to get systick working
<tabemann> so I can time things off actual time rather than pause-count
<tabemann> pause-count being a counter that is incremented every time PAUSE is called
<rdrop-exit> that doesn't seem very useful
<tabemann> pause-count isn't actual time obviously, but it's sufficient for things like getting blinkies to work
<tpbsd> https://www.viva64.com/en/b/0439/ Toyota: 81 514 issues in the code
<tpbsd> tabemann, systick is the simplest of all to configure
<rdrop-exit> Lots of duplicates in those issues I assume
<tpbsd> Two engineers started the investigation. Michael Barr and Philip Koopman. It took them 20 months to review 280 000 lines of code and write a 800-page long report. Each.
<tpbsd> The address was kept in secret. The hotel room, where the engineers worked was guarded 24 hours a day - security ensured that nobody was bringing in or taking out any papers. All the phones and internet connections were disabled.
<rdrop-exit> wow
<tpbsd> thats what you want
<rdrop-exit> they used recursion in an embedded system, wow
<tpbsd> 2005 Camry L4 has >11,000 global variables
<tpbsd> No bug-tracking system !
<rdrop-exit> globals aren't necessarily a problem, memory is memory
<tabemann> okay, I'm gonna hit the sack
<tabemann> g'night guys
<tpbsd> cya
<rdrop-exit> goodnight tabemann
<rdrop-exit> the core problem seems to be "undetected Task death"
dave0 has quit [Quit: dave's not here]
<tpbsd> agree
<rdrop-exit> At Hitachi if you fucked up they'd tranfer you to Hitachi Bento, which was the company that delivered lunches to the employees.
<rdrop-exit> Back when lifetime employment was still a thing
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
iyzsong has joined #forth
logand`` has joined #forth
logand` has quit [Ping timeout: 264 seconds]
dddddd has quit [Ping timeout: 246 seconds]
gravicappa has joined #forth
deesix has quit [Ping timeout: 268 seconds]
gravicappa has quit [Remote host closed the connection]
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
iyzsong has joined #forth
mtsd has joined #forth
mtsd has quit [Quit: Leaving]
dys has joined #forth
jsoft has quit [Ping timeout: 264 seconds]
dys has quit [Ping timeout: 256 seconds]
dys has joined #forth
<tpbsd> rdrop-exit, in this article you linked https://www.excamera.com/sphinx/article-xorshift.html
<tpbsd> the author claims the picture at the end of the article "gives no obvious patterns" ? how come I see a dragon wearing a breathing mask guarding heaps of toilet paper in it then ?
<rdrop-exit> You're in Australia, you need to turn your screen upside down then it won't be an obvious pattern anymore
<tpbsd> ahh!
<tpbsd> rdrop-exit, how high is your walking roof ?
<tpbsd> not the top of a 70 floor hirise I hope ?
<rdrop-exit> 14+1 stories
<tpbsd> 15 floors! thats high enough
xek has joined #forth
<rdrop-exit> this building was built in the 80s when regulations limiting building heights were still in place, ours was the first condo building constructed in this neighborhood
<rdrop-exit> newer condo buildings are much taller
<rdrop-exit> but our contruction quality is much better than the newer buildings
<tpbsd> always important!
<tpbsd> especially when walking on the roof
<rdrop-exit> :)
mtsd has joined #forth
jsoft has joined #forth
koisoke_ has joined #forth
koisoke has quit [*.net *.split]
lonjil has quit [Quit: No Ping reply in 180 seconds.]
lonjil has joined #forth
dys has quit [Ping timeout: 250 seconds]
lonjil has quit [Client Quit]
dave0 has joined #forth
dys has joined #forth
lonjil has joined #forth
mtsd_ has joined #forth
mtsd has quit [Ping timeout: 250 seconds]
mtsd_ has quit [Ping timeout: 256 seconds]
<tpbsd> rdrop-exit, how about this stack notation ? : TIM14_PSC_PSC ( %bbbbbbbbbbbbbbbb -- x ) 0 lshift TIM14_PSC ; \ TIM14_PSC_PSC, Prescaler value
<tpbsd> rdrop-exit, your efforts did bear fruit, I was seeing the stack notation as a view *from* the stack, rather than of the stack itself
WickedShell has quit [Remote host closed the connection]
<tpbsd> rdrop-exit, Ive now dropped the "0 lshift" where the bit offset = 0
<tpbsd> \ RCC_CFGR ()
<tpbsd> : RCC_CFGR_SW ( %bb -- x ) RCC_CFGR ; \ RCC_CFGR_SW, System clock Switch
<tpbsd> : RCC_CFGR_SWS ( %bb -- x ) 2 lshift RCC_CFGR ; \ RCC_CFGR_SWS, System Clock Switch Status
<tpbsd> : RCC_CFGR_HPRE ( %bbbb -- x ) 4 lshift RCC_CFGR ; \ RCC_CFGR_HPRE, AHB prescaler
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
proteus-guy has quit [Ping timeout: 260 seconds]
dave0 has quit [Quit: dave's not here]
deesix has joined #forth
dddddd has joined #forth
reepca has quit [Ping timeout: 246 seconds]
<tabemann> hey guys
<tpbsd> hey tabemann
<tabemann> I need to dig up the docs for systick
<tpbsd> theyre in the 'programming manual'
reepca has joined #forth
<tpbsd> as the systick is a arm core component and not a STM peripheral
<tpbsd> fortunately all the arm systick registers are located at the same address and are identical
<tpbsd> same addresses
<tabemann> I found some info on ARM's "infocenter"
<tpbsd> can be hard to track down
<tpbsd> i have my older systick library here
jsoft has quit [Ping timeout: 246 seconds]
nonlinear[m] has quit [Ping timeout: 245 seconds]
nonlinear[m] has joined #forth
_whitelogger has joined #forth
gravicappa has joined #forth
dys has quit [Ping timeout: 264 seconds]
Kumool has quit [Quit: FreeZNC - Visit us! Server: chat.freenode.net Channel: ##bnc4you]
Kumool has joined #forth
rdrop-exit has quit [Quit: Lost terminal]
jsoft has joined #forth
jsoft has quit [Ping timeout: 250 seconds]
WickedShell has joined #forth
xek has quit [Ping timeout: 264 seconds]
kieselsteini has joined #forth
kieselsteini has quit [Quit: Palaver https://palaverapp.com]
tpbsd has quit [Read error: Connection reset by peer]
tp___ has joined #forth
gravicappa has quit [Ping timeout: 250 seconds]