Zarutian_HTC has quit [Remote host closed the connection]
Zarutian_HTC has joined #forth
pierpal has joined #forth
pierpal has quit [Read error: Connection reset by peer]
Zarutian_HTC| has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
pierpal has joined #forth
pierpal has quit [Ping timeout: 258 seconds]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
pierpal has joined #forth
pierpal has quit [Ping timeout: 260 seconds]
pierpal has joined #forth
pierpal has quit [Ping timeout: 240 seconds]
pierpal has joined #forth
dave0 has quit [Quit: dave's not here]
pierpal has quit [Ping timeout: 256 seconds]
<tabemann> hey guys
<tp> hey tabemann
pierpal has joined #forth
<tabemann> been working on converting the mecrisp-stellaris numworks code to work with zeptoforth
<tp> that sounds interesting
<tp> are you able to flash the calculator yet ?
<tp> or still waiting for a different connector ?
<tabemann> still waiting for the connector
<tabemann> the issue is that I cannot flash it but rather that I cannot hook up serial
<tabemann> and because I can't hook up serial I cannot download code into it for zeptoforth to compile
<tp> so you can flash but dont have a terminal ?
<tabemann> yeah
pierpal has quit [Ping timeout: 260 seconds]
<tp> did you see Crests work with a terminal on SWD ?
<tabemann> yeah
<tabemann> but I don't think I have access to SWD, just DFU over a USB connection
<tp> aha
<tp> aha, all thru the same usb connector
<tp> DFU works fine, I use it with RISC-V
<tabemann> the serial isn't through USB
<tp> it's thru the usb connector tho
<tabemann> it's that mecrisp-stellaris and zeptoforth can take over two different USB pins and turn them into a serial line
<tp> very handy, serial or usb bepending on whats running
<tp> -b+d
<tabemann> but they need to be fed into a serial-to-USB dongle
<tp> sure, it's all up to the config
<tabemann> which is why I need my female USB A 2.0 breakout board
<tabemann> so I can extract -D and +D
<tabemann> and feed them into the USB dongle
<tp> hmm, i wonder if that's also possible with the stm32f103 for the blue pill boards
<tabemann> one of them is RX the other is TX, I always forget which
<tp> i guess it's easier to leave the blue pill as is
<tp> it's a very versatile microprocessor world we now live in
<tabemann> well the numworks have a Cortex-M7 whereas the blue pill as an M3...
<tp> sure
<tabemann> the thing is that the STM32F7 used by the numworks seemed awfully similar to the STM32F4 used by the board I have
<tp> theyre all similar
<tp> in some way or another
<tabemann> porting zeptoforth itself required almost no changes
<tabemann> probably the only things that changed were the USART interface
<tabemann> particularly because I'd be using USART6 rather than USART2
<tp> thats common
<tp> sadly STM put the usb D- and D- signals with a usart control signals
<tp> and fixed that later in the F7
<tp> (and maybe others)
<tp> another reason to avoid the old F103
<tp> even if it is 3 - 5 times faster than my F051 at the same clock speed
<tp> i can help with your moving USART2 to USART6 if you need it
<tabemann> nah, already did it
<tp> cool
<tabemann> actually, there is a problem I just realized that will need solving
<tabemann> dfu-util only flashes space that it needs to load an image
<tp> yeah
<tabemann> but zeptoforth assumes that everything above its code is flashed
<tp> but it also can erase a larger space
<tabemann> i.e. it relies on a full erase cycle
<tp> dfu-util -a 0 -d 0483:df11 -s 0x8000000:mass-erase:force -D mecrisp-stellaris-stm32l433.bin -t 1024
<tabemann> cool
<tabemann> wait a second - does the numworks board rely on an eraseable bootloader that could result in bricking if erased?
<tp> no, the stm32 bootloader cant be erased
<tp> it's in rom somewhere
<tabemann> I always wonder how those bootloaders can function without having to specifically allocate room for them
<tabemann> is there hidden ROM and RAM that is not in the standard memory space used by applications?
<tp> theyre in a read only part of the memory
<tp> sure
<tp> and not declared in the tech data afaik
<tp> but one can get the ST 'rom' dumps apparently
<tabemann> I always love undocumented stuff
<tp> they must have a bit of code as there is the DFU, the Serial bootloader that works not only with Usarts but I2c etc
<tp> well the actual functionality is well documented
<tp> the dfu and serial bootloaders are well documented as regards how to use them
<tabemann> yeah
<tp> theyre not all that trivial either
<tabemann> my biggest question is how do interrupt vectors work
<tp> there simple from mpov
<tabemann> because code installed at $00000000 have their interrupt vectors at the bottom of memory
<tp> ??
<tabemann> so for some hidden firmware to work, they'd have to have their own vectors somewhere lse
<tabemann> *else
<tabemann> and then only pass on control to the normal vectors at the bottom of memory
<tp> ahh i see
<tp> you know how the user interrupts are configured ?
<tabemann> so let's say the real reset vector isn't at $00000004 but rather at, say, $F0000004
<tp> thats all very straightforward
<tabemann> I know the normal way user interrupts are configured, I'm not familiar with moving the vectors around
<tp> why are you concerned with the factory rom firmware ?
<tp> moving them is easy
<tabemann> I'm just curious
<tp> I guess youd have to get a copy of the STM ROM dump
<tp> does Zeptoforth support interrupts yet ?
<tabemann> yep
<tp> ah cool
<tp> I havent got that far
<tabemann> you have to code everything for them
<tabemann> but it does use interrupts for serial IO
<tabemann> not in the kernel out of the box
<tp> ah yes, I remember now
<tabemann> but rather in the "full" binaries
<tp> i saw this earlier today
<tabemann> it also uses the systick (again, not out of the box but in the "full" binaries)
<tp> re STM baud rate detection
<tp> baud rate detection algo:
<tp> activate IWDG watchdog
<tp> wait until RxD=1 - this is idle state
<tp> wait until RxD=0 - this is leading edge of start bit
<tp> wait until RxD=1 - this is leading edge of bit 0 of 0x7F sync byte
<tp> start timer
<tp> wait until RxD=0 - this is trailing edge of bit 6 of 0x7F
<tp> get elapsed time - this is duration of 7 '1' bits of 0x7F
<tp> set UART bit period = time / 7
<tp> So:
<tp> baudrate detection itself can’t hang (IWDG will reset the CPU)
<tp> the sync byte is not checked to be 0x7F, any trash containing 1010 sequence will be accepted
<tp> after detection the algo proceeds to RxByte functions kicking the IWDG endlessly until something is received
<tp> but I dont use autobaud because it has to be set up after every mcu reset
<tp> and I do a zillion resets during dev
<tabemann> I personally don't see why I would bother
reepca has quit [Remote host closed the connection]
<tabemann> it's better just to note that one needs to select a certain baud and live with that
<tp> yeah, agree
reepca has joined #forth
<tabemann> one thing that annoys me about converting code from mecrisp-stellaris to zeptoforth is VARIABLE
<tabemann> mecrisp-stellaris's VARIABLE takes an initialization value
<tabemann> zeptoforth leaves VARIABLEs uninitialized
<tabemann> in part because they can be allocated while compiling code for flash despite the fact that they are really being allocated in RAM
<tabemann> so I'd need to figure out someplace to put them to store the initialization values
<tp> or just change yours ?
<tabemann> and I figured that it is easier to just require the user to initialize them from the init word
<tabemann> tp: all the ways I can imagine doing it seem overly complicated
<tabemann> like compiling an init word that calls the previous init word for each VARIABLE - which'd be inefficient space-wise
<tp> but Mecrisp-Stellaris VARIABLE just takes a parameter in addition to yours ?
<tp> it's done with <builds does> or similar if I understand that correctly
<tabemann> Mecrisp-Stellaris must be doing some magic I am not aware of
<tabemann> Mecrisp-Stellaris's and zeptoforth's <builds does> are equivaelnt
<tabemann> zeptoforth also has a CREATE which is equivalent to <BUILDS DOES> except it is more efficient space-wise
<tp> I recall reading how some VARIABLE are uninitialised in forths like yours and initialised in others
<tabemann> whereas Mecrisp-Stellaris has deprecated CREATE
<tabemann> implementing an initialized VARIABLE when compiling to RAM is trivial
<tp> ahh
<tabemann> where it gets tricky is when defining VARIABLEs while compiling to flash
<tabemann> I had to do some magic to get VARIABLEs to work while compiling to flash in the first place
<tp> thats Forth implementer black magic
<tp> technicians dont go there
<tabemann> hint - if you forget to call init from within an outer init word, it all breaks
<tp> it's the same with Mecrisp-Stellaris
<tabemann> I bet Mecrisp-Stellaris just generates hidden init words to do all this
<tp> I'm speaking about the user 'init' word
<tabemann> yeah
<tp> the turnkey user word
<tp> thats the only one I know about
<tabemann> okay, I should get to bed - kinda falling asleep here
<tp> night!
<tabemann> g'night
dddddd has quit [Ping timeout: 258 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
jsoft has quit [Remote host closed the connection]
rdrop-exit has quit [Quit: Lost terminal]
dys has joined #forth
ryke has quit [Remote host closed the connection]
ryke has joined #forth
pierpal has joined #forth
gravicappa has joined #forth
ryke has quit [Ping timeout: 260 seconds]
xek_ has joined #forth
mtsd has joined #forth
xek_ is now known as xek
xek_ has joined #forth
xek has quit [Read error: Connection reset by peer]
jsoft has joined #forth
reepca has quit [Remote host closed the connection]
reepca has joined #forth
mtsd has quit [Quit: Leaving]
xek has joined #forth
xek_ has quit [Ping timeout: 256 seconds]
WickedShell has quit [Remote host closed the connection]
TCZ has joined #forth
pierpal has quit [Remote host closed the connection]
reepca has quit [Ping timeout: 246 seconds]
jsoft has quit [Ping timeout: 256 seconds]
reepca has joined #forth
dddddd has joined #forth
jedb has joined #forth
TCZ has quit [Quit: Leaving]
gravicappa has quit [Ping timeout: 258 seconds]
gravicappa has joined #forth
xek_ has joined #forth
xek has quit [Ping timeout: 265 seconds]
ryke has joined #forth
TCZ has joined #forth
ryke has quit [Ping timeout: 258 seconds]
Zarutian_HTC| has quit [Ping timeout: 272 seconds]
jedb has quit [Remote host closed the connection]
jedb has joined #forth
holmak has joined #forth
<proteusguy> What would be the term for something that is effectively a commodity in all ways except for one parameter? Like something precisely like another except for their serial number? Any short term to express that quality?
<jackdaniel> maybe an instance?
<proteusguy> jackdaniel, not wrong but doesn't express what I'm trying to say.
<proteusguy> Another property is that they are sequential.
<boru> Element (of a series), or item, perhaps?
<jackdaniel> or "version"
<jackdaniel> but it sounds odd
<boru> Difficult to say, without more context.
kamid has quit [Ping timeout: 265 seconds]
kamid has joined #forth
jedb has quit [Ping timeout: 260 seconds]
TCZ has quit [Quit: Leaving]
cantstanya has quit [Write error: Broken pipe]
xek__ has joined #forth
xek_ has quit [Ping timeout: 258 seconds]
xek__ has quit [Ping timeout: 240 seconds]
<proteusguy> ended up with "sequentially ordered goods"... not my best work. haha
<boru> Hmm. Sequentially ordered units, perhaps?
cantstanya has joined #forth
WickedShell has joined #forth
dys has quit [Ping timeout: 260 seconds]
holmak has quit [Remote host closed the connection]
Zarutian_HTC has joined #forth
dys has joined #forth
dys has quit [Ping timeout: 265 seconds]
Zarutian_HTC has quit [Ping timeout: 272 seconds]
ryke has joined #forth
kamid has quit [Ping timeout: 272 seconds]
Zarutian_HTC has joined #forth
Zarutian_HTC has joined #forth
boru has quit [Read error: Connection reset by peer]
boru has joined #forth
ryke has quit [Ping timeout: 246 seconds]
dave0 has joined #forth
gravicappa has quit [Ping timeout: 272 seconds]
ryke has joined #forth
remexre has quit [Ping timeout: 246 seconds]