<tabemann>
I got the second part of the test framework for zeptoforth implemented
<tp>
tabemann, great, I've almost finished by bit@ test doc page
<tabemann>
cool
<tp>
check out this lovely embedded c code
<tp>
#include "SmartcontrolOS.h"
<tp>
#include "Apps.h"
<tp>
#include "CMSIS.h"
<tp>
DO__write_open_drain(_,PA4,1);
<tp>
DO__write_open_drain(_,PA4,0);
<tp>
Scheduler__wait(_,10*ms);
<tp>
Scheduler__wait(_,40*us);
<tp>
DO__write_open_drain(_,PA4,1);
<tp>
DI__read(_,PA4);
<tabemann>
oh my
<tabemann>
wait, where's the function definition?
<tp>
and people think embedded C is straightforward, easy to read ?
<tabemann>
I just see #include and then code, no foo (void) {
<tp>
there is more, this is just the first bit
<tp>
but it's all the includes ... and is a first time C user
<tp>
using CodeBlocks ... opps NOT a first time C user
<tp>
I see this stuff everywhere I look, the state of C embedded is a mess in the hobby community
<tabemann>
well coding zeptoforth to do the same thing is non-trivial either; you have to essentially have the CMSIS or equivalent available, and need to have access to the proper datasheet to know how to use said registers
<tp>
tabemann, that may change after I add RTS handshaking :)
<tabemann>
:D
<tp>
which I start soon as the bit@ page is nearly done
crest has joined #forth
<tp>
onve I have RTS I can make a binary which includes all the memory maps, and also include a bitfield template in the release tarball
<tp>
tabemann, after that, it's quite easy to do hardware config
<tp>
tabemann, youre a Emacs user iirc, I'm assuming you can easily paste lines from open buffers into a source file ?
<tabemann>
yes
<tabemann>
because I imagine that the full CMSIS will be quite large
<tp>
tabemann, for instance, my project manager opens a number of files, including the memmap.fs and the bitfield.fs for the MCU I'm using in the project
<tp>
this means it's dead easy to then add hardware config as bitfields.fs contains a hardware summary of every bitfield
<tp>
tabemann, the full CMSIS-SVD for the F4 is large, but I transform it into the memmap.fs and bitfields.fs files
<tp>
theyre transformed into Forth words etc
<tp>
in the same way that the C compiler makers use CMSIS-SVD to make their header and include files
<tp>
as do the RUST people
<tabemann>
I figured as much
<tp>
it makes sense, and makes it easy
<tp>
some people dont like CMSIS-SVD but I think it's fantastic. I wouldnt be using Forth in embedded without it
<tp>
the tyrany of bitfields makes forth simply utterly impossible to use otherwise
<tabemann>
well in the code I've copied from Mecrisp-Stellaris, in many places they just use hardcoded values to represent multiple bits that are set or unset
<tp>
Forth is fine for say a 6502 with 10 registers or so, but for a cortex-m4 with 722 registers ... forget it
<tp>
oops, thats for a M3 !
<tp>
lol, the old stm32f103
<tp>
tabemann, yeah, the assembly in Mecrisp-Stellaris is particulary hard to grok because matthias uses his own syntax as he makes it up on the fly
<tp>
it's always *partially* correct, but almost never fully correct
<tp>
for instance, a complete, non ambiguous CMSIS-SVD name is very long and programmers just have an adversion to them
<tabemann>
I highly suspect my code is the same
<tp>
everyone is the same, except me
<tp>
I noticed early on that there are name clashes in the STM32 CMSIS-SVD xml files
<tabemann>
and?
<tp>
except where the complete 'peripheral_register_bitfield" nomenclature is used
<tp>
well, name clashes mean probable bugs later on
<tp>
it's probably not fair to be too hard hon STMicro as some of their micros have over 17,000 bitfields
<tp>
thats a lot of names to invent and maintain
<rdrop-exit>
"I reminded myself a little bit of how people write C code [...]
<rdrop-exit>
There were a lot of programmable options that they had to test for. There were a lot of bits you might want to set or not set in a control word. And they had long names for those bits and they would smush them together and put them in a control word. I don't do things that way. To me it's an oxymoron. Those long names don't mean anything to me. I had to find a place in the documentation to find out what
<rdrop-exit>
that long name meant, what the consequences of setting it or not setting it in order to understand what was going on.
<rdrop-exit>
Now having gone to all that work I can just set that bit in a hex word. I don't need the names and the conditions. I only have to do it once in one context." -- Chuck Moore
<rdrop-exit>
good morning Forthies c[] :)
<tabemann>
hey rdrop-exit
<tp>
g'day rdrop-exit
<tabemann>
to me it's easier to remember what you were doing after the fact with a name rather than just remember what some random hex meant later on
<tabemann>
like in the code I borrowed from Mecrisp-Stellaris that just specifies random hex - wtf does that all mean?
<tp>
tabemann, exactly
<tabemann>
whereas if it were with CMSIS labels, I could always look them up in the data sheet
<rdrop-exit>
sure, I'm sure chuck names and documents the word were he specifies that hex value
<tp>
tabemann, same here. Embedded code written by programmers is usually impossible to understand
<rdrop-exit>
he's just not making a name for each possible hex value
<tp>
sure the Forth code is easy to understand as youd expect, but there is no way to understand what it does without spending a lot of time reading the data sheets
<rdrop-exit>
he's setting the hex value to suit his requirements within a particular context
<tp>
and doing that on a bitfield by bitfield basis is massively time consuning
<tp>
and lets remember, chicks code was in the early days when MCU's had no peripherals on board
<tp>
Chuck
<rdrop-exit>
for that he finds the "smushed names" that C programmers use next to useless, since he has to go back to the docs anyway to figure what it all means and what the subtle implications are, that seems especially applicable with todays chips
<tabemann>
that's why we should be using full names
<tp>
oh yeah, C progrmmers are terrible in that regard
<tabemann>
I hate C code examples for embedded code
<tabemann>
like I remember trying to look up how to enable some interrupt
<tp>
tabemann, I agree, of course thats in the early config stage when the full and correct hardware naming is critical. Later all that stuff becomes 'on fill wash drain spin off" etc and who cares
<rdrop-exit>
yes, Chuck is certainly allergic to such C programmer ways and doesn't use them with Forth
<tp>
tabemann, yeah, it's incredibly frustrating
<tabemann>
and all the examples I found just pointed you at some random library
<tp>
hence my C rants
<tabemann>
and I wanted to know which exact registers to set
<tabemann>
not to use library foo.c
<crest>
tp: have you ever implemented auto baudrate detection for stm32?
<tp>
sadly there are very few Forth examples for cortex-m except in the Mecrisp-Stellaris user contributions and prior to svd2forth they all had to make up their own naming
<tp>
crest, yes
<tp>
tabemann, I was *gobsmacked* recently when I looked at a new user contribution, he used the full cmsis-svd naming as provided by svd2forth!
<crest>
even for chips without hardware support for it?
<tabemann>
to get anything done with Cortex-M peripherals I found myself having to constantly go back to the datasheet
<tp>
tabemann, so it is happening slowly
<tabemann>
cool
<tp>
tabemann, thats right, it's either svd2forth or the datasheet, and when learning the datasheet is inevitable anyway
<crest>
.oO( tab completion in mecrisp would be really nice to have )
<tp>
crest, no, I only use the stmn32f051 so the autobaud rate was with that
<crest>
an other reason to pick the "right" chip
<tp>
crest, of course, the bluepill board using the ancient stm32f103 has no autobaud. This comes from being a 14 year old design
<tabemann>
I've implemented tab completion in other Forths of mine, but I have deliberately left it out of zeptoforth because I expect someone will be using something like e4thcom which won't permit it anyways
<tp>
i find autobaud a waste of time for development
<tabemann>
I haven't bothered with autobaud with zeptoforth
<crest>
i wanted to write a word to change the clock rate without locking myself out and usb<->serial adapter are often limited to a few baud rates
<tp>
crest, tab completion in Mecrisp-Stellaris would take up too much rom, matthias wouldnt allow it
<crest>
shouldn't be too bad unless you want to convert the dictionary to a prefix tree
<crest>
but it would require some sort of line double buffering
<tp>
crest, I think all that could be done in a IDE outside the mcu anyway
<crest>
i want it for interactive use as well
<crest>
but a proper ide should do more than just tab completion
<tabemann>
to me at least I wouldn't implement autocomplete except with a full line editor.... but a full line editor would be way too big and complex to implement
<tp>
frankly I know all the Forth words so well I dont need completion, which I have in my editor and dont use
<rdrop-exit>
I've never cared for auto-complete
<tp>
I use open buffer full line paste all the time tho
<crest>
i really have to look into vim completion support
<crest>
tp: i have an other idea i want to run past you
<tp>
the reason is that lines like this are too big to type or remember ": USART1_ISR_BUSY? ( -- 1|0 ) 16 bit USART1_ISR bit@ ; \ USART1_ISR_BUSY, Busy flag"
<tabemann>
now that I think of it, what I could implement is a lookup word, that essentially does completion to look up words, but without involving a line editor
<crest>
how do you think about some words to implement word sized bit fields as pair of value and mask?
<rdrop-exit>
that's how it's typically done
<rdrop-exit>
especially with a peephole optimizing Forth that can eliminate needles shifts
<tp>
crest, sounds ok to me
<rdrop-exit>
bitfield ( x mask -- bits )
<rdrop-exit>
bitfield Extract a bitfield.
<rdrop-exit>
an |and| followed by a right shift (if needed).
<rdrop-exit>
When <mask> is a literal |bitfield| optimizes down to
<tp>
crest, can I use your recent C "ok-waiter" file uploader app as a example for picocom in my online doc ?
<tp>
I have another to add to it written in python
<crest>
sure but it requires a small change to mecrisp that i haven't documented yet
<crest>
i piggy backed on the color support
<tp>
oh ? I havent had a chance to try it yet
<tp>
crest, and why not ? :)
<crest>
because i wrote it between 1am to 3am local time?
<tp>
crest, if you do finish it, can you paste it somewhere with your license etc ?
<crest>
i want to clean it up and use less system calls
<tp>
ok, I'll wait until you let me know
<crest>
right now it uses single byte write()/read()
<rdrop-exit>
the more features you add to your PC client the more it makes sense to just use a PC Forth as your client
<crest>
aka i don't provide any warrenty, please keep the license header but otherwise do what you want
<tp>
crest, I'll just provide your the url
<tp>
-your
<tp>
people can go there to check it out
<crest>
the code is just ugly at the moment but works because of the struct FILE buffering
<rdrop-exit>
I think it's a natural evolution, at some point if you keep adding features to the PC side of your development environment, you might as well use a PC Forth as your client
<tp>
rdrop-exit, thats fine 1) if you make your own forth, 2) if you want to depend on a PC
<tabemann>
back
<crest>
rdrop-exit: a tethered forth has different tradeoffs
<crest>
sure your host has plenty of cpu cycles and memory for fancy tricks
<tp>
rdrop-exit, I have to disagree with you that a tethered Forth is the answer to all problems
<crest>
but how do you keep the compiler extensible?
<tp>
personally I love tethered forths, but they all have their pros and cons
* crest
should finally receive 10 buck converters today
<tabemann>
to me at least, tethered forths tie you to a particular PC Forth, whereas hosted forths allow you to use any terminal sofware you like
<crest>
usb isn't designed to power stepper motors etc.
<rdrop-exit>
tp, I didn't say it was
<tabemann>
I assume you've seen fans powered by USB
<crest>
sure
<crest>
but i have received serveral over power warnings from my host
<crest>
and macos just disables the usb port for a few seconds if that happens
<rdrop-exit>
tabemann, sure if your PC development environment is simply a generic terminal, then you are truly thin client, but once it ends up relying on a bunch of scripts and other tools, then it's not so thin anyhow, might as well consolidate
<tabemann>
my PC development environment is either e4thcom or codeload3.py (thanks to Thomas, the STM8EF guy) combined with st-flash, a build script or two, and so on, but as a whole the functionality is not tied to the PC - e.g. zeptoforth is perfectly happy communicating with screen, even though e4thcom is more user-friendly IMHO
<tabemann>
(codeload3.ppy being a port of codeload.py to Python 3, combined with changes to make it tolerant of the MCU rebooting mid-load)
<tabemann>
*py
<rdrop-exit>
Sure, the same thing can apply with Forth instead of Python and your various other scripts, you can still have a target Forth that can be perfectly happy just communicating with screen when you don't need the rest of your client tools
<rdrop-exit>
one does not preclude the other
<tp>
in my case I use Forth hosted on the mcu to do real time development on various hardware that isnt anywhere near my mc
<tp>
there is no alternative for that
<rdrop-exit>
As I said, one does not preclude the other
<tp>
crest, you may have to get a PSU at some point ?
<crest>
tp: i have bench power supplies at the local hackerspace :-(
<tp>
crest, that doesnt help you working at home unless you have some really long wires ?
<crest>
your normal units with 0-30V, 0-3A adjustable voltage and current limit
<crest>
tp: exactly
<tp>
0-30 is a bit high for working with bluepills
<tp>
it's a great way to burn them out
<crest>
they have different knobs for fine and coarse adjustment
<crest>
and display the target limits without load
<crest>
so i can adjust them to 3,4 or 5,1v and a sane current limit that should prevent damages from user error
<tp>
thats pretty common for most cheap Chinese gear
<tp>
the expensive stuff has a keypad for voltage and current settings
<crest>
so far i only tested the color version of this on a stm32f103-ra where it required me to bump the flash size by one 2048 byte page
<tp>
crest, cool, I'll try it out later today after I finish my bit@ doc
<crest>
the idea behind my uploader and the patch is to ack each line processed by including a ascii ack byte in the "ok. " string literal
<crest>
and a negative ack byte in all error messages
<tp>
oh, you need a kernel patch ?
<crest>
yes
<tp>
ok, I'll add that in the notes
<crest>
the patch changes a few string literals and the Fehler_Quit and Fehler_Quit_n macros
<tp>
understand
<tp>
I always patch them myself
<crest>
i also added a simple change to to Redfine warnings to use yet an other control char
<crest>
that allows the uploader to tell the user that a warning has been emitted
<tp>
cool
<tabemann>
back
<crest>
picocom (and other terminal programs) just ignore those control chars
<tp>
I was suprised that matthias added my colors and warnings to the kernel, it's like trying to inject blood into a stone ;-)
<tp>
welcome back! tabemann
<tabemann>
hey - I created a "lookup" word which shows all the words with the longest common prefix of the word specified
<tp>
crest, yes, picocom is ancient
<tp>
tabemann, that sounds interesting, I cant wait to try it
<crest>
the patch is small, easy to maintain and doesn't increase the defaul code size at all
<tabemann>
it's like "words", except it allows you to control which words you want to look for
<tabemann>
it even has the four-column formatting
<crest>
tabemann: i wrote a match word that shows all words containing a substring
<crest>
limiting it to a prefix would be trivial
<tabemann>
this searches for a prefix, but if no words perfectly have said prefix, it shows all the words with the longest common prefix any one of them matches
<tabemann>
like:
<tp>
crest, i trued that and it worked, then I tried it later and it didnt, I havent gone back to it yet
<tp>
tabemann, have you considered renaming Zeptoforth to gforth ? ;-)
<tabemann>
lolol
<rdrop-exit>
:))
<rdrop-exit>
zforth
<tp>
tforth
<crest>
omega forth the last one to rule them all :-P
<tabemann>
I wanted to name it zforth, but the name was already taken
<rdrop-exit>
tforth exists
<tabemann>
almost every possible forth name is taken
<crest>
scnr
<tp>
yeah, all the names are taken in the world thesedays
<tabemann>
that's just how many forths there are
<tp>
it's the same for URL's
<tabemann>
I chose zeptoforth because it's like only small SI multipler not taken as the name of a forth
<tp>
tabemann, naming is hard anyway
<rdrop-exit>
but fun
<tp>
it's a science I think
<tabemann>
I wanted to name it with a small SI multiplier because this is meant for microcontrollers
<tabemann>
it wouldn't be appropriate to name it something like megaforth
<tp>
for programs it's important to be unique and not ambiguous, for product branding it's critical
<crest>
zettaforth :-P
<crest>
and all numbers have to be written as zero padded 64bit hex
<rdrop-exit>
you could do the GNU thing, e.g. FINF Is Not Forth
<rdrop-exit>
or FINC, FINC is not C
<tp>
thats a good one!
<rdrop-exit>
I call my latest No Frills Forth
<tabemann>
I'm sticking with zeptoforth because Google already associates zeptoforth with the name (i.e. first entry you see when you google it is its github)
<rdrop-exit>
cool
tolja has joined #forth
jsoft has joined #forth
<crest>
tp: i just looked at the stlink lib and within a few minutes i'm able to read a 32bit word from sram without resetting the system
<crest>
the lib is pretty easy to use: open a handle, issue a command, check the return value, get the word from a buffer stored inside the handle
<crest>
tp: writing works the same way
<crest>
put what you want to write in the buffer and use stm32_mem_write32 to write a multiple 4 bytes from the buffer to the memory address
<crest>
i can change a forth variable this way (if the host knows the address)
antaoiseach has joined #forth
<crest>
does anyone know of a better way to use a the debugger as console than just polling a single word?
<tabemann>
that would require an intimate knowledge of stlink
<tabemann>
I bet there's a way though
<tabemann>
because if writing to flash had to be 32 bits at a time, god it'd have to be slow, which it isn't
dave0 has joined #forth
gravicappa has joined #forth
andrei-n has joined #forth
mtsd has joined #forth
<crest>
tabemann: i don't want to write to flash
<crest>
i want to use a single 32bit word as serial port replacement for the forth system
<crest>
with one byte each for rx, tx, rx_ready, tx_ready
va has joined #forth
dys has joined #forth
<crest>
i guess an adeptive poll rate would be good enough
<crest>
*adaptive
antaoiseach has quit [Quit: leaving]
xek has joined #forth
<tp>
crest, very interesting, it sounds as tho your idea may work
<crest>
it should
<tp>
crest, and openocd knows how to use a usb3.3v dongle as SWD programmer and debugger
<tp>
so no one really needs a dedicated Chinese swd programmer
<crest>
because my code just calls the open_usb variant it only works with stlink v2 right now
<crest>
but a small change to the open code should be enough to support stlink v1 as well
<tp>
eww, forget V1, nobody uses that
<tp>
what we all did was flash V1 to V2
<crest>
tp: so far i'm only implementing a simplified version of my idea
<crest>
with a one byte buffer and flag for each direction
<tp>
crest, start small and get bigger later
<tp>
crest, yours is a new idea for Mecrisp-Stellaris, you're bringing new talent to it!
<crest>
and maybe the simplified verstion is good enough
<tp>
crest, what's the whole idea? upload source via SWD into the TIB where it is compiled ?
<crest>
no
<crest>
provide hooks for key?, key, emit and emit?
<crest>
writing directly into the TIB would be hideous
<tp>
wait a minute, providing hooks for key?, key, emit and emit? is far to easy!
<crest>
why would it be too easy?
<tp>
then use an 'uploader' program on the pc without a terminal ?
<tp>
well compared to writing to the TIB I mean
<crest>
the whole state (rx, /rts, tx, cts) fits into 32 bit
<crest>
allowing the stlink v2 to read it with a single read_mem32 command
<crest>
i used a different byte for each field because it allows me to use write_mem8 to change fields in the right order
<crest>
or c@/c! on forth system
<veltas>
Good morning forth-users
<tp>
g'day veltas
<veltas>
I wrote my division and it doesn't work, so debugging that today
<veltas>
Hi tp how is the metal life
<crest>
tp: it works
<tp>
veltas, good, a lot to do atm, tabemanns Zeptoforth dissasembler is ready to try to use to build RTS handshaking
<tp>
crest, awesome, so what can it do now ?
<crest>
replace the usart as console
<tp>
veltas, my new bit testing page is nearly ready, stm32f103-diags-v1.5 is finished
<tp>
crest and what replaces the terminal at the pc end ?
<veltas>
Cool, well you know I will read that if you want, although I don't see the point because I don't think you really listen to anything I say about C unless it's negative :P
<crest>
my little tool
<crest>
it puts the tty in raw mode and sends everything to the forth system
<crest>
and outputs everything in the other direction as well
<tp>
veltas, I have at least 42 readers already ;P
<tp>
veltas, actually my doc page is just my Forth notes, and some personal rants, it's not there for readership or money, it's all OSS on sourceforge
<crest>
now i have to implement something better than 1kHz polling
<tp>
veltas, it's only there to provide something modern for the few Forth addicts to read as everything else everywhere is about C
<crest>
and handle things other than ttys as input
<tp>
crest, is raising the speed a issue ?
<crest>
shouldn't be
Vedran has quit [Ping timeout: 260 seconds]
<crest>
next i have to implement file uploads
<crest>
... again
<tp>
the price of innovation!
<crest>
polling the stlink v2 as fast as possible takes about 17% of one core at 900mhz on my thinkpad t470s
<crest>
the stlink lib uses libusb in turn to acess the stlink v2 from userspace
<crest>
because there is no file upload i can't tell you (yet) how fast this console can be without further optimizations
<tp>
wow
<crest>
?
<tp>
polling the stlink v2 as fast as possible takes about 17% of one core at 900mhz
<crest>
the library fires ioctl()s like crazy
<tp>
to be expected I guess
<crest>
its a true busy poll loop only limited by how fast the syscalls return
dave0 has quit [Quit: dave's not here]
<crest>
with a smarter polling algorithm it shouldn't cause more than a few dozen syscalls per second at idle
<crest>
maybe start with a 100ms poll interval and on each transfer divde it by 3, increase by 2 on timeout
<crest>
or something like that
<crest>
with some upper and lower bounds
<tp>
the polling is part of st-link I guess ?
<crest>
its part of the logic because i don't know how to set data watchpoints
<crest>
it would be really nice to just have a data watchpoint on tx
<crest>
but because i haven't found a mcu -> host command in the stlink headers i assume that the host still has to poll
<crest>
just on some debug control register
<crest>
running words takes about 20 seconds with my swd console
dys has quit [Ping timeout: 260 seconds]
<crest>
which is several times slower than an usart at 115200 baud
<tp>
uploading and then running some words takes 20 seconds ?
<crest>
no just running "words"
<tp>
oh
<crest>
but this could be due to lots of ping-pong between the mcu and host
<tp>
because of the low 1kHz polling ?
<crest>
no this is without any sleep
<crest>
but there is still a lot of roundtrips per byte
<crest>
*there are
<crest>
it could be a lot faster with proper buffering per direction
<crest>
right now emit waits for the host to poll the "shared memory"
<crest>
notice the change and clear the flag
<crest>
so for each byte transmitted from the mcu to the host two commands have to be executed on the stlink
<crest>
one to read the whole 32 bit word
<crest>
and an other to clear the flag byte inside the 32 bit word
<tp>
http://dpaste.com/03YE95Y takes 0.5 second to list on a stm32f051 cortex-m0 running at 75Mhz and 460800 baud
Vedran has joined #forth
<tp>
thats what Im used to, a STM32F103 at 75MHz is a bit faster, definitely noticable
<tp>
lol, especially when using USB to display the wordlist
<crest>
its not like the debugger was designed as a high speed interface
<crest>
and i have to check the swd clock rate
<tp>
i think Ive seen st-link stating 900 Mhz speeds
<tp>
it usually wants 1GHz but has never achieved that here
<tp>
I have noticed that SWD is faster than JTAG when uploading to flash
<crest>
GHz?!?
<tp>
yeah
<tp>
thats what I see with openocd
<tp>
OOPS!
<tp>
adapter speed: 1000 kHz
<tp>
sorry
<tp>
1Mhz
Vedran has quit [Ping timeout: 265 seconds]
<tp>
adapter_nsrst_delay: 100
<tp>
none separate
<tp>
jtag_ntrst_delay: 100
<tp>
cortex_m reset_config sysresetreq
<tp>
Info : clock speed 1000 kHz
dys has joined #forth
<crest>
the default with stlink is 1.8MHz lets try again with the full 4MHz
<crest>
that reduced the runtime of "words" by 5 seconds
<crest>
looks like i should implement a buffered version of this
<crest>
but it's still a useful alternative to the usart if you're running out of pins
<crest>
i inverted one of flags to get a all zeroes start value for the shared variable
<crest>
the terminal programs needs to know which stlink and memory address to use
<tp>
crest, your Forth code looks simple but it's well above my Forth level
<crest>
swd is the 32bit variable polled by the stlink
<crest>
swd. just dumps the variable with hex. (little debug helper)
<crest>
the protocols works like this
<crest>
to send a byte from the mcu to the host the mcu checks if the one byte tx buffer is available
<crest>
if so it writes to a byte to the tx buffer and sets the flag to $ff
<crest>
now it's the hosts job to poll the whole variable
<crest>
notice the flag
<crest>
show the byte to the user and clear the flag
<crest>
to get a byte from the host to the mcu the host has to check if the mcu rx buffer is free
<crest>
if the buffer is free it writes to the buffer and sets corresponding flag to $ff
<crest>
now the mcu has to poll the rx flag byte
<crest>
read the data byte and clear the flag
<crest>
so there are two or three stlink commands (mem_read32 or mem_write8) per single byte transfer depending on the direction
<crest>
this is a lot of fucking overhead
<tp>
as you said earlier, perhaps a buffer on the mcu to speed it up ?
<crest>
and each side has to wait for the other
<crest>
i want to write a little benchmark how fast i can read 1024^2 times
<tp>
yeah, must be as it's so slow, Im surprised
<crest>
that should be the upper bound
jsoft has quit [Ping timeout: 265 seconds]
<crest>
65.738424 seconds / MiB
<crest>
or 124.61 kib/s
<crest>
so my upper bound is around the speed of a 115200 baud usart
<tp>
but there is a disconnect as reading the wordlist at that speed is much less than 60 seconds ?
<tp>
maybe 1 or 2 seconds ?
<crest>
that's just reading from the same 32 bit memory location in a loop
<crest>
with no waiting at all
<tp>
it's much too slow imho
<tp>
... sadly
<crest>
uint32_t value = read32(addr);
<crest>
for ( size_t i = 0; i < (1024*1024)/4; i++ ) {
<crest>
}
<crest>
i don't know if one could write debugger
<tp>
can you correlate that with a sw-link write to flash if 1024 bytes ?
<tp>
if = of
<crest>
or even if the debugger i have could be faster with a different library
<tp>
I'm thinking suck a write to flash is about 7 seconds ?
<crest>
i haven't tried that
<tp>
such
<crest>
let me check how long it takes to read the whole flash
<tp>
ah yes, great idea
<crest>
reading the whole 128KiB flash took just 1.31 seconds
<crest>
= 6.2 times faster than my benchmark
<tp>
still slow :(
<tp>
come to think of it, when Ive used the serial bootloader on occasion Ive always been surprised how fast it is
<crest>
faster than your serial baurate
<crest>
but not by much
<tp>
I'm limited to 460800 baud with Screen on FreeBSD but the real slowdown when uploading source is the on chip compiler
<tp>
so uploading is different to reading from the chip
<crest>
how fast is your effective datarate while uploading code?
<tp>
I've not measured it
<tp>
let me time it
<crest>
maybe it's more efficient to transfer multiple words per api call?
<crest>
reading in 1024 byte blocks is about 10 times faster
<tp>
11 seconds to upload (and compile) 42606 bytes of source with no comments
<tp>
on a cortex-m0
<crest>
my latest benchmark reading 1024 times the same 1024 bytes from sram runs in 6.429456 seconds
<tp>
thats as fast as st-link ?
<crest>
that's faster than st-flash read
<crest>
so your upload speed is just 3873 byte/sec
<crest>
less than the peak throughput of a 38.4k baud link
<tp>
yeah, the culprit is the on-chip compiler
<crest>
sure but relative to this my idea could still be fast enough
<tp>
ah yes, regarding upload speeds :)
<tp>
youll just have to send wordlists by telegram instead ;-)
<crest>
no?!?
<tp>
60 seconds for a wordlist is about 120 times too slow
<crest>
with a large enough buffer the transfer speed should go up by several factors
<tp>
I think thats still way too slow, certainly for me
<tp>
of course searching wor a word would cure that
<tp>
for
<tp>
so there would be workarounds
<tp>
searching instead of listing
<tp>
I list as I have no search
iyzsong has joined #forth
<crest>
my read benchmark reaches about 1276 kbaud
<crest>
about 3 times that of your serial console
<tp>
only when uploading source
<tp>
I also use it to download hexfiles and source
<tp>
automatically, when Im making a release tarball
<tp>
and hex is quite verbose ;-)
<tp>
Intelhex I mean
<tp>
but thats just me
<crest>
3 times the peak data rate of your serial connection's baud rate
<tp>
tho tabemann also uses that method to make his 'full' releases
<tp>
another factor is this is a cortex-m, your cortex-m3 is 3 -5x faster than that
<tp>
another factor is this is a cortex-m0, your cortex-m3 is 3 -5x faster than that
<crest>
why is the m0 so much slower per clock?
<crest>
is it just the thumb1?
<tp>
it's the m0
<tp>
it's the simplest stm32 off all
<tp>
it has a tiny dies size and very few transistors in comparison to the F1xx and above
<crest>
but why did they use the old arm v6 with thumb1? isn't the m3 the oldest cortex m?
<tp>
yes, the stm32f103 was released in 2004, the stmn32f0 in 2011
<tp>
the f0 is the cheapest in stm32, and is capable of many embedded tasks, perhaps thats why ?
<crest>
but how can a core that implements arm and thumb1 mode be smaller than one that just implements thumb2?
<tp>
the m0 *only* implements thumb1
<crest>
maybe instead of a pair of ring buffers with a read and write index each it would be better just have a bitmap in every 8th byte of the buffer
<veltas>
How old is # for pictured numeric output processing?
<veltas>
Because the method seems really inefficient for printing a number, although I'm not sure how much it matters
<crest>
i have no idea
<crest>
it isn't designed to just print numbers
<crest>
but to format them
<veltas>
The way it's defined makes sense if you have division built-in, and division is fast. But if division is software or software-support it makes zero sense because the *steps* of division actually produce digits in the right order
<veltas>
So it's like you end up doing the work many times over
<crest>
division is always faster than humans
rdrop-exit has quit [Ping timeout: 246 seconds]
<veltas>
I don't understand what you mean, why does it matter how fast humans do it?
rdrop-exit has joined #forth
<veltas>
My least favourite thing in standard forth so far is the sized arithmetic combinations available and the ambiguous conditions for using them
dddddd has joined #forth
<crest>
i guess on hardware without a hardware divider you could implement special cases for base 10 and 16
<veltas>
Yes, that is the approach I am using
rdrop-exit has quit [Quit: Lost terminal]
<veltas>
Well the plan is to have a special case in # for any power of 2 base, and probably a hardcoded case for 10.
pointfree has quit [Ping timeout: 260 seconds]
mtsd_ has joined #forth
pointfree has joined #forth
mtsd has quit [Ping timeout: 272 seconds]
TCZ has joined #forth
<crest>
the numworks calculator looks like a nice little mobile forth system
<tp>
and has a Mecrisp-Stellaris binary just for it
Lord_Nightmare has quit [Ping timeout: 258 seconds]
karswell has quit [Remote host closed the connection]
karswell has joined #forth
Zarutian_HTC has joined #forth
<tabemann>
back
<tabemann>
hey guys
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
karswell has quit [Remote host closed the connection]
karswell has joined #forth
<crest>
dealing with padding for both parts of a ring buffer gets annoying
<tabemann>
hey
* tabemann
is going to take a stab at programming this nRF52840-DONGLE board
<andrei-n>
Hello. This time I have a more concrete problem. How should I represent a doubly linked list in Forth? Should I use structures or there is a better solution?
<MrMobius>
andrei-n, do you know how to use CREATE and ALLOT?
<andrei-n>
Yes. It's for creating arrays or strings, that is contiguous sections of data in memory.
<MrMobius>
right
<MrMobius>
you can store anything you want there though. you can also think of it like a struct in C where the bytes could be different types
<MrMobius>
like if you have a 1 byte variable, a 2 byte variable and a 4 byte variable, just do 7 ALLOT and you can store those three things there however you like
<andrei-n>
So the way Forth does while defining words? So you just specify (like in a binary file) the organization of data and that's all?
<MrMobius>
you dont really specify the organization of data, you just write it at a particular address and as long as youre careful you wont overwrite anything
<andrei-n>
And is there a way to "free" the allots? For example I have a string that might become bigger, so I need to make more space. But the old one still takes some space.
<MrMobius>
not really. what youre describing is dymanic memory allocation
<CORDIC>
" allot" is yet another Stack: " neg allot".
<MrMobius>
so you could a few bytes in your structure to hold an address then devise some way to do dynamic allocation and store the address in the struct
<andrei-n>
That means that if I for example want to make a text editor I need to write my own memory allocator?
<MrMobius>
andrei-n, yes or find a forth that has one builtin or bite the bullet and make every line in the editor the max line size
<MrMobius>
the memory allocator becomes much easier if every block allocated is the same size. on the other hand you might be wasting a lot of memory. depends on what system youre on the resources you have to spare
<andrei-n>
Is it a common thing for a Forth programmer to write a memory allocator? Or is it some kind of antipattern?
<CORDIC>
Why would it be ""anti-pattern""?
<MrMobius>
andrei-n, what system are you working on? some of the PC-based forths probably have it built in already
<andrei-n>
CORDIC, Because it might be like forcing a mentality from other programming paradigms...
<andrei-n>
MrMobius, gforth
<CORDIC>
andrei-n: Are you aware gforth is not even v1.0?
<andrei-n>
CORDIC, yes... Is it a problem? Are there other free implementations that are still alive?
<crc>
andrei-n: I've not needed to use or write a memory allocator in my forths
* tabemann
wrote a memory allocator for hashforth from scratch, while on the other hand, zeptoforth lacks such a thing
<crc>
Create and allot have sufficed
<andrei-n>
crc, If you have enough memory you don't have to free. You can allocate more and more.
<andrei-n>
MrMobius, Thanks. It seems to be a non-standard extension.
<MrMobius>
andrei-n, I wouldnt worry about that. everyone just does what they want when it comes to Forth. its not like C where you can compile the same source with different compilers
<crc>
I generally use a build with 512k memory locations
<crc>
This can be tight with large files
<andrei-n>
crc, I made a hashtable in PL/M on CP/M for Nand To Tetris, it had something like 30K, so it's entirely possible.
Zarutian_HTC has quit [Ping timeout: 264 seconds]
karswell has quit [Remote host closed the connection]
<tabemann>
back
jsoft has joined #forth
jsoft has quit [Ping timeout: 256 seconds]
karswell has joined #forth
gravicappa has quit [Ping timeout: 260 seconds]
reepca has joined #forth
<crest>
tp: i improved my througput to 19 seconds per megabyte
<crest>
or about 430 kilobit/second
karswell has quit [Read error: Connection reset by peer]
<crest>
running words takes less than a second with the m3 disassembler loaded
<crest>
but i have only implemented the stm32 -> host direction so far
reepca has quit [Read error: Connection reset by peer]
reepca` has joined #forth
reepca` has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Client Quit]
reepca` has joined #forth
Zarutian_HTC has joined #forth
dave0 has joined #forth
TCZ has joined #forth
xek has quit [Ping timeout: 272 seconds]
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
andrei-n has quit [Quit: Leaving]
dys has joined #forth
cheater has quit [Ping timeout: 240 seconds]
cheater has joined #forth
TCZ has quit [Quit: Leaving]
cheater has quit [Ping timeout: 240 seconds]
cheater has joined #forth
WickedShell has quit [Remote host closed the connection]