<tp> I'm all for reinforcements
<crc> Hi tp
<tp> hey crc, how goes RETRO ?
<crc> it progresses nicely
<tp> crc, I'm still loving being able to do a 'fossil update' on you, it's a sheer pleasure!
<crc> :)
<tabemann> hey guys
<tp> hey tabemann, how goes Zeptoforth
<tp> still working on the disassembler i see
<tabemann> yep
<tp> yousaid it would take a while
<tabemann> it's long, back-breaking labor
<tp> caring loaded baskets of assembly syntax on your head ?
<tp> carrying
<tabemann> yep
<tp> I can picture it
<tp> if you imagine the vista of infinity, reaching out into time unknown .... that's how long it would take me to write one
<tp> so I'll just do doc and svd2forth plus make forth powered gear I think
<tabemann> lol
<tabemann> actually working on the disassembler is just a simple matter of programming - almost all coding and very little thought
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tp> tabemann, I looked at your elaboration of using lambdas, but I'm still confused, perhaps you could write a blinky using them if you get the time ?
<tp> tabemann, i'll be happy to assist with any hardware related issues you may run into
* tp finds not thinking while coding a perplexing conundrum
<tabemann> well it's primarily significant when one has registers with multiple fields where one wants to modify only certain fields and not others
<tp> which is what one does when blinking a led
<tp> or infact any peripheral use
<tp> it's *all* about bitfields to me
<tabemann> note that for many purposes they aren't necessary, e.g. ones where one can use bic! and bis!
<tp> I still believe that trying to work with registers and not bitfields is totally wrong for embedded, but so far I'm debating programmers that have never actually made a working blinky, ie their theories are as yet untested
<tp> tabemann, even bic! and bis! are often not needed as cortex-m has atomic single bit manipulation commands
<tp> tabemann, meaning that there is no need to read and mask before setting particular peripheral bits
<tp> tabemann, for data there are no such aids
<tp> tabemann, but thats what makes embedded different, the MCU manufacturers anticipate and design for this kind of need
<tabemann> my lambda approach is useful when one wants to set multiple bits both on and off simultaneously as a single write
<tp> and thats useful
rdrop-exit has joined #forth
<rdrop-exit> good morning forthwrights c[]
<crc> Good evening rdrop-exit
<rdrop-exit> hi crc :)
dddddd has quit [Ping timeout: 256 seconds]
<tabemann> hey rdrop-exit
<tabemann> hey crc
<rdrop-exit> hi tabemann
<tabemann> tp: that's an example of what I as talking about
<tp> tabemann, thanks!
<tp> tabemann, did you test it ? I assume it's for your L476 disco ?
<tp> hey rdrop-exit, Zen Guru of Forth!
<rdrop-exit> hi tp
<rdrop-exit> a lot of jumping through hoops in that code
<tp> rdrop-exit, I'm keeping a open mind because my mind has a lot of unused dusty space for Forth concepts
<rdrop-exit> what's wrong with
<tp> rdrop-exit, once that code is known to work I'll compare it against what I would do
<rdrop-exit> <mask> <reg> set
<rdrop-exit> <mask> <reg> clear
<tp> rdrop-exit, for a start no mask is needed
<rdrop-exit> the mask is the field
<rdrop-exit> 14 11 bits constant %tickler
<rdrop-exit> %tickler <reg> toggle
<rdrop-exit> %ticker <reg> clear
<tp> bits can be set and cleared atomically with no mask
<tp> cortex-m has special hardware just for that purpose
<rdrop-exit> you give the mask the name of the field it identifies
<tp> you may, I don't
<rdrop-exit> <value> %xreg-writable xreg %!
<rdrop-exit> (a masked store to the writable fields of xreg)
<tp> 1 2 lshift GPIOB_BSRR !
<tp> or "2 bit GPIOB_BSRR !"
<tp> done
<rdrop-exit> sure, you're overwriting an entire register, that's fine
<rdrop-exit> <value> xreg !
<tp> no I'm not
<rdrop-exit> 2 bit xreg !
<tp> you have ignored what I wrote earlier
<rdrop-exit> I see a !
<tp> so ?
<rdrop-exit> what does a ! do?
<rdrop-exit> if you're system is 32 bits a store overwrites 32 bits
<tp> the important question here is what does a "GPIOB_BSRR !" do ?
<rdrop-exit> stores 32 bits somewhere, unless you're using bit-banding
<tp> true, still fine as written
<tp> <tp> cortex-m has special hardware just for that purpose
<rdrop-exit> yes
<tp> rdrop-exit, you need to understand that GPIOB_BSRR is *special*
<tp> it's designed especially to set bits atomically, it cant even be read
<tp> youd be wasting your time trying to read it
<rdrop-exit> I'm not trying to read it
<tp> and no point using a mask, it will ignore all cleared bits
<rdrop-exit> what do you think your "2 bit" results in? it's a mask with the bit #2 set
<tp> you can understand it better by reading this doc: https://mecrisp-stellaris-folkdoc.sourceforge.io/_downloads/stm32f0x-reference_manual.pdf and searching for "BSRR"
<tp> rdrop-exit, perhaps I have a different understanding of the word 'mask' to you, that could be a cause of confusion here
<tp> to me, "2 bit" = %100
<rdrop-exit> yes
<tp> i dont see it as a 'mask' at this point in my lacklustre programming career
<tp> but Im often wrong
jsoft has joined #forth
<tp> I always understood a 'mask' to be a number used to 'filter' another number to remove undesired bits
<tp> usually by oring or anding etc
<rdrop-exit> that too
<rdrop-exit> anyway I'm not sure why you bought up, GPIOB_BSRR
<tp> what dont you understand about it ?
<rdrop-exit> why you brought it up
<tp> <rdrop-exit> sure, you're overwriting an entire register, that's fine
<tp> thats why
<rdrop-exit> yes, and your code and mine are identical in that case, as seen above
<tp> your comment indicated you didnt understand that GPIOB_BSRR is designed for this use
<tp> no, your code is abstract, there is no 'xreg' in a cortex-m
<tp> our code has nothing in common
<tp> (apart from the !)
* tp orders another bottle of Kahlua Coffee Liqueur so he can withstand rdrop-exit's programmer only viewpoint!
<rdrop-exit> wow
<tp> luckily they reduced the price but this tactic forced me to buy a 1l bottle :)
<tp> ah well, I'll do my best to cope
<rdrop-exit> maybe the kahlua will help
<tp> one can hope ...
<rdrop-exit> it can only help
* tp is out for some exercise, bbl
<rdrop-exit> have fun
<rdrop-exit> tabemann, as a rule of thumb if you're producing a combinatorial explosion of words you're not facttoring
<rdrop-exit> combinatorial explosions only show up at the lowest level, e.g. 16@ 32@ etc...
<rdrop-exit> * factoring
<rdrop-exit> bbl
rdrop-exit has quit [Quit: Lost terminal]
tp has left #forth ["I'm leaving to find peace with my inner stack !"]
jedb_ has joined #forth
jedb has quit [Ping timeout: 264 seconds]
gravicappa has joined #forth
<jsoft> Look at the usual suspects being nerds in here again :P
jedb_ is now known as jedb
WickedShell has quit [Remote host closed the connection]
dys has quit [Ping timeout: 256 seconds]
xek has quit [Ping timeout: 246 seconds]
dys has joined #forth
proteus-guy has quit [Ping timeout: 256 seconds]
proteusguy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #forth
proteusguy has joined #forth
reepca has quit [Remote host closed the connection]
reepca has joined #forth
tp has joined #forth
<tp> lol, how is this for convoluted ? I was dreaming that I was writing important Forth code, and became aware I was dreaming, so I woke up to go and write the code, but as I awoke I realised I don't have any important Forth code to write!
<DKordic> Inception?
<tp> that's an excellent film
<veltas> I have definitely experienced dreams where I get a eureka moment and wake up and realise I had been thinking something totally stupid and my regular unconscious brain halucinations had tricked me
<tp> veltas, heheh, our minds are things of wonder indeed!
proteus-guy has quit [Remote host closed the connection]
<veltas> I like watching dogs sleep and wondering what they're dreaming about
<tp> I prefer to "let sleeping dogs lay"
<tp> ;-)
proteus-guy has joined #forth
<veltas> Probably they're dreaming that they have the solution to tp's forth problem and then wake up and remember they're just a dog
<tp> hahah
proteus-dude has joined #forth
<tp> I didnt have a Forth problem :)
<tp> I may have had a XSLT problem tho
<tp> technically, it's impossible for me to have a Forth problem
<tp> because every complex Forth problem can be reduced to the most simple form and interactively tested
iyzsong has joined #forth
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
iyzsong has quit [Ping timeout: 260 seconds]
iyzsong has joined #forth
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
proteus-dude has quit [Quit: Leaving]
jpsamaroo has joined #forth
Zarutian_HTC has quit [Ping timeout: 246 seconds]
deesix_ has joined #forth
deesix has quit [Ping timeout: 272 seconds]
dddddd has joined #forth
Zarutian_HTC has joined #forth
dave0 has quit [Quit: dave's not here]
karswell has joined #forth
jsoft has quit [Ping timeout: 246 seconds]
<crest> tp: is "The Definitive Guide to the ARM® Cortex-M3" worth reading?
<crest> because my problem is that the stm32f103 is so much more capable and complex configure than the 8bit avrs i've used before
<crest> that a lot of the time i don't know which question to ask
<crest> and i don't want to fall victim to cargo cult programming
Zarutian_HTC has quit [Ping timeout: 246 seconds]
dys has quit [Ping timeout: 256 seconds]
dys has joined #forth
<crest> seven leds are too much for the ft232 3.3v regulator *cough*
<crest> with all seven active the voltage drops from 3.4v to 2.4v and the leds are noticable dimmer than with just one
<MrMobius> transistor time
<crest> even the blue pill's power led dimms
<crest> MrMobius: i did use a small npn transistors with a 1.5k ohm resistor to protect the gpio pins
<crest> but i powered the whole bread board from the usb serial converter
<crest> the usb to serial converter chip got a bit warm as well
<crest> that should at least keep the current per gpio pin to less than 2 mA
<crest> but beeing a naiv programmer i forgot that the microcontroller is not the only part with current limitation
Zarutian_HTC has joined #forth
gravicappa has quit [Ping timeout: 272 seconds]
Zarutian_HTC has quit [Ping timeout: 256 seconds]
Zarutian_HTC has joined #forth
<crest> is there a cortex m3 assembler for mecrisp stellaris?
<crest> crazy ideas ... add a sd card to one blue pill board and use can bus to provide blocks to the other boards
<crest> as long as all boards use lower addresses for requests use lower addresses than responses a simple round robin scheduler could provide fairness
<tp> crest, Ive never read it, my arm knowledge comes from building projects etc
<tp> crest, no, just a m0 one
<tp> (assembler)
<tp> crest 7 leds with high value series resistors should be ok, say 2k7 and 'high intensity' leds
<crest> just a bunch of random green leds with diffusor
<crest> they are bright enough to be easily visible in a well lit room
<crest> iirc i measured them as between 80mA and 110mA at 3.3v
<tp> thats WAY too much current
<tp> did you use a series resistor with them ?
<tp> a hi intensity led will be bright enuf to see at 5 ma
dddddd has quit [Ping timeout: 260 seconds]
<tp> but random cheap leds will be quite dim
<crest> no
<tp> crest, the *total* current allowed by *all* at once GPIOS is 80 mA and it's 20mA per gpio max
<crest> 3.3v -> led -> npn transistor -> gnd
<tp> ahh, if you add a series resistor per led your ft232 3.3v regulator will be fine
<crest> than used a 1.5k ohm resistor between 3.3v and the transistor
<tp> the gpio can drive a led with 1k5 resistor directly, no problem
<crest> but how many leds can i connect per gpio port?
<tp> you only need a transistor and external psu if you exceed the GPIO ratings or 500mA total from the ft232 3.3v regulator
<tp> how many leds directly = 80mA/each led on current
<tp> say 8 leds on at once = 10mA each
<tp> measure the voltage across a led with the 1.5k resistor in series and use that to calculate
<crest> the only resistor values i have right now are 150 and 1.5k ohm
<crest> with 150ohm they are barely visible
<tp> generally led on voltage is about 2.5 volts
<tp> well 150 ohm will have to do
<crest> let me put a second one in parallel
<tp> measure the current thru the led, thats the critical factor
<tp> 9,000mcd brightness
<tp> Standard size - T1 3/4 5mm
<tp> 2.4V forward drop
<tp> Max current 20mA
<tp> thats similar to what i use, they are easy to see with almost no current
<crest> looks like some idiot blew the fuse in the multimeter *sigh*
<tp> Id buy 30 of those leds and throw away all the old ones
<tp> heheh, thats what the fuse is for
<crest> it doesn't work in current measurement mode (led stays dark)
<tp> oops
<tp> well calculate it then ?
<tp> 3.3 - 2.7 / 150
<tp> thats about what the led will use as green has a higher voltage per led
<crest> i just switched to the unfused 10A connector
<tp> unfused!
<tp> oh man
<crest> the power supply (ftdi 232) is rated for less than 200mA
<tp> that will make a big bang oneday if you ever decide to see how many amps are inside the mains power
<tp> ahh yes, it's only a serial dongle
<crest> i wouldn't try that with lead acid batteries
<crest> they're great for spot welding connectors :-P
<tp> thats all I use to power the bluepill projects i feature on my site
<crest> according to my multimeter the led draws 1.1mA when attached to the 3.3v without any series resistor
<crest> which is a lot more reasonable but i no longer trust the multimeter
<crest> after all i'm going through the unfused (up to 10A) connector
<crest> i could measure the current through some known resistor to double check
<tp> that reading is definitely wrong
<crest> it has to be. the power led on the blue bill gets noticeably darker
<tp> because it's exceeding 200mA
<tp> the regulator folds back at 200mA being current limited
<tp> and then it starts to heat up, obviously it has good heat sinking on the board
<crest> .oO( beware of programmers with soldering irons )
<tp> whats your clock speed on the bluepill ?
<tp> crest, but ya gotta deal with a soldering iron in embedded sooner or later
<crest> probably 8mhz unless the default stm32f103-ra image configures the PLL
<crest> i'm supprised it didn't crash as well
<crest> given that the voltage dropped to at by about one volt
<tp> the stm32's are really quite amazing
<tp> the default is the internal 8MHz internal RC oscillator
<crest> is the internal rc oscillator is good enough for a reliable serial connection at 115200 baud?
<tp> easily
<tp> the f103 mcu will run at 2.0 v
<tp> and internally it's running at 1.8v via a internal LDO regulator
<crest> (3.3 - 2.7) / 150 = .004
<tp> yeah, 4mA
<tp> a hi intensity led will be seen across the room at that level, a cheap/old led, not so much
<crest> there is some diffuser on the leds
<crest> which probably eats most of the light output
<tp> the efficiency of the led is the problem
<crest> they just emit a dim green glow
<tp> your leds are like a car that goes 20kph max and uses 100l of fuel per km
<crest> sure but they're good enough to test the gpio port
<tp> heheh, yeah with a series resistor and dim the lights :)
<crest> i'm to lazy to remove the transitors
<tp> dosnt matter
<crest> with two 150 ohm resistors in parallel its bright enough that i don't have to dim the lights
<tp> all you need is that 150R or perhaps 2 in parallel
<tp> so thats 8mA per led
<crest> 26mW per led
<tp> and as you have 1.5K resistors into the bases of the transistors, (BJT's ?) then thats only 1.7mA per GPIO
<crest> BC337
<tp> but the 1500 R led is too low, it should be at least 10k
<tp> 1.7mA is massive for the base-emitter current of a BC337
<tp> but it will all work ok
<crest> the only other value i had available was 10k ohm and that dimmed the leds noticeable