dave0 has joined #forth
iyzsong has joined #forth
rdrop-exit has joined #forth
<rdrop-exit> (-_-)zzz c[] good morning Forthers
<tp> morning Zen Forth Guru, how is your volcano ?
<rdrop-exit> hi Master Forth Technician (tm)
<rdrop-exit> still Alert Level 3
<rdrop-exit> weak emissions, might stay like this for months
<tp> like my smoke here but yours is more of a hazard
<tp> and we have had about a week of rain, the nearby massive fire has been out for at least a week now
<tp> ill take jarrrah and wandoo smoke over silicates anyday!
<rdrop-exit> great, we've gotten some rain also cleaning up the air somewhat
<tp> id forgotten waht rain looked like
<tp> Im not mad about the 100% relative humidity tho
<rdrop-exit> we got our first coronavirus fatality
<tp> oh dear
<tp> just when we were all worrying about overpopulation, economics, wars ...
<rdrop-exit> yup
<tp> hey, I finally can say how much faster Forth is than C at development ;-)
<tp> it's 58 days quicker !
<rdrop-exit> cool! :)
<tp> I released my Forth 'stm32 diagnostics' bootable binary 58 days ago and today someone has just released C code that reads some registers in the chip
<tp> mine has a simple user menu, theirs seems to require a debugger and then analysing a hexdump
<tp> so it's very primitive and more complex to use
<rdrop-exit> interesting
<tp> my forth solution is nearly 2 months faster than a C one
<tp> real world problem solving with Forth and C compared!
<tp> and oddly I used to get a lot of trolling by C users on the forum I released by binary on, not a single attack on FOrth since
<tp> the trolls all went away like magic
<tp> today the total downloads are up to 112
<tp> and my V2 is nearly ready to be released
dave0 has quit [Quit: dave's not here]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
dddddd has quit [Ping timeout: 265 seconds]
jsoft has joined #forth
<tabemann> hey tp, rdrop-exit
<tp> hey tabemann
<rdrop-exit> hi tabemann!
<tp> tabemann, Ive discovered developing in Forth is 58 days faster than developing in C ;-)
<tabemann> :D
<tp> tabemann, I released my Forth 'stm32 diagnostics' bootable binary 58 days ago and today someone has just released C code that reads some registers in the chip, mine has a simple user menu, theirs seems to require a debugger and then analysing a hexdump
<tabemann> neat
<tp> why was it ever a debate that Forth development is faster ?
* tabemann has to get around to implementing . ." .( s" c"
<tp> tabemann, dont forget to track where hardware exceptions come from :)
<tabemann> right now I don't know how to escape from a fault exception :(
<tabemann> i.e. I want to raise a forth exception in response to a fault exception
<tp> well you generally cant
<tabemann> so how do OS kernels do it?
<tp> a hardware reset is usually the inevitable outcome on cortex-m exceptions
<tp> I have no idea, but a OS isnt the hardwre
<tabemann> with hashforth e.g. I was actually able to recover from segfaults and like
<tabemann> but hashforth runs under a Linux kernel
<tp> youd have to read the cortex-m doc
<tp> yeah, and Forth runs on the hardware
<tabemann> the cortex-m doc wasn't very enlightening
<tabemann> but what I mean is that if an OS can do it, Forth should be able to as well
<tp> I thinkl the cortex-m leaves relevant data and then just halts, a reset is the only way back
<rdrop-exit> I don't know ARM, but I would look find out where the vectors are
<tp> i have no idea about PC hardware, perhaps a CPU exception results in a halt ?
<tp> i read a interesting article about the cortex-m exception handling that seemed to explain it well, cant recall the doc tho
<tabemann> with PC hardware a CPU exception only results in a halt with "triple fault"
<tp> can you recover from the halt ?
<tabemann> the only fault you can't recover from is a triple fault
<tp> so it's the same ?
<tabemann> which is sometimes used to force a powerdown if power management isn't working
<tp> makes sense
<tabemann> a triple fault is when an exception occurs inside the double fault handler, which is the fault handler for faults occurring inside processor faults
<tp> i think the doc said that because the data needed to analyse the hardware exception is transferred to registers, all state information about the program it was running is lost, hence a halt is the only way out
<tp> something like that, I may not be 100% accurate but the gist is probably close
<tabemann> okay, I'm gonna hit the sack
<tabemann> g'night guys
<rdrop-exit> I would assume lower end chips don't let you recover from as many faults as higher end chips
jsoft has quit [Ping timeout: 260 seconds]
<tp> rdrop-exit, good point, those extra 10 billion gates are bound to help
<rdrop-exit> goodnight tabemann
<tp> cya tabemann
dys has quit [Ping timeout: 272 seconds]
gravicappa has joined #forth
ryke has quit [Ping timeout: 240 seconds]
<proteusguy> tp, outstanding results!
<proteusguy> MrMobius, I saw your msg the other day about dealing with 9 parameters/variables. Did you come up with a satisfactory solution? I'd be curious to know more details.
<tp> proteusguy, thanks, but most of the credit must go to Charles More and Matthias Koch :)
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
dys has joined #forth
iyzsong has joined #forth
iyzsong has quit [Remote host closed the connection]
iyzsong has joined #forth
jsoft has joined #forth
<rdrop-exit> back c[]
<tp> welcome back!
dave9 has quit [Ping timeout: 265 seconds]
<rdrop-exit> thanks!
dave9 has joined #forth
<tp> rdrop-exit, as you know, as part of my sneaky Forth infiltration into a very large C and Arduino anti-Forth group I released a bootable binary with a simple menu that worked from a single USB conection to the board in question, a cheap $2 Chinese "BluePill"
<rdrop-exit> yup
<tp> the bootable binary was my initial foray into this issue, mainly trying to detect which of the 'fake' Chinese STM32F103 clones was in the board
<tp> then I waited a couple of months and released 'a gentle introduction to Forth by way of a blinky' that ran on the binary I released
<tp> as the binary was a full Forth system with as many memory mapped registers as I could fit onto the binary image and yet still be under 64kB
<tp> because the standard binary flashing scheme can only handle 64kB when the chip declares 64kB Flash is all it has
<tp> and this system works with Windows and Linux USB
<tp> in fact most of the downloaders are Windows users in the USA
<tp> so as of right now, Im up to 112 downloads of the binary and 5 downloads of the overt 'a gentle introduction to Forth by way of a blinky' so thats five C users having a closer look at Forth
<tp> so sneaky Forth advocacy plan:
<tp> 1) release a really useful bootable binary for a popular micro for which no C alternative exists
<tp> 2) Dont mention Forth at all
<tp> 3) wait until there are over 100 downloads
<tp> 4) Advertise a overt Forth 'intro' that runs on the binary
<rdrop-exit> kudos
<tp> interestingly I haven't received a single bug report
<tp> which means it's doing on their systems exactly what I planned. This is good as Ive never owned any of the fake chips myself so was unable to test on anything but a bonafide STM chip
<tp> I guess that has to speak to the versatility and robustness of Forth
dave9 has quit [Ping timeout: 260 seconds]
<rdrop-exit> nice
<tp> it's a funny thing testing fakes
<tp> you cant buy a fake directly
<tp> no one advertises their bluepill has one in it because if it does it's probably been marked as a STM32F103
<tp> and they probably dont know, even if they did, they wouldnt say
<tp> so one has to buy 'bluepills' and wait to get a fake!
<tp> so at $5 - $10 a board I'm not interested, and knowing my luck, they will all be bonafide, obsolete 16 year old STM32F103's!
<tp> so it's a difficult problem to address, relying on Internet users to test my binary as there are so many who ordered the bluepill boards and got the fake chips
<rdrop-exit> right
<tp> how is that flu of yours going ?
<tp> is there any panic over the Conavirus there as yet ?
<tp> everyone wearing paper masks ?
<rdrop-exit> No panic yet, maybe 1 in 10 or more wearing masks.
<tp> personally I dont believe in the medias 'panic' agenda. I dont think people panic like that
<tp> usually people are orderly in times of emergency in my experience
dave9 has joined #forth
<tp> Ive seen people run away in times of unexpected explosions, but that's instinctual. it's not panic
<rdrop-exit> right
<tp> before you know it your legs have carried you 100 meters to safety
<rdrop-exit> You typically see more visitors wearing masks here than locals, especially Chinese, Koreans, and Japanese, tend to habitually wear masks
<tp> ah yes
<tp> i can understand that when the Japanese get packed like sardines on some trains
<tp> being out in public is a great way to catch viruses etc
<tp> if I'm on public transport and some starts coughing, I immediately move as far away as possible
<rdrop-exit> I don't use any public transport locally
<tp> you dont need to, with all the awesome shops opposite your door!
<rdrop-exit> it's a convenient neighborhood, I only tend to leave it to go to the beach or to visit friends or family
<tp> sounds like it!
<rdrop-exit> I hate sitting in traffic
<tp> that only happens in our major cities, here in rural Australia there is no traffic jams
<tp> I can hop on my motorbike and ride for 2/5 hrs and never stop
<tp> thats my 'fish run' when I buy fresh fish from a fishermans co-op on the coast
<rdrop-exit> cool
<tp> 2.5 hrs thru rainforests and mountains, it's just awesome
<rdrop-exit> nice
<tp> hey have a look at the C alternative to my Forth binary, I can barely understand it
<rdrop-exit> ok, checking
<tp> it appears he uses USB to dl a hex file ?
<tp> no user notes, no nothing
<tp> i know it's only a day old, but why release something so unfinished ?
<WilhelmVonWeiner> probably just to keep it in version control?
cartwright has quit [Remote host closed the connection]
<tp> but one doesnt need github for version control
<WilhelmVonWeiner> maybe s/he wants to keep it on github as a backup and access the code from multiple places
<tp> thats a valid reason
cartwright has joined #forth
<rdrop-exit> He's trying to distinguish STM32, GD32, CS32, and APM32
<tp> yes
<rdrop-exit> which are the counterfeits?
<tp> CS32, and APM32
<tp> GD32 is a clone but advertizes itself as a GD32
<tp> the others counterfeit the STM32 chip internal credentials
<tp> CS32 and APM32 may be the same fake chip, no one knows yet
<rdrop-exit> so if the id is 59, and the continuation code is 4, he assumes it's either a apm32 or cs32
<rdrop-exit> then he does a further test to differentiate those two from each other
<tp> oh
<tp> the data doesnt suggest a way to differentiate the apm32 or cs32
<rdrop-exit> // So, we can determine what core we're running on. We still need to find // a way to tell apm32 and cs32 apart.
<tp> there isnt one as yet
<tp> TM32 : Cortex-M3 r1p1 V:1 CONT: 0 ID: 32 PART: 410 REV: 0
<tp> GD32 : Cortex-M3 r2p1 V:1 CONT: 7 ID: 81 PART: 76F REV: 0
<tp> CS32 : Cortex-M3 r2p1 V:1 CONT: 4 ID: 59 PART: 4C3 REV: 0
<tp> APM32 : Cortex-M3 r2p1 V:1 CONT: 4 ID: 59 PART: 4C3 REV: 0
<tp> thats the data hes using
<rdrop-exit> but after that he does a further test
<rdrop-exit> romtable_t *rom = (romtable_id_t*) (ROMTABLE);
<rdrop-exit> if (rom->etm & 1) { prob = "CS32";
<rdrop-exit> } else { prob = "APM32";
<rdrop-exit> }
<tp> oh
<rdrop-exit> that's from line 175
<tp> Embedded Trace MacrocellTM (ETM)
<tp> thats the "user ETM pending" bit I think
<rdrop-exit> I'll take your word for it ;-)
<tp> it's way to iffy for me
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
iyzsong has joined #forth
<tp> perhaps he has a APM32 and diffed the ROM hexoile and found it different to the CS32
<tp> thanks for mentioning it, Ive made a note. Thankfully the "APM32" is hardly seen thesedays
<tp> there is no doc for it either, same as the "CS32"
<rdrop-exit> have fun with your detective work
<tp> Its fun with Forth
<rdrop-exit> :-)
<tp> his code looks like a lot came from premade templates
<tp> the popular C IDE's for STM32 have template generators using "HAL" or whatever
<tp> one gives the desired config and the IDE spits it out (more or less)
<rdrop-exit> I hate such things
<tp> the more experienced coders always advise to avoid them and do the config manually, the fans claim that these are the reasons the IDE is desireable
<tp> it does produce copious boilerplate thats soul destroying to read
<rdrop-exit> :)
<tp> I'm guessing that "sprintf" talks via the USB and a virtual serial port ?
<tp> so basically it makes some decisions and reports them ?
<rdrop-exit> I closed the browser tab, hold on
<tp> mine is similar but I do two reports, one is a few decisions and the other is a XML file with the virgin data for later analysis and database etc
<rdrop-exit> sprintf() prints to a 128 byte buffer
<tp> I wonder how that is then used ?
<tp> perhaps the bugger is read by the debugger into a hexfile, seems silly to do it that way tho
<tp> he has a USB virtual serialport, perhaps that reads the buffer ?
<tp> in demo.c in the project root directory ?
<tp> either way, I find that project very basic and confusing without some doc explaining it
<rdrop-exit> I don't see that buffer being picked up by any code
<tp> ahh, I reread his announcement
<tp> There is no fancy user interface, it puts its result in the USB string of the Interface.
<tp> The USB ID is DEAD:BEEF, so to capture the output, you can do something like this
<tp> Code: [Select]
<tp> [andre@8570w ~]$ lsusb -d dead:beef -v | grep iInterface
<tp> can't get device qualifier: Resource temporarily unavailable
<tp> can't get debug descriptor: Resource temporarily unavailable
<tp> iInterface 4 STM32 Cortex-M3 r1p1 V:1 CONT: 0 ID: 32 PART: 410 REV: 0
<tp> The iInterface string will contain
<tp> STM32/GD32/CS32/APM32
<tp> Cortex M3 rnpn : The ARM Core used: STM32 uses r1p1, clones usually r2p1
<tp> Content of the PID in the ROM TABLE (JP106 Identifier)
<tp> I guess his buffer and decisions are for later use
<rdrop-exit> probably work-in-progress
<tp> definitely
<tp> thanks for having a look at it, my C sucks
<rdrop-exit> np
<tp> this guy seems very capable, I can only imagine the initial design questions that he must have had
<tp> having *zero* on chip resources ready to use, he had to create eveything
<tp> Forth had everything I already needed when I started
<rdrop-exit> cool
<tp> I guess his idea is pretty simple, but it does require his hexfile be flashed to the chip, then the data is sent back as a USB string 'Interface"
<tp> probably the simplest C method ever apart from blinking the data thru the board user LED as morsecode
<rdrop-exit> My first instinct would be to use the debug interface for stuff like this.
<rdrop-exit> As you know I always assume a tethered setup.
<tp> yes
<tp> do you have actual hardware connected via the debug interface yet ?
<tp> the bluepill has no SWD or JTAG connector
<rdrop-exit> Not yet, I haven't bought a target yet.
<rdrop-exit> If the target has no debug interface than I would put a tiny monitor on it, enough to go peeking and poking around under the control of a Forth on the PC side.
<tp> the Blue Pill has pims for SWD and Jtag which have to be manually wired
<tp> thats what I did, my monitor was 19kB in size, some people call it "mecrisp-stellaris" tho
<tp> :)
<rdrop-exit> that works :)
<tp> it do
<tp> my aim was to get data back from users who actually have the hardware and analyse it
<tp> that was the aim of V1, apart from showing C users that something else other than C does this job very well
<rdrop-exit> you are a generous person
<tp> (for those that even wondered)
<tp> it was a interesting challenge
<tp> and I have about 20 STM32F103 chips here myself, just none of the clones
<rdrop-exit> time to walk the dogs, catch you later
<tp> cya
rdrop-exit has quit [Quit: Lost terminal]
dddddd has joined #forth
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
jsoft has quit [Ping timeout: 265 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
deesix has quit [Read error: Connection reset by peer]
dddddd has quit [Ping timeout: 268 seconds]
deesix has joined #forth
dddddd has joined #forth
deesix_ has joined #forth
dddddd_ has joined #forth
deesix has quit [Ping timeout: 265 seconds]
dddddd has quit [Ping timeout: 240 seconds]
dddddd_ is now known as dddddd
deesix_ is now known as deesix
xek has joined #forth
proteus-guy has joined #forth
tabemann has quit [Ping timeout: 240 seconds]
ryke has joined #forth
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
ryke has quit [Ping timeout: 265 seconds]
ryke has joined #forth
dys has quit [Ping timeout: 240 seconds]
WickedShell has joined #forth
pierpal has joined #forth
gravicappa has quit [Ping timeout: 268 seconds]
pierpal has quit [Ping timeout: 272 seconds]
pierpal has joined #forth
cartwright has quit [Remote host closed the connection]
cartwright has joined #forth
xek has quit [Ping timeout: 265 seconds]
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #forth
KipIngram has quit [Quit: WeeChat 1.4]
KipIngram has joined #forth
pierpal has quit [Ping timeout: 265 seconds]
pierpal has joined #forth
pierpal has quit [Ping timeout: 268 seconds]
dave0 has joined #forth
pierpal has joined #forth
pierpal has quit [Ping timeout: 265 seconds]
ryke has quit [Ping timeout: 260 seconds]