<tp>
crest, religious scm debates aside, I think your take on a new Forth terminal is exciting
<tp>
that's the kind of stuff I find really interesting, I'm just a scm user
<crest>
i won't file any ridiculous software patents on it. feel free to implement it :-P
<tp>
crest, feeling free and having the capabality are two different things
<tp>
my system works perfectly for me and I understand it
<tp>
it works so well that I never worry about it, projects just get built and the work only involves the project
<tp>
I have no intention to spend another 4 years developing something else to do the same thing in a better or more modern network centric way
<crest>
too bad
<tp>
I read about people using C and eclipse waiting 5 minutes to compile a small project etc, Id give up developing if that applied to me
<tp>
I wait for almost nothing, the longest is building a binary release from the chip itself, which while being fully automated can take 30 seconds
<tp>
that release also includes a readme in html, two copies of all (non kernel) source, one with comments and one without, a Word list etc
<tp>
everything needed to rebuild the project using whatever Forth terminal system you use
rdrop-exit has joined #forth
djinni has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
<tabemann>
hey guys
<crest>
tabemann: have you ever written directly to the sram with the stm32* running while debugging your forth?
<tabemann>
you mean use gdb to do so?
<crest>
yes while the core is running
<tabemann>
no I haven't
<tp>
hey tabemann
<crest>
not stop at a breakpoint and debug
<crest>
e.g. change the delay of a delay loop while it's running
<crest>
because if you check the backlog you can find my crazy idea
<crest>
use a pair of ring buffers in sram as console for the forth system
<tabemann>
I'm gonna create a release with teh Debugger shortly
<tabemann>
what I have done is modified fields from the Forth REPL while things are running via multitasking
<rdrop-exit>
good morning Forthwrights c[]
<tabemann>
hey rdrop-exit
<rdrop-exit>
hi tabemann
<crest>
i want to use libstlink-shared to access the ring buffers to get a fast reliable console
<tp>
hey rdrop-exit
<rdrop-exit>
hi tp
<tp>
crest, when I tested micropython on a M4 I was really impressed with their full screen editor, it was awesome to use ... shame about the rest of the micropython tho
<tp>
crest, but that editor was luxurious
dddddd has quit [Ping timeout: 256 seconds]
<tp>
crest, an editor like that for Mecrisp-Stellaris would be hard to resist
<tabemann>
I wonder how much that editor weighs in though
<tp>
I weighed it at the time and came up with 4.5 grams
<crest>
i created a variable in mecrisp st
<crest>
printed its address
<crest>
attached gdb
<tp>
it the editor would have been python based on the pc tho
<crest>
changed it from 23 to 42
<rdrop-exit>
a good undo/redo takes a lot of space
<crest>
and continued the core
<crest>
to print the new variable content
<tp>
crest, thats pretty cool
<crest>
with gdb
<crest>
but it stopped the core to do so
<tp>
I've run Mecrisp-Stellaris under gdb
<tp>
but didnt change anything on the fly from gdb
<tp>
yeah, I think Ive always had to halt the target to change variables etc
<tp>
I dont use gdb much, too complex, too hardware dependent
<rdrop-exit>
just use Forth
<tp>
me too
<tp>
but I have both systems set up and working so I can answer questions from the occasional embedded C user about the diferences
<tp>
Ive tested most open development systems, I even have Eclipse and massive C dev systems here
<tp>
some of the systems are so massive they make a blinky hard work
Labu has quit [Quit: Leaving.]
<tabemann>
back
<tabemann>
I've always just changed things on the fly via Forth
<rdrop-exit>
that's the Forth way, Total Interactive Control (tm)
<rdrop-exit>
:)
_whitelogger has joined #forth
<rdrop-exit>
I was thinking of doing a Forth on JVM, but the spec madfe my stomach turn.
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<crest>
tp: turns out even if you run continue & in arm-eabi-none-gdb connected to the stm32f103 you can't change things without interrupting the thread first
<crest>
i'm not sure if this is a limitation of gdb, the st-util gdb server, st-link v2 or the debugging hardware itself
<tp>
crest, it's not a problem that paying $50,000 for proprietary JTAG gear would't fix I expect :)
<crest>
so far i haven't even looked into the opensource stlinkv2 library *headers*
<crest>
not really at least
<crest>
it could be as easy as open a context to the stlink
<crest>
an read/write memory in bytes and words
<crest>
there is a little bit of documention (short description of each function) in the doc folder of the git repo
<crest>
but nothing about the pre and postconditions for each function
<crest>
or even better a state diagram
<crest>
of how the library is supposed to be used
<tp>
crest, it's a job for a serious programmer like you, besides you thought of it :)
<crest>
but the st-util gdb server should include it all
<tp>
crest, Ive not heard it mentioned before, altho rdrop-exit is using JTAG for his tethered Forth project
<crest>
my only question is how fast is the swd interface and stlink in the real world
<tp>
crest, there is something called 'blackmagic' probe that is supposed to include it all even run on a bluepill
<tabemann>
back
<tp>
crest, 5mb/s
<tp>
welcome back! tabemann
kori has joined #forth
kori has joined #forth
kori has quit [Changing host]
<tp>
crest, swd is super fast
<crest>
tp: is that the realworld bandwidth or just the baudrate?
<rdrop-exit>
using FTDI's MPSSE cable you can go USB to JTAG
<rdrop-exit>
you have to deal with their proprietary drivers/library though
<tp>
crest, thats the bandwidth I think. I first discovered that it's fast when using it with flying leads ... 12" leads FAIL, 3" leads work
<rdrop-exit>
no need for gdb
dave0 has quit [Quit: dave's not here]
<crest>
running."
<crest>
"Instead, a debug interface module is decoupled from the core, and a bus interface called the
<crest>
can access control registers to debug hardware as well as system memory, even when the processor is
<crest>
Debug Access Port (DAP) is provided at the core level. Through this bus interface, external debuggers
<tp>
crest have a look at 'blackmagic probe' and get the blue pill binary, it's bound to be interesting
<crest>
from the defintive guide to the cortex m3
<crest>
so it should be possible
<rdrop-exit>
PC Forth <-- USB<->JTAG --> Target Forth
<rdrop-exit>
or just PC Forth <-- USB<->JTAG --> bare Target
<crest>
i wonder how complex the swd protocol truly is
karswell has quit [Read error: Connection reset by peer]
<crest>
or at least the subset needed for 8 bit sram access
<tp>
crest, there are OSS projects to use a RPI as a SWD programmer, or a blue pill
<crest>
that could be useful to get a feel for the protocol
<tp>
crest, matthias uses JTAG to talk to the MPS430 from a cortex-M4 so it's definitely dooable
<tp>
crest, he does that on the M4 with Mecrisp-Stellaris
<tabemann>
tp: I've officially made a release 0.5.0
<crest>
so my crazy idea is should be possible
<rdrop-exit>
IF you want total interactive control of a target JTAG is the way to go
<rdrop-exit>
no need for gdb, or a terminal program
<tp>
rdrop-exit, SWD is what we use for STM32, it's similar but doesnt have all the extra uneeded stuff that JTAG has
<tp>
tabemann, cool, I'll get that and run it up soon
<rdrop-exit>
tp, if it's simpler and can give you the needed level of control, then cool
<rdrop-exit>
JTAG is definitely not simple
<tp>
rdrop-exit, true, JTAG is designed to connect to everything JTAG enabled on a PCB, SWD is just designed to connect to to STM32 MCU's
<tp>
but both are supported by programmers and GDB
<rdrop-exit>
I went with JTAG because RISC-V has a fairly complete spec for how their on-chip debug infrastructure works with JTAG
<tp>
rdrop-exit, I think for you JTAG is the right choice
<rdrop-exit>
cool
<Zarutian_HTC>
jtag is how many signal wires again?
<tp>
rdrop-exit, as JTAG is the universal fits all
<tp>
rdrop-exit, if you ever use the MSP430 jtag will do that job also
<tp>
Zarutian_HTC, jtag: Reduced pin count JTAG uses only two wires, a clock wire and a data wire.
<tp>
Zarutian_HTC, same as SWD
<rdrop-exit>
regular JTAG uses 4 or 5 pins
<crest>
although it recommends to stop the cpu to prevent it from executing partially modified code
<crest>
but that wouldn't be a problem for a ring buffer of up to 256 bytes with
<tp>
rdrop-exit, yeah, power, data,clock and /NRST
<tp>
crest, I can see a lot of possible jam-ups
<crest>
tp: ?
<tp>
rdrop-exit, and of course STM32 uses JTAG and SWD
<crest>
sure i can crash the whole system in 1001 intersting ways
<tp>
crest, I think the potential is high
<tp>
:)
<Zarutian_HTC>
tp, rdrop-exit: thanks
<crest>
it i don't plan to upload raw machine code while the cpu is executing it
<tp>
crest, the fast that SWD also has a NRST pin
<crest>
having a way to reset the system without reaching from the keyboard to the puny reset button would be an other advantage
<tp>
crest, rdrop-exit JTAG is also a lot slower than SWD when programming
<Zarutian_HTC>
tp, rdrop: know of any standardish pogopin pads constellation footprint for such on pcbs?
<tp>
crest,tabemann, the designer of 'propellor Forth is working on a cortex-m Forth now and his REPL which uses a interrupt includes using the ESC key to reset the MCU
<rdrop-exit>
tp, yes but faster then having to interpret from source
<tp>
Zarutian_HTC, I dont but there are standards for the JTAG board headers
<tp>
rdrop-exit, definitely
<Zarutian_HTC>
tp: hmm probably the same layout as those headers
<rdrop-exit>
The only way to get total interactive control of a target nowadays is the target's debug infrastructure
<tp>
rdrop-exit, I have two working tethered forths here, one uses the pc serial port, the other uses JTAG generated from a M4. Comparisons: serial tether ... slow and buggy, jtag tether .. flawless
<Zarutian_HTC>
it is just so nice to have an automatic test rig machine (an old p'n'p that was moddified to have pogopin header on its pick head) to test, program and test again
<rdrop-exit>
tp, cool
<Zarutian_HTC>
in manifacturing that is
<rdrop-exit>
The weak link in the chain in going from a PC to a target is the USB<->JTAG, no good non-proprietary solutions AFAICT
<tp>
tabemann, do you have a reset word ?
<crest>
rdrop-exit: how bad are the stlink v2 and its clones?
<tp>
thats right, stlink v2 is a $4 usb --> jtag dongle
<tp>
crest, but the stlink v2 doesnt do JTAG ?
<tp>
crest, only SWD
<tp>
rdrop-exit, what about the Olimex range of usb JTAG dongles ?
<tp>
rdrop-exit, I have two of them here
<crest>
tp: so fat swd is what i want to use for my console
<tp>
crest, yeah, but rdrop-exit's system requires JTAG
<rdrop-exit>
The only low-level solution I found was the MPSSE cable from FTDI, but you have to deal with their Windows derived library, they don't provide a protocol spec
<rdrop-exit>
There's an OSS alternative library available, but it seems incomplete
<rdrop-exit>
"The USB-MPSSE cable is capable of providing a USB to SPI, I2C or JTAG interface. This is accomplished by the MPSSE within the FT232H device which has the ability to emulate synchronous serial protocols while handling all the USB signalling and protocols.
<rdrop-exit>
I haven't found a viable alternative, yet
<tp>
rdrop-exit, and anyway, you can build a USB or ethernet to JTAG interface with a few different boards or mcu's
<tp>
my Tiva Connected Launchpad was $25 and has ethernet and usb. mathias turned it into a tethered host using JTAG to talk to the target using Mecrisp-Stellaris Forth
<rdrop-exit>
I've already done most of the code for interfacing through the MPSSE cable, but maybe at some point I'll rip it out and replace the cable with a board if I get frustrated
<tp>
rdrop-exit, at least you have plenty of choices
<rdrop-exit>
It drives me nuts when a vendor provides a library instead of a protocol spec
<Zarutian_HTC>
the lib is only given as .so or .dll or is it C source code?
<rdrop-exit>
closed source, only object
<Zarutian_HTC>
I have gotten the latter and the protocol spec was in there as a massive multiline comment
<rdrop-exit>
there's a OSS alternative on github, but it seems incomplete, does not inspire confidence
<rdrop-exit>
"Libraries? We don't need no stinkin' Libraries!"
<rdrop-exit>
-- Treasure of the Madre
<Zarutian_HTC>
right, one programmer I know got such an object file. He promptly stuffed it throug ida pro and ghandra to get a dissambled version to reverse engineer the protocol
<rdrop-exit>
or should that be...
<rdrop-exit>
"APIs? We don't need no stinkin' APIs!"
<rdrop-exit>
Zarutian_HTC, it's sad one needs to go to such lengths
<Zarutian_HTC>
rdrop-exit: yeah but that case the manifacturer had long evaporated. This was part of an RE project of a older equipment
rdrop-exit has quit [Quit: Lost terminal]
rdrop-exit has joined #forth
<rdrop-exit>
lost my connection
<Zarutian_HTC>
rdrop-exit: yeah but that case the manifacturer had long evaporated. This was part of an RE project of a older equipment
<rdrop-exit>
I see
<rdrop-exit>
what drives me nuts is implementers who use an API as an excuse not to fully document internals, pay no attention to the man behind the curtain
<rdrop-exit>
"Well there's a difference between, and I don't think this is understood very well by everybody, there's a difference between simplifying and making a higher level of abstraction, we say that's simplifying, but it's actually making things more complicated most of the time because there's more stuff underneath right, and that's what we have not acknowledged as a programming community" - Jonathan Blow
dave0 has joined #forth
_whitelogger has joined #forth
_whitelogger has joined #forth
Blue_flame has joined #forth
jsoft has joined #forth
rpcope has quit [Ping timeout: 260 seconds]
rpcope has joined #forth
WickedShell has quit [Remote host closed the connection]