<tabemann>
I'm already working on a new release of zeptoforth (I'll call the previous "release" 0.1)
<tabemann>
well, 0.1.0
<tabemann>
the main improvement will be getting erasing to work as expected (it does already on the l476, but is broken on the f407)
<tp>
changed your file structure ?
<tabemann>
for 0.1.0 I added premade binaries
<tabemann>
so someone can just take st-flash, write a binary to their board, and wahoo they're off and running already
<tp>
people love that to get started
<tp>
and of course Mecrisp-Stellaris always came with binaries and source
<tabemann>
no need to get the arm-none-eabi toolchain
<tp>
*everyone* has that, even arduinees
<tabemann>
the hardest part of doing it the build it yourself way is remembering to write to $08000000
<tabemann>
I had that problem with mecrisp-stellaris
<tabemann>
(and that problem also applies with prebuilt binaries as well)
<tp>
tabemann, thats why some of us use a script :)
<tabemann>
ugggh
<tabemann>
why is it (semi)bricking the board after erasing the interrupt-driven IO driver (along with everything else but the kernel) on the F407 board (but not the L476 board)?
<tp>
tabemann, youve seen I use the occasional script to get stuff done
<tabemann>
(semi)bricking as in it locks up and refuses to boot, but can be simply restored to working order with st-flash
<tp>
bricking was only a Linksys WRT54 problem until people discovered JTAG
<tabemann>
bbl
<tp>
no problemo
<tabemann>
back
<tp>
tabemann, $8000000 is burned into my memory, I cant forget it anyway :)
<tabemann>
as it is into mine
<tp>
not that I use it much now
<tp>
Forth isolates one from all that
<tabemann>
you mean your scripts isolate you from all that
<tp>
no, I mean I rarely upgrade the Forth binary
<tp>
all my flashing is done New York Forth itself in the normal course of program development
<tp>
oops
<crest>
tabemann: that's why you use a Makefile instead of ^Rgcc to invoke the compiler
<tp>
all my flashing is done in Forth itself in the normal course of program development
<tp>
crest, exactly, or a script
<tabemann>
whereas I very regularly flash the zeptoforth kernel
<crest>
tp: most people forget that scripts can be interrupted and fail to recover from a simple ^C
<tabemann>
because I'm constantly bricking the board, over and over
<crest>
having to deal with broken scripts reinventing dependency tracking etc. is annoying
<crest>
make isn't perfect, but it works and saves a lot of time and pain
<tp>
tabemann, yes of course as youre doing a lot in assembly
<tp>
tabemann, do you use stlink instead of openocd ?
<crest>
and if want to do it in scripts at least provide a makefile wrapping them
<tabemann>
I only use openocd if I plan on using gdb
<tp>
aha
jsoft has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tabemann>
back
<tabemann>
tp
<tp>
yes tabemann
<tabemann>
do you know how to trigger a true warm reset on Cortex-M
<tp>
whats a ' true warm reset' ?
<tabemann>
because my "reboot" on zeptoforth is really just a branch to its entry point, it does not truly reset the hardware
<tp>
I know how to clear ram
<tabemann>
essentially pressing the reset button, but in software
<tp>
um, yeah ... I enter 'reset' :)
<tp>
I havent looked into the mechanism tho
<tp>
as a tech Im familar with the way to reset the chip using the BRST pin
<tp>
NRST
<tp>
tabemann, the other thing is that a cortex-m reset sets all peripheral registers to defaults
<tabemann>
that's the point
<tabemann>
I want to reset all peripheral registers
<tp>
tabemann, cant you see how matthias does that in his source ?
<tabemann>
oh, I found it
dddddd has quit [Ping timeout: 256 seconds]
<tp>
tabemann, if you ever get inclined to poet to the GD32VF103 bear in mind that it DOES NOT HAVE a global register reset to defaults like cortex-m
<tp>
tabemann, one has to reset every peripheral to defaults individually with the GD32CF103 RISC-V chip
<tabemann>
ugh
<tabemann>
why did they have to do it that way?
<tabemann>
YES
<tabemann>
my software reset now really works
<tabemann>
i.e. a real software reset, not the fake software reset I was doing before
<tp>
FAKE RESET NEWS!
<tabemann>
lol
<tp>
tabemann, and that may have been a cause of much of your 'undefined behaviour'
<tp>
as peripherals were not being reset
<tabemann>
yeah
<tabemann>
and btw, new binaries are available!
<tp>
awesome ill grab one right now
<tabemann>
I should put some work into writing better docs for this now that it's in a good state
<tabemann>
like guides on how to use the multitasker and the event scheduler APIs
<tp>
you mean 'write some docs' ?
<tp>
you havent started yet :P
<tp>
when you do a cortex-m0 version I'll document it on my site
<tp>
but you have to get over your thumb1 revulsion first I know
<tabemann>
I have docs, but they are just a list of words with stack comments and very short explanations (in the case of the Forth routines, the kernel ones have no such explanation)
<tabemann>
tp: the big problem is that with thumb1 literals may be gigantic, and there is no way to know ahead of time how big an arbitrary literal that will be set later will be
<tabemann>
and also, if you use the approach of storing literals in separate locations in memory from the code
<tp>
yeah I know
<tabemann>
it has the problem of not being able to predict where those locations will be, which is a problem for compiling to flash
<tp>
I doubt youll ever feel the need to port, but I dont use M4 so I have no interest in documenting it
<tabemann>
at least for thumb-2, you can know that a literal will be a maximum of eight bytes
<tp>
I'm a user, I dont care how hard or inefficient the Forth kernel is
<tabemann>
I'll probably have to do a partial rewrite to support M0
<tp>
look at my benchmark :
<tp>
MCU Clock (MHz) Time (sec) Comments
<tp>
STM32F051 96 (overclocked) 0.3 Mecrisp-Stellaris RA 2.3.7 with M0 core for STM32F051
<tp>
STM32F103 75 0.1505 Mecrisp-Stellaris RA 2.5.1 with M3 core for STM32F103
<tp>
STM32F051 72 (overclocked) 0.516 Mecrisp-Stellaris RA 2.5.3 with M0 core for STM32F051
<tp>
STM32F051 48 0.6 Mecrisp-Stellaris RA 2.3.7 with M0 core for STM32F051
<tp>
STM32F051 8 2.59 Mecrisp-Stellaris RA 2.3.7 with M0 core for STM32F051
<tp>
Atmega328 16 4 Flash Forth 5
<tp>
STM8S003F3P6 ( From Flash ) 16 6.4 optimized for size not speed
<tp>
STM8S003F3P6 ( From Ram ) 16 6.9 optimized for size not speed
<tp>
Mecrisp-Stellaris for cortex-m thumb1 is the fastest in existence
<tp>
regardless of the thumb1 issues, which mattias also hated, in fact he hates all cortex-m
<tp>
prople are still making forths for cortex-m that use python, java, C etc and theyre so slow I could die laughing
<tabemann>
writing a forth in python that runs on cortex-m? lol
<tp>
every programmer trying out forth for the first time has a unique Forth
<tp>
the repos are full of hundreds of them
<tp>
they bring all their previous software attitudes
<tp>
i think Forth must be the most reimplemented language *ever*
<tabemann>
it's probably because it's the easiest language to try to implement
<tp>
I guess, but youre the expert here, not me
<tabemann>
you probably know way more about the matter than your average forth newbie
<tabemann>
compared to you, I am a forth newbie
<tp>
only using Forth
<tp>
nooo, youre confusing a user with a programmer
<tp>
is a linus user a Linux programmer ?
<tp>
nope, that have no idea what a spinlock is, and I dont have much either
<tp>
but it doesnt stop them using Linux to design a pcb, a 3dcad drawing etc
<tabemann>
you're a Forth programmer, you just aren't a Forth compiler implementor
<tp>
ok, I'll use that description in future
<tp>
:)
<tp>
I havent even acquired a basic understanding of <builds does> yet, ... please don't anyone try and explain it to me, no spoilers!
<tabemann>
I'm the opposite - I've implemented three different Forths, but most of my use of Forth has been in the form of writing example programs or add-ons to the compiler
<tp>
yeah, users and programmers have differnt skill sets, mine arer hardware
<tp>
-r
<tabemann>
hardware programming for me is limited to programming LEDs to turn on or off
<tp>
thats a start
<tabemann>
seriously, the most elaborate programs I've written for zeptoforth are ones that use the multitasker and the event scheduler to turn LEDs on and off in different patterns
<tp>
tabemann, your binary works fine has no 'words'
<tabemann>
which binary
<tp>
tabemann, whats the point of a binary that doesnt include everything ?
<tabemann>
there's two binaries
<tabemann>
one's just the kernel
<tabemann>
one includes everything aside from the blinkies themselves
<tp>
and the sooner you implement it, the easier your doc generation becomes
<tabemann>
I assume to you Markdown counts as "bunch of text files"
<tp>
well not quite unless they have no index
<tp>
but lets face it *.md is text
<tp>
unless it's viewed by a browser
<tp>
not that I'm a markdown expert
<tp>
fact is the harder unconnected text files are to read, the less people will read them
<tp>
youll get tons of emails asking questions yove answered already in various unindexed md files if you dont
<tp>
once zeptoforth hits critical mass ...
<tp>
youll be *buried* in emails
<tp>
then your marriage will suffer, you'll become an alcholic and end up on skid row ... mark my words!
<tp>
save yourself NOW!
<tabemann>
back
<tabemann>
lol
<tp>
this is why GIT sucks and fossil rules, fossil has built in tickets, wiki, technotes, forum etc
<tp>
I expect CRC built his excellent doc in fossil as he developed, right from the start which is the right place to begin doc, and I dont mean 'Doxygen' which is FAKE DOC!
<tp>
in a way I now wish Id used fossil for my doc instead of py.sphinx, except I was a double dumbass when I started my docs
<tp>
now I'm just a dumbass
<tp>
I had come from Zim before py.sphinx so that was a big improvement
<tp>
and markdown has no indesing or cross refs afaik which is a big negative imho
<tp>
indexing
<tp>
but one think Ive learned is 'if DOC isnt dead easy to create, it won't happen'
<tp>
why do you think I have 10 million viewers of my online webdoc ?
<tp>
.. ok it's really only 42 viewers but '10 million sounds so awesome'
<tabemann>
lol
<tp>
tabemann, i think markdown doc required masterful editing to be useful, and thats what CRC does
<tp>
tabemann, otoh, py.sphinx has indexing and search, plus pictures etc and that ameliorates my crap writing and editing to a great degree
<Modulo5k>
Hello all - my friend is having trouble making dlls compatible with forth. Are there any requirements for this?
<veltas>
"making dlls compatible with forth" really depends on the forth
<Modulo5k>
I know nothing about forth, so please spare newbie comments
<Modulo5k>
He should be on IRC soon, so I'll ask him what version he's using
<veltas>
Half of us are noobs we're not going to judge
<veltas>
Maybe he should ask if he'll be on IRC
<Modulo5k>
yes, probably
<Modulo5k>
I'm just the messenger
<Modulo5k>
recon if you will
<Modulo5k>
The dlls are compiled in C++
<Modulo5k>
And he calls the dlls from forth
rogerlevy has joined #forth
<rogerlevy>
Hi, are there any VFX or SwiftForth users on here today, who happen to know about DLL's on Windows?
<MrMobius>
rogerlevy, its usually better to just ask your question. someone who knows might tune back in a little while
<MrMobius>
but not knowing anything about either of those, you might want to figure out the calling convention a program written in C or some other language uses and try to recreate that in Forth
<MrMobius>
maybe create a one line program in C that calls a DLL then step through with a debugger and see what it's doing
<Modulo5k>
rogerlevy and I are trying to solve some problems with the graphics and input library Allegro 5. On Windows, it's compiled as C++
jsoft has joined #forth
<MrMobius>
and you want to do that in forth instead of C++?
<rogerlevy>
Already been doing it for several years now :]
<rogerlevy>
VFX and SwiftForth both have problems loading newer versions of Allegro's DLL in recent years.
<rogerlevy>
I.E. it refuses to load
<rogerlevy>
(bind)
rogerlevy has quit [Quit: Connection closed]
rogerlevy has joined #forth
rogerlevy has quit [Client Quit]
rogerlevy has joined #forth
<Modulo5k>
Turns out the LIBRARY call succeeds, but all calls to functions within the DLL crash
<Modulo5k>
NVM it was 64 bit , trying a 32 bit DLL now
<rogerlevy>
Worked (y)
<tabemann>
back
<tabemann>
hey guys
<tabemann>
crest
<crest>
tabemann: ?
<tabemann>
the problem is that, at the time a literal is compiled
<tabemann>
there is no way to know where to put the PC-relative literal
<tabemann>
because one does not know how long the word will be
<tabemann>
unless
<tabemann>
one puts the literal inline, and jumps over the word
<crest>
how do you deal with to large conditionals?
<tabemann>
but that has its own complications
<crest>
e.d. a 10kB switch case
<crest>
*e.g.
Modulo5k is now known as BugSquasher
<tabemann>
because PC-relative addressed constants have to be 32-bit aligned
<tabemann>
yet thumb code is 16-bit aligned
<tabemann>
and it has to jump over the constant that way as well
<crest>
which is a lot of bloat
<tabemann>
right now I'm just focusing on Cortex-M3/M4, and will get around to working on Cortex-M0 if I feel the need
<tabemann>
also because zeptoforth seems to produce kind of big machine code, and Cortex-M0 processors typically don't have that much flash
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
<veltas>
tp: You still awake?
<crest>
tp: is the code for your mecrisp stellaris helper functions like "words4" and "free" publicly available?
BugSquasher has left #forth [#forth]
<veltas>
My Forth can't handle a control structure that needs to jump further than 255 bytes
<veltas>
But who would ever need that, right? ;)
<tabemann>
I've run into that
<tabemann>
this is a reason I probably won't even support Cortex-M0
<veltas>
To be fair haven't done CASE yet, I think I will be doing a dumb walk over the OFs so you should be able to manage a much bigger switch control than 255 bytes, but each OF..ENDOF will need to be that small
rogerlevy has quit [Quit: Connection closed]
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
Zarutian_HTC has joined #forth
jsoft has quit [Ping timeout: 240 seconds]
<veltas>
But anyway refactoring is a virtue
tolja has joined #forth
tp is now known as tp_
tp_ is now known as tp
tp is now known as tp_
tp_ is now known as tp__
tp__ is now known as tp
<tp>
crest, yes it's all available, people only have to ask if they cant find it on my website
<tp>
veltas, I am awake now
* crest
asks
<veltas>
tp: Do you have twitter?
<tp>
crest, I saw that, I'll quickly paste them to a pastebin
<tp>
veltas, no, I have avoided all 'social networking' this is as close as I get here on irc
<veltas>
SHUCKS
<veltas>
There are some people I can only get on Twitter which is why I joined today
rogerlevy has joined #forth
<tp>
veltas, I've basically got little to say to most people because I've always been very foccused on what I want to do
<veltas>
Yes that is how people seem to use Twitter, at least in random dev stuff
<tp>
oh
<veltas>
You have a YouTube channel, it would basically be like that if you had one but for short clips and random status updates
<veltas>
That's how techy poeple seem to use it anyway
<veltas>
I know that there is a twitter underworld of people with too much spare time, but the actual interests parts of twitter are chill
<tp>
veltas, then I'll look into it
<veltas>
I'm not trying to sell it, just explaining my perspective as someone who has also resisted twitter
<tp>
brb, gotta paste the programs for crest
<tp>
BTW GENERAL NOTE::: To all here, if you dont know, Freenode just removed all unused NICKS
<veltas>
Now's my chance to grab a short nick nobody will recognise me under
<veltas>
meh
<tp>
so NOW is a good time to reaquire any old alternative NICKS that people may have stolen from you
<tp>
Ive just recovered my old "tp_" and "tp__" that were taken after I hadnt used them about a decade ago
<crest>
tp: looks like my blue pills admit having 128kB flash
<veltas>
Oh so it's COUNT TYPE ?
<tp>
crest, do they suggest a chip type ?
<tp>
veltas, I learned Forth with Mecrisp-Stellaris so Ive only known it as CTYPE
<crest>
i closed the window that contained the stm32flash output and don't want to wipe the flash at the moment
<veltas>
Hmmm it refers to it as a "logical extension" of ANS forth I think
<tp>
crest, my newbluelipp 'developer' version is nearly finished won;t be long now
<veltas>
tp: Nothing wrong with that, I don't even know standard Forth that well
<tp>
er ... newbluelipp = new bluepill
<crest>
tp: thanks for working on that (almost just for me) :-P
<tp>
crest, a pleasure, I like to be useful
<tp>
crest if you want one, someone else in the group of 42 worldwide Forth users may also
<tp>
I was a bit sneaky with the Bluepill I admit; I tried advocating Forth on probably the worlds most popular tech forum, EEVblog but the C advocates soon massed like an angry mob
<MrMobius>
tp, do you have a link to that thread?
<tp>
MrMobius, it's all over the place, I'll try and find some
<crest>
tp: but please include the source code because it really helps us poor programmers sleep better :-P
<tp>
crest, of course, thats one of my "improvements" in the release
<tp>
crest, up until now, it wasnt possible to automatically include the source for my precompiled binaries
<MrMobius>
oh hmm he's being satirical. I never saw the original thing he's making fun of
<tp>
hes a troll
<tp>
so I noticed there was an immense amount of confusion with C/Arduino users regarding the $2< "blue pill" board from china regarding counterfeit MCUS
<tp>
many boards had non functional USB etc, so I decided to be sneaky and make a Forth bootable binary with menues and not mention Forth
<tp>
it was pretty popular with Windows users and has been dl about 222 times as of today, but a recent new version has pretty much stopped that one being used now
<tp>
this diagnostic binary booted from the usb power and the active terminal menu made it so easy to use that I think most people didnt know it ran Forth
<tp>
in any event I no longer get replies from posters like "mr scram" or anyone else on that forum regarding Forth
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
<tabemann>
hey guys
<rogerlevy>
hi
<tp>
hey tabemann
<tabemann>
I made WORDS display words in four columns
<tabemann>
it also handles the case when word are too long to fit in their column properly
<tp>
awesome
<tabemann>
I've also made an official release .tar.gz package
<tabemann>
and I put it up on github and on hackaday.io
<tp>
nice, I'll grab and try!
<tabemann>
it's not the newest code though
<tabemann>
it lacks the four-column WORDS
<tp>
doesnt matter
<tp>
oh
<tp>
forget it then ;P
<tabemann>
lol
<tp>
my system is fully automated, I click on clone and I get the latest all in a tarball, plus the newest mods include a 'source' file with all my smaller files concatenated
<tabemann>
note that the four-column words doesn't sort, because I didn't feel like dumping a record of each word out to RAM in a doubly-linked list, then implementing something like mergesort to sort that list
<tp>
yeah, I knew sorting wouldnt be fun, and Ive decided to include a sorted wordlist as a separate txt file in my releases
<tp>
i cant do it on the cortex-m0 I think as I only have 8kB ram
<tabemann>
tp: yeah, it doesn't seem feasible on a system that small
<tabemann>
okay, added code to WORDS to hide all those *RAM* words
<tp>
tabemann, is that like a SMUDGE ?
<tabemann>
*RAM* words are necessary to make RAM variables declared from flash work properly
<tabemann>
they're used to record the maximum amount of RAM taken up by such RAM variables, so that RAM can be allocated at boot time
<tp>
sure
<tabemann>
I made it so it doesn't show words that take the form of *<text>*
<tp>
aha
<tabemann>
note that it still shows the word **, where it to exist, allowing me to create a word for exponetiation that would be visible
<tabemann>
*were
<tabemann>
I wonder how I should space out releases - simply making WORDS better is not release-worthy, whereas making a major bugfix is, as is adding a major feature
<tp>
good question
<tp>
as long as serious users can git pull they can get the latest anytime
<tabemann>
yes
<tabemann>
the source code in git will always be the newest
<tp>
so just release when you have a major update ?
<tabemann>
the binaries in git, on the other hand, will be associated with a release
<tp>
of course
<tp>
only do major releases as binaries ?
reepca` has quit [Read error: Connection reset by peer]
<tabemann>
well, any releases will be as binaries
reepca` has joined #forth
<tabemann>
e.g. if I make a bugfix, I want the binaries to include the bugfixes
<tp>
sure
<tabemann>
bugfixes will probably be more likely to result in releases than features
<tabemann>
because people can do without features
<tp>
thats pretty much what matthias does
<tabemann>
whereas if someone runs into something that's broken... they'll want it fixed
<tp>
he's very careful but occasionally releases a a bugfix with a minor release number
<tp>
how he does all that without *any scm* amazes me
<tabemann>
I probably will do most of my releases as minor numbers, but things like bugfixes and like as patch numbers
<tabemann>
why???
<tp>
i dont know
<tp>
he just doesnt need them he says
<crc>
why four columns?
<tp>
to make it easier to read than a word dump
<tabemann>
back
<tabemann>
crc: from comparing the new way of doing things with the old way, the new way definitely is more readable
* crc
will implement this then
<tabemann>
and four columns fits well on a 80-character wide terminal
<tabemann>
e.g. with zeptoforth, which has quite a few long word names, most word names still are within 20 characters wide
<tp>
crc, I find that Forth creators definitely dont need a columnar list as they know every Word intimately, but us noobs get lost in a huge word dump
* tabemann
is now porting [if] - [else] - [then] to zeptoforth
<tp>
tabemann, I find your words a bit long, for instance "led-red-on" Id name "redon" or maybe "red-on"
<tp>
thats just my personal choice
<crc>
that assumes word names thank ~19 characters (for an 80 column display), some of mine are longer
<tp>
tabemann, your wording is certainly more acccurate
<tp>
crc you have to allow for longer names in the "word4" design
<tabemann>
I'm going to take a walk because it's going to rain in about an hour
<tabemann>
my four-column WORDS design takes into account word names longer than 20 characters
<tp>
in mine a long word just uses up the next column or more until it's finished
<tabemann>
that's how mine works too
<crc>
longest names in retro on unix are 23 characters
<crc>
mine pads all columns to match the longest name length
<tabemann>
I haven't determined a longest word length for zeptoforth, but the vast majority are < 20 characters
<tabemann>
I'll be back in a bit
<tp>
same here
<tp>
irq-spi3 irq-uart4 irq-uart5 irq-tim6
<tp>
irq-tim7 irq-usbfs --- Flash Dictionary ---
<tp>
72mhz u.1 u.2 u.3
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
<crc>
my average names are 8 characters, or 5 if excluding the namespace prefixes I use
<tp>
crc, mine can get longer because I auto create words for hardware
<tp>
when you have 17,000+ Words to create, you can't do them manually
<crc>
Ouch
<crc>
that's a *lot* of words
<tp>
here is a example
<tp>
: SYSCFG_CFGR1_USART1_TX_DMA_RMP ( -- x addr ) 9 bit SYSCFG_CFGR1 ; \ SYSCFG_CFGR1_USART1_TX_DMA_RMP, USART1_TX DMA remapping bit
<tp>
crc, it's a facet of these modern hitech times :)
<tp>
crc, take for example a STM32F7x7 chip. It has 93 Peripherals, 2093 registers and 17051 bitfields all with unique names
<tp>
crc, fortunately with Forth I can name them automatically and correctly, you should see the massive mess that C systems make of them
<crc>
2093 registers?
<tp>
peripheral registers
reepca` has quit [Read error: Connection reset by peer]
<tp>
the chip itself has seperate mcu registers
reepca` has joined #forth
<tp>
not included in that tally
<crc>
that seems excessive...
<tp>
the above SYSCFG_CFGR1_USART1_TX_DMA_RMP Word is one of the 17051 bitfields
<tp>
it's not, in fact it's awesome
<tp>
each one represents capability
<tp>
for instance that chip might have SIX on board USARTS
<tp>
it will probably have 100+ GPIO pins, and each one can have up to about 50 different configs
<tp>
this is the world I live in as a electronics tsch
<tp>
tech
<crc>
it's a very different one from where I work
* Zarutian_HTC
would have something like mram or memristor based CPLDs than most MCUs
<tp>
hopefully it throws some light on my attitudes about using forth, where they differ from the usual here
<tp>
Zarutian_HTC, I live in a simpler world :)
<Zarutian_HTC>
in
<Zarutian_HTC>
it has occured a few times that MCU i wanted to use had placed two periphals I wanted to use on the same pins
<tp>
Zarutian_HTC, I always refused to even look AT PLDs, FPGA's etc where proprietary software was required to program or flash them etc
<Zarutian_HTC>
most fpgas need propitary software, well specified cpld does not
<tp>
Zarutian_HTC, yeah, you get that, it's a complex world. Most massive peripheral chips can't use everything at once
<Zarutian_HTC>
sure but the pin allocation was bonkers
<tp>
even the mcu I use, the STM32F051 can only use a few peripherals as it only has 32 pins and 33 peripherals on board
<tp>
Zarutian_HTC, and if you want a really versatile pin matrix choice then you get a zillion onboard analog switches and all the attendent xtalk ?
* crc
will eventually have to deal with this stuff, but that'll be a while off
<Zarutian_HTC>
I thing motorola or at least someone inspired by them had the right idea of just having spi buses and provide peripheral chips on that bus
<tp>
crc, I started with this stuff in 1974 so Im really at home with it
<Zarutian_HTC>
think*
* tp
likes SPI
<Zarutian_HTC>
that way you can mix and match in your design
<crc>
tp: my low level work has almost exclusively been on x86 systems so far, and I've only been back into that during the last year
<tp>
crc, I think this is true of most X86 Forth creators, X86 is never used in embedded work
<tp>
Zarutian_HTC, every industry has it's special needs, a STM32 MCU is made for general applications, generally not specialist stuff
<tp>
Zarutian_HTC, and the cost of every additional part adds up in pcb design and manufacture
<MrMobius>
Zarutian_HTC, that sounds terrible :P
<Zarutian_HTC>
tp: one trick I came across was to have an shift in shift out paralel register feeding into a demux. The outputs of the demux went to the en on various, chips
<MrMobius>
some of the old timers on the 6502 forum still think setting up a whole system 6-7 chips to get 16 GPIO is the way to go
<MrMobius>
whereas you could do that with a $1 chip and more gpio and flash
<tp>
Zarutian_HTC, luckily I dont have to worry about that stuff with a mcu with 33 - 98 peripherals on board :)
<Zarutian_HTC>
that way only two pins extra were needed for chip enable. One for that selection register and one through the demux
<tp>
MrMobius, yeah, I HAD to do that a long time ago, it was awesome then, but now ??? Its like buying a Stanley Steamer to drive around in
<tp>
I know there are a LOT of 6502 fans about, but after repairing hundreds of 6502 boards in the mid 80's I'm about over them now
<Zarutian_HTC>
MrMobius: depends on what you are doing. I have run a manifacture line where hundreds of gpio pins were needed and routing prevented the usual huge many pins packages
<MrMobius>
tp, thats cool. what kind of boards?
<Zarutian_HTC>
MrMobious: and spi bus is about 4 or five wires/traces
<tp>
MrMobius, commercial video game boards
<veltas>
I2C the future
<MrMobius>
nice
<Zarutian_HTC>
veltas: sometimes i2c isnt fast enough or you get addressing collision issues
<tp>
MrMobius, huge boards made by Atari, asteroids, armour attack etc, all vector scan graphics
* tp
hasn't used I2C yet, prefers SPI
<veltas>
Zarutian_HTC: Yeah but usually not, and you have the I2C priority algorithm which is just genius
<veltas>
tp: Do you know much about it? It's pretty genius
<veltas>
SPI is the simplest way of doing a reliable simple serial connection to a device, I2C is like finesse
<tp>
veltas, no, I'm apprehensive of I2C after looking at the SPI peripheral config
<Zarutian_HTC>
tp: re pcb design and manifacture: not so much as two layer boards are etched usually. Costs go up for more kinds of chips though
<tp>
veltas, I will get to it tho, Im slowly working my way thru the STM peripherals
<veltas>
Cool
<tp>
veltas, when I have a Forth project working with a peripheral I always write an article about it on my Mecrisp-Stellaris unofficial doc website
<tp>
veltas, my last one was the stm32 'touch' peripheral
<veltas>
What kind of interface did that have?
<Zarutian_HTC>
tp: cost is usually the pick'n'place nest setup fee. The fewer kinds of components you have the cheaper it is. This is why one sees for instance two 1k resistors in series instead of one 2k resistor.
<Zarutian_HTC>
a change of capacitence sensor, no?
<tp>
Zarutian_HTC, sure, I do have a lot of SMT p&p experience
<Zarutian_HTC>
bloody hand when you can put "buttons" right in the pcb layout and not fiddle around with buttons that wear out
<tp>
Zarutian_HTC, yes, I was expecting the 'touch' sensor implementation to be dodgy and unreliable, Imagine my surprise when I discovered the opposite
<veltas>
tp: I find these capacitive sensors interesting even though I actually *hate* using them in anything other than phones
<tp>
Zarutian_HTC, my SMT experience was when I ran a commercial SMT assembly factory for a year up until 1990
<veltas>
Had a bloody capacitive sensor on an electric weighing scale and it would never detect my touch correctly, always resetting when it was meant to tare etc
<veltas>
Buttons are underrated
<tp>
veltas, my experience is that they will work well on certain projects I have planned
<veltas>
I bet your ones work correctly tp
<tp>
veltas, they sure will
<veltas>
You seem to have what Linus Torvalds calls 'taste'
<Zarutian_HTC>
now we just need something like cheap elwire paint or laminate then one could make a board that has one mcu as the main component and a battery as the second
<veltas>
So I could trust you to make a button not total shit like these scales ;)
<tp>
veltas, well mine wont be for commercial products, just my own hobby gear so I dont have to worry about the usual hassles
<tp>
veltas, but in my testing here, the touch is flawless
<Zarutian_HTC>
heck, I saw a four banger calculator that used cheap b&w epaper, capacitance touch and solar cell recentilyish
<tp>
I even have some excellent new projects that use it for other utterly unrelated projects
<veltas>
tp: You're making me want to buy a blue pill and play around with it
<tp>
veltas, they suck, I recommend a STM32 Discovery or Disco board
<tp>
veltas have you read my Bluepill 'rant' ?
<Zarutian_HTC>
(it was meant to be one of these giveaway items or confrence swag)
<Zarutian_HTC>
though such a thing could be usefull for 2 factor authentication device
<tp>
Zarutian_HTC, I have a lone STM32F051 on a pcb, I hand deadbugged it with a soldering iron the size of two chip pads. It runs Mecrisp-Stellaris with only a external filter cap
<Zarutian_HTC>
hmm, loose the fr4 pcb and use a vinyl cutter to make a layered 'sticker' circuit?
<tp>
nah, I like Fr4
<tp>
Im doing my new prototyping using teflon composite and copper rivets
<veltas>
tp: I also like this critique of the 6502 because that really is a garbage processor, the 'super fast' 2MHz 6502 in the BBC Micro was actually about as fast as a 3.5MHz Z80 you could get in a ZX Spectrum, a much cheaper computer
<tp>
crc, that's a really high end mcu full of resources and very fast, hard to get something more complex
<crc>
hmm, any recommendations for a simpler one with at least 256k of ram?
<tp>
veltas, theyre both ancient now, tho I realise that there are many fans of both chips
<veltas>
Yeah I know that
<veltas>
I wonder if the ttmrichter you meantion is the same one I've encountered on IRC
<veltas>
mention*
<tp>
crc, um, thats a hard question as 256kB ram is usually only found in the high end stuff
<tp>
veltas, there is only ONE ttmrichter!
<tp>
crc, I made a 'solid particulate' detector for the grain processing industry in 1998, and the MCU in that had 72 bytes of ram iirc
<tp>
it was a PIC MCU with 1k of flash
<tp>
and my firmware used maybe 800 bytes of flash and 20 bytes of ram
<tp>
thats the areas I work in, but my $0.56 STM32F051'a have 64kB flash and 8kB ram which is IMMENSE to me
<tp>
crc, perhaps youre looking for something like a RPI which have a lot more PC type resources, but a lot less embeded peripherals ?
<crc>
I'll need a fair amount of ram to run retro. I've done a cut down version in 64k, but more is better fpr my purposes
<tp>
plus one can get a small form RPI for $5 with wifi
<crc>
tp: I have one of those already
<tp>
ahh
<tp>
ok, then I guess the 32f769idiscovery is probably the one for you, does it need a LCD ?
<crc>
I don't need an lcd
<tp>
you can probably get them in a LCD less Disco for much cheaper
<tp>
ill have a look
<veltas>
tp: I think your article is mostly right applied to baremetal code
<tp>
veltas, wow
<veltas>
About issues with C
<tp>
yeah, it's very frustrating in a C oriented world
<veltas>
The stuff ttmrichter said is in a totally different direction and I'm not sure I agree with him
<tp>
hes very polarising
<tp>
people love him or hate him
<veltas>
I think the issues you have with C code is more to do with the programmers than the language
<tp>
Im in the former category
gravicappa has quit [Ping timeout: 258 seconds]
<tp>
in that case all embedded C programmers in the world are very dissapointing to me
<tp>
*all*
<veltas>
You could write C code that doesn't abuse most of the stuff you complain about
<veltas>
Well I work in this industry and I can see what you're talking about
<veltas>
I think we find it hard sometimes to nail down the 'right' way to write maintainable code that has a good mix of baremetal secrets and maintainability.
<veltas>
Most of us don't get it right
<tp>
veltas, i CAN SEE YOU DO
<tp>
oops sorry caps
<veltas>
lol
<tp>
C hides stuff, I blame C not the programmers
<jackdaniel>
this caps gives a punch to your message
<tp>
jackdaniel, it was a accident I assure you
<veltas>
tp: It's more like if you have a pretty hammer everything looks like a nail
<veltas>
The C 'hiding stuff' is a really good idea, for what it's for, and that is writing high-level structured systems code. It is *not* for writing drivers or baremetal code
<veltas>
Even the people who invented C mostly used assembly for that
<tp>
veltas, I think that all of the embedded C programmers on line have no idea that their examples are deficient
<tp>
veltas, yeah I get that, but they hide stuff *first* not later
<tp>
I 'hide' my Forth embedded config stuff as it's ugly and Forth programmers throw up when they see it
<tp>
event tho Ive worked on making it less ugly for years now
<tp>
here is a small part of the config that my 'touch sensor' code uses
<tp>
\ ------------------------------------- Config Words ------------------------------------------- \
<tp>
: RCC_AHBENR_TSCEN ( -- x addr ) 24 bit RCC_AHBENR ; \ RCC_AHBENR_TSCEN, Touch sensing controller clock enable
<veltas>
'However C is not interactive like Forth. If you want to test a LED, you have to write a program to turn the led on, then compile and flash that program into the target.'
<Zarutian_HTC>
tp: you are absolute madman for handsoldering a ball grid array like that
<tp>
Zarutian_HTC, at age 66 ?
<tp>
heheh
<veltas>
waaaat
<Zarutian_HTC>
at any age
<tp>
lol
<veltas>
What size BGA was this?
<tp>
64 pin, 0.5mm spacing I think
* veltas
staggers away
<tp>
Zarutian_HTC, it's part of my next plan for lowering hardware costs
<tp>
veltas, I do have trouble with 0.4mm spacing BGA's
<veltas>
Should've been a brain surgeon right ;)
<tp>
but I need to use them, so I'm working on some mechanical assistance
<tp>
I have the hands of a brain surgeon for sure
<tp>
my hands have always been absolutely rock steady
<veltas>
Regarding interactibity, you can absolutely do this in C and for some reason few if any C programmers will do it this way, sometimes the fact that Forth gets you to *think* with that level of interactivity and modularity it's better
<tp>
so thats a plus, not that Im able to imagine what unsteady hands are like
<tp>
veltas, how do you provide instant low level hardware interactivity with C ?
<veltas>
I think C actually is *simpler* than Forth in the respect that it is a compiled language, but that doesn't mean you can't load in and/or swap out C code at runtime, or write your own 'commands' and/or simple scripting into it
<tp>
Ive used C since 1997 and Ive never seen that
<Zarutian_HTC>
tp: it isnt hand steadyness that I am impressed with but sheer self control
<tp>
Zarutian_HTC, whats a life withot some self control ?
<tp>
I definitely need MORE self control tho
<Zarutian_HTC>
veltas: C is more complex. Just look at a C compiler.
<tp>
Zarutian_HTC, my next batch of rivets will be made soon as I remake the jig, I'll have some very cool pics then!
<veltas>
Zarutian_HTC: I said in that respect, I'm not going to say C is simpler in general because it is clearly not
<veltas>
But C has no notion of interpreter, or execution vs compilation, it is just a 'compilation' language.
<tp>
have the essential connection on the outer balls
<tp>
because of the horrific bga spacing and connection metalisation, theyre fragile and a bastard to hand solder, but they are PACKED with resources and dirt cheap
<tp>
Ultra-low-power 32-bit MCU Arm® Cortex®-M3
<tp>
384KB Flash
<tp>
48KB SRAM
<tp>
12KB EEPROM
<tp>
LCD, USB, ADC, memory I/F, AES
<tp>
Low Power, 305 nA Standby mode
<tp>
so I'll be using one soon in a teflon composite pcb with rivets running Mecrisp-Stellaris :)
<tp>
now hobbysists wouldnt ever consider using one of these in a conventional BGA layout, but my hand soldering and rivets to selected pins only means I can easily use one in a design that only needs a gew pins
<tp>
-g+f
<tp>
next I plan to try soldering to those 0.4mm BGA's with a laser
<Zarutian_HTC>
doesnt sparkfun or adafruit sell bga breakout boards?
<tp>
probably but theyre not suitable for me
<tp>
I hate 'breakout boards'
<tp>
the whole BGA soldering process is fairly specialised, my hand soldering a few wires to only the outer balls gets around a lot of the hassles (I hope)
<tabemann>
back
<tabemann>
hey guys
<tp>
always experimenting like spacex but my failures are mostly too small to see ;-)
<tp>
hey tabemann
<tabemann>
veltas: with zeptoforth, I can at the REPL issue something like led-red-on, and lo and behold, the red led turns on; to turn a red led on with C requires compiling a binary and downloading it onto the board and rebooting
<veltas>
You can dynamically load code with C, not sure about with your setup though
<tp>
tabemann, you *can* connect to the STM32 in GDB over SWD or JTAG and change a register to turn the led on/off, but thats the only other way I know other than compiling a C program to do it
<tp>
(or using forth)
<veltas>
GDB is awesome it's like interpreted C
<veltas>
Sorry tp
<tp>
veltas, it's slow and complex compared to Forth in my own personal experience
<veltas>
Yes it is
<veltas>
I was saying sorry because I was being enthusiastic about something aimed at C development :P
<veltas>
And I know how much you loathe it
<tp>
veltas, when I started learning Forth in 2014 I had been using C since 1997. I promised myself that if I couldnt make a Forth development environment that was faster than the C alternatives, then I wouldnt use Forth, I'd stay with C
<tp>
veltas, I like C code for a PC, it's embedded C I loathe
<tp>
veltas, dont make me paste C bit manipulation examples here! ;-)
<tp>
veltas, by "dynamically load code with C" do you mean the usual code compile cycle with loading it into RAM on the target instead of flashing ?
<tp>
veltas, cause thats still NOT 'interactive'
<tp>
well it's about as interactive as a phone call to someone on Alpha Centuri ...
<tabemann>
back
reepca` has quit [Read error: Connection reset by peer]
<tabemann>
tp: I think veltas means using stuff like dlopen() on linux
<tabemann>
which still involes a code-compile-run cycle
<tp>
thats a area I have no expertise in, but on embedded Ive never seen any interactive C
<tp>
and I never will
<tp>
unless someone took a Forth and renamed it to 'interactive C' ;-)
<tabemann>
I can't imagine how one could make C on embedded dynamic in the way that Forth is
<tabemann>
like my led-red-on example
<veltas>
It doesn't come out the box I'm just saying C is capable of it
<tabemann>
the only way I can see doing that in C is embedding an interpreter for another language, such as Forth, in hte C
<tp>
me neither, Ive used BASIC, micropython and eLUA on embedded in addition to Forth (they all suck badly compared to Forth)
<veltas>
An example that comes to mind is the shell scripting in das u-boot
<tp>
and oddly, people do that!
* tabemann
at one job embedded Lua in C++ - this wasn't embedded though
<veltas>
I have embedded Lua, it's easy. Not in 'embedded' dev though either lol that would not be as nice
<tabemann>
Lua is too heavy-weight to easy go on many embedded platforms
<tabemann>
easily*
<veltas>
I am *here* because I suspect Forth might be 'nicer' than any of these, I don't have my answer yet
<veltas>
But I am encouraged by the endorsements here
<tabemann>
mecrisp-stellaris will fit in under $4000 bytes of flash
<veltas>
That is impressive
<tabemann>
zeptoforth is a little more weightly, probably because I'm not quite as good at optimizing assembly as matthias
<veltas>
Careful you don't accidentally say "$4000 of flash" because you can actually fit quite a bit in $4000 of flash lol
<tabemann>
and because I made some decisions in the compiler design that made it more space-heavy
<veltas>
Especially these days
<tp>
veltas, didnt das u-boot get hit by a depth charge and sink ? ;-)
<tabemann>
when one compares it to microPython or eLua, it's very lightweight
<veltas>
tp very funny :P
<tp>
veltas,its awesome to see you here in your early evaluation stage
<tp>
veltas, and Forth isn't for everyone, after one accepts forth, Forth still has to accept them ;-)
<tabemann>
of course the second step at using forth is to write a forth
* tabemann
has written three of them
<tp>
tabemann, not for techs it's not
<veltas>
tabemann: I'm in the middle of writing mine atm
<veltas>
Actually tp after reading the critique you made of some embedded Python thing I realise I need to support running Forth inside interrupts
<tabemann>
what platform, language, and architecture?
<veltas>
I know real Forthers would accept no less
<tp>
tabemann, you don't ?
<veltas>
tabemann: ZX Spectrum, Forth, Z80
<veltas>
Unless you mean by which language am I starting from which is an assembler
<tabemann>
yeah
<tp>
tabemann, support running Forth inside interrupt handlers ?
<tabemann>
yep
<tp>
lol, I didnt even realise that was a problem as Mecrisp-Stellaris always had that as long as Ive been using it
<tp>
the things that us Forth users take for granted!
<veltas>
It's not a big problem, it just affects the code I'm writing right now
<veltas>
It should actually be quite easy to add, and I imagine in Python.. it's not.
<tp>
well python is manifestly unsuitable for embedded. along with Ulisp and eLua
<tp>
the reason is that you cannot have garbage collection in embedded
<tp>
it's just 100% not allowed
<veltas>
Weirdly (?) enough this is not just a problem in embedded, it's a general issue with multitasking + GC
<tp>
micopython is a example of programmers with zero real world embedded experience at work
<tp>
veltas, it's not 'a problem' in embedded, it's not allowed
<tp>
the reason is that embedded is 'real time'
<tabemann>
people wonder why there is a ~kilohertz or so thing doing on in their code and not realize it's the GC
<tp>
I may scan a special signal (for example) every 5 us and to miss one will result in total system failure
<tp>
a GC takes a few Mecrisp-Stellaris and during this time the MCU can't scan my special signal --- total FAIL
<veltas>
You can totally avoid GC actually occuring in well-written programs, but I suspect a lot of people writing Python etc in embedded don't realise this in the first place.
<tp>
oops Mecrisp-Stellaris = (ms)
<tp>
veltas, I think the python in embedded pople use it because it's supposed to be easy
<veltas>
Hmm
<tp>
theyre also the people who complain about reading a suitcase full of ARM tech docs
* tabemann
doesn't find ARM tech docs to be a problem
<tp>
and the excuse "I dont have the time"
<tp>
tabemann, thats because youre a closet embedded wannabe ;-)
<tabemann>
tech docs haven't stopped zeptoforth from being ported to four platforms by now
<tp>
tabemann, the spacex of cortex-m4 forths!\
<tabemann>
I should port zeptoforth to a cortex-m3 board as well
<tabemann>
cortex-m0 just isn't happening though
<tp>
tabemann, after watching your progress, I doubt there is much that can stop you
<tp>
tabemann, thats cool, I already have a perfectly good cortex-m0 one
* tabemann
right now is trying to figure what the issue is with his [if] ~ [else] ~ [then]
<veltas>
Isn't [then] a no-op?
<tabemann>
the reason being is that it's based directly off of working code for a different forth of mine
<tabemann>
veltas: it's detected by [else] to frob a counter
<tabemann>
when by itself it is a no-op
<tp>
veltas, it's a "non-op" in tabemanns case right now ;-)
<veltas>
I'm mixing up [then] with (then)
<veltas>
(then) doesn't exist
<veltas>
I think?
rogerlevy has left #forth [#forth]
<tp>
I normally only frob a turbo-encabulator
<tp>
and even then only if therecirculating frimfram is embogled
<tabemann>
I said "frob" because one could increment or decrement a counter
<tp>
frob - Computer Definition
<tp>
To manipulate and adjust dials and buttons for fun. From the term "frobnicate," of course.
<tp>
The TMRC definition was “FROB = a protruding arm or trunnion”; by metaphoric extension, a frob is any random small thing;
<tp>
well I learnt a new word today :)
<veltas>
^
<tp>
one is rarely bored on #forth!
<veltas>
Yes
<veltas>
It's one of the most active IRC channels I'm on, which I would've bet against before coming here