<tp>
tabemann, what two nordic boards did you get ?
<tabemann>
back
<tabemann>
I only got one board
<tabemann>
the nRF52840
<tabemann>
I ported to the nRF52832, but never tested it
<tp>
ah
<tabemann>
as the only purpose of that port was to facilitate a port to the nRF52840
<tp>
bit hard to test with no board
<tabemann>
someone can still try it if they want
<tp>
good pint
<tp>
point
<tp>
once you get a following people will try
Keshl has joined #forth
<tp>
matthias has the right approach tho, he makes people who cry for help actually make some effort first
<tp>
becase sadly some are like that peter anonymous guy who do nothing and expect everything
<tp>
hence just timewasters
<tp>
and the first thing to do if someone wants a port is aske them to send you a board, no board, no interest
<tabemann>
if no board, I'd say they have to implement it themselves
<tp>
yeah
<tabemann>
because I'm not going to just buy any old board because you want me to implement it for you
<tp>
matthias advises that a port is mostly a matter of grabbing the closest chip supported by Mecrisp-Stellaris and changing the USART
<tabemann>
if you want me to implement it for you, at least go out and get the damn board and send me it
<tp>
exactly
<tp>
even then thats damn cheap considering how cheap most boards are
jsoft has joined #forth
<tabemann>
like I think I'm already done with my nRF52840 port, aside from figuring out which pins to use
<tp>
I mean send you a $20 board and expect you to spend a week on it ?
<tp>
just ignore the time wsters
<tp>
Ive learnt a lot trying to help Mecrisp-Stellaris users
<tp>
wow, thats fast!
<tabemann>
I already have an nRF52832 port
<tabemann>
which was itself based heavily off the nRF52832 port of Mecrisp-Stellaris
<tabemann>
the port was really just going through the code and checking whether anything that changed, which turned out to be a minor change in how interrupts are implemented for the UART
<tp>
of course, you just changed the name from "Mecrisp-Stellaris" to "Zeptoforth"
<tp>
thats what most people do thesedays
<tp>
;-)
<tabemann>
it wasn't that simple - when I did my nRF52832 port I had to rework the flash system to allow flashing units smaller than aligned words
<tp>
nice
<tp>
what was the nordic flash controller like to work with ?
cantstanya is now known as Oxford
Oxford is now known as frank
frank is now known as cartwright
cartwright is now known as cantstanya
Croran has quit [Remote host closed the connection]
Croran has joined #forth
<tabemann>
back
<tabemann>
tp: it was quite simple
<tabemann>
essentially set one bit to enable writing to flash, then just write to the target word, then unset the bit
<tabemann>
wait
<tabemann>
that's writing to flash
<tabemann>
erasing flash is also simple
<tabemann>
write to one bit to enable erasing flash, then write the address of the block of memory to erase to a register, then unset the bit
<tabemann>
note that both of these have ready-wait loops too
<tp>
nice
<tabemann>
ugh ugh ughitty ugh
<tabemann>
it turns out that programming over USB requires a preprogrammed bootloader
<tabemann>
which of course zeptoforth won't be compatible with
<tabemann>
otherwise you have to use the headers on the board itself
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tp>
no standard bootloader present ?
<tp>
the SWD headers to a disco board ?
<tabemann>
there is a bootloader which comes with the board
<tp>
but ...
<tabemann>
the problem is that zeptoforth requires taking up the vectors
<tabemann>
while the bootloader requires that it take up the vectors
<tp>
what does that mean ?
<tabemann>
and the bootloader is designed to work with proprietary tools
<tabemann>
the exception vectors
<tp>
configuring the vectors ?
<tabemann>
as you say, I could use one of my disco boards to program the board via the SWD header on the board
<tabemann>
but the problem is that that require soldering
<tabemann>
and pretty fine soldering at that
<tp>
nah, it's std header pins, you can do it!
<tabemann>
they're not pins
<tabemann>
they're just pads
<tp>
theyre "half holes' which are actually easier to solder
<tp>
trust me here ...
<tabemann>
if they were pins I'd just buy some dupont jumpers
<tp>
i mean theyre half holes meant to take std 0.1" pin headers
<tabemann>
no, they're not that
<tp>
they save a bit of pcb also, hence lowering the cost to the manuf
<tabemann>
and I know because I've got the board right here with me
<tp>
is yours the same as the pics I posted the otehr day ?
<tp>
can you post a link to a pic of yours ?
<tabemann>
the pads are on the bottom of the board, not the half-holes on the edges
<tp>
oh!
<tp>
are those pads blind, ie no hole ?
<tabemann>
yes
<tp>
ouch
<tp>
and very small ?
<tabemann>
they're wide but thin
<tp>
like edge connectors ?
<tabemann>
except they're not on the edge of anything
<tp>
i think that shows the pins, youre also correct about the signals being on P1
<tp>
not having a connector on P1 and a cable supplied is criminal imho
<tp>
how the *uck are users supposed to use this thing
<tp>
I guess that $10 boards are for the well equipped electronics tech
<tp>
the $100 board is for programmers .. :)
<tp>
my soldering iron was $550
<tp>
of course there are much cheaper irons
<tabemann>
back
<tabemann>
at least they should have put through holes for P1
<tabemann>
because I could see myself soldering a male dupont cable into a through hole
<tabemann>
(I have a soldering iron somewhere around here)
<tp>
gees I think youre right
<tp>
the doc info is just pathetic
<tp>
youll have to use DFU to flash the board
<tp>
and no GDB until you can connect to that poxy P1
<tabemann>
and I'll have to figure out some means to get around not having direct access to exception vectors
<tp>
they make a nice expensive cable I think
<tabemann>
I'm glad I didn't spend any more than 10 bucks on this
<tp>
one with 'pogo pins'
<tp>
well it's always been $10
<tp>
the $100 version has the right connectors :P
<tabemann>
I'm sufficiently pissed off that I'm not going to buy that $100 board out of spite even though, technically speaking, I can afford it, especially since I'm not spending any other money thanks to this virus
<tp>
honestly tabemann I just dont get it
<tp>
what did a arnold palmer coffee cost you in the pre covid-19 days when you had coffee shops ?
<tabemann>
like about $5
<tp>
I bet you spend $5 on a coffee then bitch endlessly about a complex board with a M4 and wireless for $10
<tp>
I'm old, pleas eignore my r`ant
<tp>
coffee is so expensive here that most Americans wont pay for one
<tp>
lol
<tabemann>
part of it is also that I think that the expensive Nordic boards are, well, overpriced when compared to the STM DISCO boards
<tp>
$10 is nothing, I'd personally GIVE you $10 if you could drop in here
<tabemann>
$10 is nothing
<tp>
no it's not that, it's just that STM is MASSIVE, they practically give their boards away
<tp>
nordic cant afford that
<tp>
nor can NXP
<tabemann>
the thing is also this
<tp>
pe`rhaps STM have to do that because their MCUs are pretty ordinary compared to Nordic ?
<tp>
I mean I have NXP and SILABS boards here Ive never been able to use, all windows oriented or special hard to get connectors
<tabemann>
if Nordic is going to make me deal with either a stupid proprietary bootloader which makes me modify my code to work around it OR a stupid set of pads on a board so I can have SWD that are impossible for myself to solder, who is to say that they won't do something similar with one of their expensive boards?
<tp>
sure, reasonable question
<tp>
I think this mainly shows how super friendly STM boards are ?
<tabemann>
I'm glad at least that I bought the DONGLE first, so I knew what kind of things to watch out for, rather than having bought an expensive board, and then gotten fucked over after spending that money
<tp>
norsic, nxp, silabs all make stuff thats expensive and hard to use
<tabemann>
I'm glad I only spent $10
<tabemann>
lesson to self: stick with STM boards, at least theirs are friendly (and their downsides, such as short pins, are minor compared to the alternative)
<tp>
youre glad you only spent 1.6 Arnold Palmers ?
<tp>
think of the calories you saved ?
<tp>
ah well, it was a good exercise, the chip is excellent, the dev boards really suck
<tp>
and you got out of it for the price of 1.6 Arnold Palmers
<tp>
and you can STILLprogram it with DFU
<tabemann>
I can still program it with DFU, yes
<tabemann>
I just will have to figure out how to rework zeptoforth so it's compatible
<tp>
I have to program my RISC-V boards with DFU, no problem even with FreeBSD and the BROKEN GD32VF103 DFU bootloader
<tp>
well I dont have to, I can solder on pins to the SWD pads
<tp>
but DFU is just easier
<tabemann>
how is Mecrisp-Stellaris compatible with a DFU bootloader? does it just not use exception vectors (as I know that Mecrisp-Stellaris does not out of the box)?
<tp>
DFU is just a bootloader
<tabemann>
because a key difference between Mecrisp-Stellaris and zeptoforth is that a fully configured zeptoforth system uses SysTick and USART interrupts and Mecrisp-Stellaris does not
<tp>
it doesnt have any special requirements in comparison to the serial bootloader or SWD
<tp>
yeah, but thats independent of the bootloader
<tabemann>
but the DFU bootloader for the DONGLE takes up the first $1000 of flash
<tabemann>
which contains the vectors
<tp>
ARM also had DFU
<tp>
hmm id the nordic DFU bootloader in volatile flash ?
<tp>
thats nuts
<tabemann>
there are two sections of flash taken up by it
<tp>
hmm
<tabemann>
both low flash and high flash
<tp>
I know that the STM32F103 doesnt come with a DFU and one needs to be flashed in if needed
<tp>
but the serial bootloader is in rom on all stm32
<tp>
also the serial bootloader works with I2c etc
<tp>
but I used the DFU on the GD32VF103 many times and flashed Mecrisp-Stellaris meny times
<tp>
do DFU is obviously in rom on the GD32VF103
<tp>
do = so
<tp>
plus Mecrisp-Stellaris does set the vecrors
<tp>
vectors
<tp>
only the reset and interrupt vector is required to be preset
<tp>
or maybe only the reset vector, I cant recall
<tp>
bbl, youll be asleep by then, good luck!
<tabemann>
back
jsoft has quit [Ping timeout: 265 seconds]
jsoft has joined #forth
proteus-guy has quit [Ping timeout: 264 seconds]
proteus-guy has joined #forth
gravicappa has joined #forth
jedb_ has joined #forth
jedb has quit [Ping timeout: 250 seconds]
rdrop-exit has joined #forth
reepca has quit [Ping timeout: 250 seconds]
tp is now known as tp___
reepca has joined #forth
reepca has quit [Read error: Connection reset by peer]
reepca` has joined #forth
xek has joined #forth
<veltas>
rdrop-exit: Regarding P@ P! PB@ PB! is that from an existing Forth?
<veltas>
For PORT fetch etc
<rdrop-exit>
hi Veltas, IIRC p@ p! were common on x86/z80 Forths (native, CPM, DOS)
<rdrop-exit>
So were pc@ pc! for single bytes
<rdrop-exit>
Myself I used pb@ pb! for single bytes, but that's a personal affectation
<rdrop-exit>
I'd have to dig to name specific Forths
<rdrop-exit>
Let me check my shelf
<rdrop-exit>
ok, according to All About Forth 3rd Edition:
<rdrop-exit>
F83 and FP-C had p@ p! pc@ pc!
<rdrop-exit>
FIG also
<rdrop-exit>
MVP had pw@ pw!
<rdrop-exit>
MVP used pw@ pw! for words, p@ p! for bytes
<rdrop-exit>
LaForth also used p@ p! pc@ pc!
<rdrop-exit>
I don't recall what eForth for x86 uses
<rdrop-exit>
Note, when earlier I mentioned F83, that's a particular Forth system, i.e. Laxen & Perry's F83, not to be confused with the Forth 83 standard itself
<rdrop-exit>
HS/Forth (Harvard Softworks) uses pw@ pw! for words, and p@ p! for bytes
<rdrop-exit>
I suspect the most common was p@ p! for words, and pc@ pc! for bytes, but by no means universal
<rdrop-exit>
Myself, I tend to use "b" for byte, instead of the more common "c" for character
<rdrop-exit>
I can't recall if if any Forths used something other than "p" for port I/O
<rdrop-exit>
You'd need to dig through the old Forth Interest Group archives
jsoft is now known as jsoft_
jsoft_ is now known as jsoft
jsoft is now known as jsoft__
jsoft__ is now known as jsoft___
jsoft___ is now known as jsoft
tp___ is now known as tp_
tp_ is now known as tp__
tp__ is now known as tp
rdrop-ex1t has joined #forth
rdrop-exit has quit [Read error: Connection reset by peer]
<rdrop-ex1t>
It seems MMS also used p@ p! pc@ pc!
reepca` has quit [Read error: Connection reset by peer]
reepca`` has joined #forth
iyzsong has joined #forth
WickedShell has quit [Remote host closed the connection]
webchat9 has joined #forth
rdrop-exit has joined #forth
rdrop-ex1t has quit [Read error: Connection reset by peer]
dddddd has joined #forth
reepca`` is now known as reepca
rdrop-exit has quit [Read error: Connection reset by peer]
<veltas>
Is there an easy way of sending a message to rdrop *when they're on*?
<veltas>
I want to reply but we seem to have an almost perfect complement of activity
<tp>
/msg boo rdrop-exit
<veltas>
Thanks
<tp>
oops
<tp>
it's /msg rdrop-exit boo
<boru>
There's also the freenode service memoserv; /msg memoserv help
<tp>
hey boru!
<boru>
Hey tp. Long time no see, old chap.
<tp>
boru, so true, time flies when one is having fun
<boru>
Indeed it does. How are things?
<veltas>
Thanks boru that's what I was after
<boru>
Sure, you're welcome.
iyzsong has quit [Ping timeout: 265 seconds]
proteus-guy has quit [Ping timeout: 256 seconds]
dave0 has quit [Quit: dave's not here]
webchat9 has quit [Ping timeout: 264 seconds]
proteus-guy has joined #forth
webchat9 has joined #forth
<crest>
tp: i managed to get something close to your screen setup working with picocom and tmux
<tp>
crest, wow, thats impressive
<tp>
all automatic ?
<crest>
make upload
<crest>
invokes tmux send-keys -t $SERNUM:0.0 ...
<crest>
that tells picocom to upload a file
<crest>
the picocom send command is a shell script
<tp>
well thats as automatic as me!
<crest>
this shell script queries the forth system is a word is in the dictionary
<crest>
and if it's defined skips the upload
<tp>
and can you do multiple connection ?
<crest>
to multiple forth systems or multiple makes in parallel?
<crest>
both should be possible with a simple lock file including the serial number
<crest>
the problem is that my solution includes a sleep 0.1 to give picocom time to spawn the upload command
<tp>
I have a few and longer than that
<crest>
i need something better than a race condition by design
<tp>
yeah, a purpose program
<crest>
the right solution would be a smarter picocom replacement
<tp>
I meant I process the rx data from the MCU separately with screen so I have a parser to make the error RED and beep the bell
<tp>
screen feeds it to a shell script with SED
<crest>
so you have nothing to stop after the first error either?
<crest>
because a sending code line by line would be nice
<crest>
to stop at the first error
<crest>
and print the the line number
<tp>
no, not in the terminal system, but I can stop on error with a kernel mod I did
<crest>
does that include a line counter that can be reset?
<tp>
it just uses hardware handshaking and a error raises CTS
<tp>
no, I have to reset the board anyway
<tp>
I upload everything every iteration
<crest>
not after successful uploads
<crest>
lets say i want to upload a few files and the first two succeed
<tp>
sure, right up until the final upload
<tp>
when the project is turnkey
<crest>
it would be nice to get to line number that failed in the last file
<crest>
not just the total number of lines processed
<tp>
i get the error in red and just mousewheel up to see it
<tp>
after that I stopped using hardware handshaking to find the error
<crest>
a special purpose replacement for ascii-xfr could upload each line and parse the response
<tp>
crest, hmm Im getting more and more suspicious that you're a programmer ... ;-)
<crest>
tp: you're on to something :-P
<tp>
heheh
<tp>
as you said I see youre using Expect
<tp>
thats pretty slick
<crest>
yeah but i got rid of it because i simplified my code
<crest>
at the moment zsh is enough
<tp>
but I wont do that, I prefer to reupload all the new source everytime
<crest>
maybe if i want more i
<crest>
'll return to expect
<tp>
which is why I run the MCU as fast as it will go and use the hightest serial rate I can
<crest>
how much buffering would be required on the uC to make software flowcontrol work?
<tp>
I dont use any
<tp>
all I do is enable RTS
<tp>
thats all it needs
<tp>
and connect the MCU RTS to the PC CTS
<tp>
oops!
<tp>
you said software ...
<tp>
I dont know, tabemann is the expert there
<tp>
I only do hardware flow control
<crest>
the unofficial documentation states that part of the problem with software flowcontrol is that the host and usb<->serial adapter contain buffers
<crest>
and modern desktop operating systems are slow to respond compared to a microcontroller
<crest>
but how slow?
<crest>
is a 128 bytes buffer enough to get software flowcontrol working?
<crest>
that would save two wires after all
<tp>
i tried XON/XOFF and had a big fail
<tp>
tabemann, had problems but then swiched to some ACK/NAK system and said it's flawless
<crest>
so i can now upload multitask.txt and blinky in 0,3sec
<crest>
most of that is spend waiting 100ms for picocom to spawn its send command
<tp>
wait ... you mean I've a competitor in the 'fastest Forth feeder' sweepstakes now ??
<tp>
crest, now it's so fast, you need that bell
<tp>
or you will miss errors
<crest>
sure
<crest>
do you remember under which condition your old image prints "ok." in red?
<tp>
hidden there like CoV-19 in a bat is the bell escape sequence
<veltas>
lol
<veltas>
It's weird how one of the most active channels I'm in is #forth
<crest>
\007
<crest>
doesn't the compiler throw an exception on compile errors?
<tp>
crest, no
Zarutian_HTC has joined #forth
<tp>
i asked for that ages ago
<veltas>
tp: Also CoV-19 isn't in bats, it's SARS-CoV-2. CoV-19 is the disease of the virus SARS-CoV-2 activating in a human
<tp>
but matthias is like the god of Forth, he doesnt need stuff like that
<veltas>
It's like the difference between AIDS and HIV
<tp>
veltas, oops!
WickedShell has joined #forth
<tp>
veltas, thanks for that, I realise youre right
<crest>
veltas: technically correct
<veltas>
The most annoying thing right now is people 'correcting' me and saying it's "COVID-19" and not "coronavirus", even though "coronavirus" is actually more accurate if you're talking about the virus
<veltas>
People prefer the name "COVID-19" because it sounds more 'official'
<tp>
well 'coronavirus' sounds like a trademark to me ;-)
<tabemann>
back
<veltas>
I want my Forth to print RED errors too, might even be flashing
<veltas>
I think I will customise ABORT" to do that
<tabemann>
COVID-19 is annoying
<tabemann>
I made zeptoforth ring a bell when there's an error
<veltas>
I might beep
<tabemann>
I've gotta figure out how to log with screen
<tp>
tabemann, e4thcom will log
<tp>
tabemann, I have a shell script for that
<crest>
looks like the compiler doesn't provide a nice hook for error handling