Hi Martin, A few years ago (probably around 2020) Microchip had a sale (on their online store) of SAME51-CNANO EvalKits, it uses ATMEL ATSAME51j20 which is based on a Cortex-M4F core (running at 120mhz). This dev board was evaluated to be included in an R&D project at the time after having success working with the SAMD21-CNANO EvalKit porting of a project (Cortex-M0+). Strangely enough they also had AVR128DB48-CNANO EvalKit (AVR8) which was going to be used for evaluation for the above project. Once RISCV started to show promise work shifted to there. Do you see where I am going on this, AmForth has the potential to run on all these platforms without a lot of time spent on porting C and assembly code even though any of the CNANO kits mentioned above are/were cheaper (last time I checked) than uno r4 (on DigiKey) and have an on board chip for deploying and debugging programs on Cortex-M4F/M0+ and AVR8 using MPLAB X IDE (free download from Microchip site) which I still use when time allows. MounStudio is being used for RISCV CH32 chips, since Microchip (which now owns ATMEL) won't support RISCV chips (since they are royalty free and ARM is not). FYI John S
On Wed, Dec 24, 2025 at 9:58 AM John Sarabacha <[email protected]> wrote: > Hi Martin, > This is quite good, also your enjoying what you are doing I think that is > the key for good quality products (software, hardware, integrated systems). > This is a time saver for new development and making it work properly. This > gives you more control of the debugging process for the chip your > interested in. This also beats what MounStudio has done with it's > integration of GDB for debugging their CH32 chips because they focus only > on those chips. > > Have a good holiday > John S > PS: I don't think you need to worry about the quantity of emails, looks > like we can break the record of the number of emails in one month at least > since 2014? (in the group email chart). > > On Wed, Dec 24, 2025 at 9:07 AM Martin Kobetic <[email protected]> wrote: > >> My last message seems to have been blocked due to size (I attached a >> picture). I'm not sure if any list admins are watching currently, so I'm >> resending it with a link instead. Please reject the original if you are. >> >> ---------- >> >> Hi all, I hope I'm not too annoying with all the emails. I promise I'll >> try >> to keep it down, but I've got one more thing I'd like to bring up. I've >> been doing a lot of debugging, and I went down the rabbit hole with GDB to >> make that as convenient as possible. I want to share what I was able to do >> with GDB and maybe solicit some debugging tips from others. >> >> First of all I'm quite impressed with how powerful GDB's TUI and Python >> API >> is. This is how my debugger looks now: >> https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/gdb-amforth.png >> >> The top views are "source", "asm" and custom "registers" view. Note that >> the register view is tailored to what AmForth uses the registers for. The >> Forth "parameter stack" and "return stack" are on the bottom right. I have >> some ideas how to improve the stack views further but I think this already >> shows what's (fairly easily) possible. >> >> Some of my earlier tweaks are addition of ".s" and ".r" commands to GDB to >> dump the stacks in the command window (that's also what the stack views >> are >> currently using as well). >> >> If anyone's interested the custom views are defined using the python API: >> https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/gdb-amforth.py >> and the custom commands and the layout itself is defined in GDB init file: >> https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/.gdbinit. >> The OpenOCD and GDB invocations are in the Makefile: >> https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/Makefile#L64-L80 >> >> This makes debugging the assembler words quite comfortable. I'm still >> thinking about the best way to debug colon words. The best I've got so far >> is adding a breakpoint at DO_EXECUTE and automatically stepping twice to >> end up in the code of the word being executed. >> >> define bde >> hbreak DO_EXECUTE >> commands >> step 2 >> end >> end >> >> Then I can use `continue` to step from word to word. I suspect there are >> probably better ways to go about this. I'd welcome any suggestions. >> >> I'm also wondering what's the best way to set a breakpoint in a colon >> word. >> You can't just point at the address in the word parameter field because >> that's not where the PC is going to be. The best I can think of is again a >> breakpoint in DO_EXECUTE but with the condition on FORTHIP pointing at >> that >> address in the parameter field maybe? I haven't really tried that yet, but >> can't think of anything better. Again, any suggestions are welcome. >> >> Any other favourite tricks that you could share with a rookie? I'd be much >> obliged. >> >> Cheers and Merry Xmas! >> >> Martin >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
