* tabemann
should port zeptoforth to the numworks calc but for some reason is reluctant to do so
<tp>
why ?
<tabemann>
probably mostly because of A) having to figure out the damn memory controller B) either make significant changes to zeptoforth to support three memory spaces or otherwise leave onboard memory to just the kernel alone
<tp>
a lot of work involved ?
<tp>
ah yes, I recall now
<tp>
it's a real world challenge
dave0 has quit [Quit: dave's not here]
<tp>
I'm surprised the on board mcu has so little memory
<tp>
I mean, my stm32f051 has 64kb onboard
<tabemann>
that's probably because the numworks people decided to put everything in the external flash
<MrMobius>
is it parallel flash or XIP type stuff?
<tabemann>
I'd have to look it up
<tabemann>
okay, time for dinner
<tabemann>
bbl
<tp>
MrMobius, serial flash I believe
<MrMobius>
hmm
<tp>
MrMobius, the MCU in that calculator maps serial flash to internal address space
<MrMobius>
some of them can fetch code from serial at run time so it runs code from serial transparently
<tp>
MrMobius, so once the serial flash type is configured, it's just like internal flash
<MrMobius>
but maybe it loads from flash into ram before running anything
<MrMobius>
neato. it might be the first thing then
<tp>
maybe, but as with all things cortex-m, the register options are vast
<tp>
and tabemann in porting all that has to find ot which is which
<tp>
MrMobius, I'm not sure how the mcu can autofind serial flash from all the available options to load by itself, Ive looked thru the register concerned and it appears to need configuration
<MrMobius>
tp, I dont mean it detects it automatically. I mean it can be configured to execute code stored in serial memory
<tp>
MrMobius, ahh, ok, thats definitely the case
<MrMobius>
which is relatively new. before that it was either executing from parallel memory or loading from flash to ram before executing
<tp>
MrMobius, absolutely
<tp>
I was intruiged to find the option myself, this stuff advances faster than I can keep up
<tp>
MrMobius, yet ... in one of the Chinese STM32F103 clones, the GD32F103 ( or the CS32F103) they actually glue a 128KB flash on top of their clone die, and it loads into ram at bootup, making for a cheaper chip, faster clock, but slower boot up
<MrMobius>
I wonder what the speed trade off is too
<tp>
the mcu can then run at full clock speed instead of flash wait states
<tp>
bit takes about 130ms to start
<MrMobius>
Im only really into electronics and programming for calculator stuff but lost interest in the numworks thing pretty quickly. I imagine running from serial flash might be quite a bottleneck on top of everything being in Java iirc
<tp>
compared for a couple of Mecrisp-Stellaris with the non clone
<tp>
well tabemann is planning to run his Forth on it
<MrMobius>
heh, so that chinese clone has as much ram as a legit chip has just for flash?
<tp>
but yeah, serial flash has to be slower
<tp>
correct
<tp>
they even ficed a long standing STM32F103 issue, namely reading the DBG register
<tp>
fixed
<MrMobius>
bizarre
<MrMobius>
doesnt sram use a lot more power than flash?
<tp>
whats odd is that they made the clone and printed stm32f103 on it so as to make a quick buck. If they had marketed it under its proper designation as a separate product they would have had to wait longer for market acceptance but could have sold millions ?
<tp>
frankly I dont know, Ive never looked ito it
<tp>
but now no one trusts the Chinese when it comes to clones
<tp>
in the meantime STM innovates with their serial flash to program memory mapping facility
<MrMobius>
why would they have made millions? I think they would have had to license the ARM core at the very least
<tp>
MrMobius, compared to the 1 bit calculators of old, perhaps serial flash on a 200mhz calculator isnt so bad ?
jedb has joined #forth
<tp>
I dont believe they licensed anything
<tp>
their STM32f103 clone is totally different silicon
<tp>
china doesnt need tp license anything, their law is different
<tabemann>
back
<tp>
MrMobius, maybe they did license the arm core, who knows ? perhaps it's the peripherls they redesigned
<MrMobius>
tp, kind of. they flout international agreements on copyright stuff so its not just that they have different domestic laws
<MrMobius>
hehe, ya compared to a 1 bit ALU but not compared to the 500mhz+ monster HP is selling now
<tabemann>
do you need to license the core when you implement your own from scratch, with completely different silicon and merely binary compatibility?
<tp>
lol, embedded mcus are now in the 1Ghz territory, the Atmel SAM stuff
<tp>
they are serious fast
<tp>
but the MCu in the Numworks ? it draws 300mA at full speed
<tabemann>
but what do you lose in power consumption?
<tp>
and 30mA in low power!
<tabemann>
is that the chip or the screen?
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tp>
thats the MCU
<tp>
they must stop it between keypreses or something
<tp>
it's power hungry compared to my stm3f051 which runs on 3ma at 8mhz
<tabemann>
at least on the l476 and the f407 sleep mode is pretty trivial to use, so I don't see why they wouldn't use it
<tabemann>
hell, I normally put the MCU to sleep between keypresses, and my code is pretty simple
dys has quit [Ping timeout: 260 seconds]
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
<tp>
tabemann, sleep means 30mA in the case of the Numworks
<tp>
thats 10x more than my stm32f103 in run mode at 8mhz
<tp>
and I get 3uA in sleep
<tp>
tabemann, sleep is always trivial, deepsleep, and other modes are far from trivial
<tabemann>
that is true
<tp>
my embedded programmer friend spent 3 months getting a STMLxx down to nA on his profuct
<tp>
he's awesome and said it nearly drove him mad
<tp>
he makes a hand held IR camera
<tp>
sells it to power companies
<MrMobius>
does it have external sram?
<MrMobius>
numworks i mean
<tp>
of course those power levels involve more than the STM power settings, but how he did it is a secret known only to him
<tabemann>
IIRC the numworks calculator has onboard SRAM
<tabemann>
so to install software on the numworks calculator I'd have to write the kernel onto the device, and compile a simple seconary bootloader into RAM (or have it prewritten into the kernel), then use that to load the rest of the code into external flash
<tp>
hmm
<tp>
no
<tp>
I think you could write a bootprogram that simply sets up the serial flash then runs your Forth ?
<tp>
or if you want it to be easy, load Mecrisp-Stellaris onto the numworks which on powerup configures for the serial flash and boots your forth ?
<tp>
Mecrisp-Stellaris only takes 20kb of flash on the mcu
<tabemann>
back
<tabemann>
I don't think bringing in Mecrisp-Stellaris is necessary
<tabemann>
after all Mecrisp-Stellaris doesn't include code for configuring the external flash anyways
<tp>
what ??
<tp>
youre kidding ?
<tp>
Mecrisp-Stellaris is the total answer
<tabemann>
Mecrisp-Stellaris's numworks support is for the older version of Numworks
<tabemann>
which has 1 meg of on-chip flash
<tp>
oh, thats a problem
<tp>
yeah but Mecrisp-Stellaris only needs 20KB
<tabemann>
what I need is this
<tp>
if you think writing and testing assembly on the numworks is easier than Mecrisp-Stellaris, I think youre in for a learning experience and a half :)
<tabemann>
A) I need code for configuring the external flash, in the kernel
<tabemann>
B) I need code for supporting the USART, in the kernel
<tp>
no, yu only need to configure the relevant mcu register
<tp>
b) maybe
<tp>
supporting the external serial flash is a mcu config, nothing more
<tabemann>
C) I need a secondary bootloader of sorts to read a binary for the external flash, in ihex format, over serial
<tabemann>
that's what I mean by having to configure it
<tp>
C) no the external flash gets mapped to the mcu internal memory space
<tp>
after that it's indistinguishable from normal flash
<tabemann>
tp: the problem is that it's not mapped at bootup time
<tabemann>
so I need to get zeptoforth running first before I can load code into external flash
<tabemann>
and I can't use dfu for it, as dfu won't see the external flash
<tp>
i discussed that above
<tp>
tabemann, you have zeptoforth coloured glasses on :)
<tabemann>
using mecrisp-stellaris will only complicate things
<tabemann>
it's simple
<tabemann>
1. bootup
<tabemann>
2. configure external flash
<tabemann>
3. configure serial
<tabemann>
well, 1.5: configure the clock
<tabemann>
4: load ihex over serial to load info external flash
<tp>
cool
<tabemann>
(4 is probably best achieved by loading and compiling a program in RAM which does this and then having that load the code info external flash)
<tp>
be interesting to hear your progress
<tabemann>
I need to buy a damn female USB 2.0 A breakout board again
<tabemann>
because the one I bought never arrived and instead got sent back to amazon for some reason
<tp>
darn!
<MrMobius>
tabemann, is there no support for running a program once numworks boots?
<tabemann>
what do you mean?
<tabemann>
do you mean loading a program that will be executed by numworks?
<tabemann>
all external code has to be either A) compiled into numworks itself or B) run as microPython code
<MrMobius>
gross
<MrMobius>
like on a TI calculator from the mid 90s you could download a chunk of asm and just run it from the OS
<tabemann>
I've tried running microPython code on the calculator for the hell of it, and it's slow
<MrMobius>
heh I bet
<tp>
oh yeah upython is 300x slower than Mecrisp-Stellaris on the same device in my tesys
<tp>
tests
<MrMobius>
a chunk of binary data I should say. I think the z80 based ones called this an "asm" type object
<tp>
MrMobius, the numworks is just a flashy oss calculator, it wasnt meant to do anything else as std
<tabemann>
well one of the assumptions of numworks is that one can load external code - you just have to compile it into the kernel
<tabemann>
which you do have access to the source code of
<tp>
tabemann, we call that 'reflashing new fw'
<tp>
:)
<MrMobius>
I guess you totally reflash it every time you want to test your program
<tabemann>
albeit it's not free because it does have a non-commercial license clause
<tabemann>
wait a second
<tp>
MrMobius, thats right
<tabemann>
how does flashing work if you only have access to 64K of flash
<tabemann>
so the flashing code must know about the external flash
<tp>
tabemann, same as usual
<MrMobius>
most of the latest calculators are locked down too which is why I stopped buying them after the HP 50G
<MrMobius>
I just wouldnt own one you cant run native code on
<tp>
I'm happy to just use my TI34 as a caLculator
<tp>
still works perfectly since I bought it in the 1980's
<tp>
solar powered
<MrMobius>
tabemann, could you modify the OS just enough to load your Forth code?
<MrMobius>
so you dont have to reflash everything every time
<tabemann>
modify the OS - lol
<tabemann>
from the impression I get, zeptoforth is far, far lighter-weight than the numworks OS
<tabemann>
well the zeptoforth kernel at least
<tabemann>
it's just a matter of me having to figure out how to configure this damn memory controller
<tabemann>
and writing an itsy bitsy program to load into RAM to write code in ihex format into external flash
<tabemann>
or
<tabemann>
just compile the code as source into external flash
<MrMobius>
so you just have forth rather than switching in and out?
<tabemann>
yes
<MrMobius>
I hope you have a good floating point package :)
<tabemann>
zeptoforth doesn't have floating point, but I intend to add fixed point
jsoft has joined #forth
tp has left #forth ["I'm leaving to find peace with my inner stack !"]
_whitelogger has joined #forth
mtsd has joined #forth
gravicappa has joined #forth
dddddd has quit [Ping timeout: 260 seconds]
xek has joined #forth
jsoft has quit [Ping timeout: 240 seconds]
iyzsong has joined #forth
WickedShell has quit [Remote host closed the connection]