Activity for Matthias Koch
-
Matthias Koch posted a comment on discussion General Discussion
The long-awaited USB-CDC terminal driver for RP2040 Pi Pico is up and running and ready for initial testing before release: https://mecrisp.sourceforge.net/usb-rp2040.txt If you feel adventurous, please try it and report back. Matthias
-
They differ in their memory access capabilities. j1-universal-16kb.v: There are data paths for the two topmost elements of the data stack, so there is "memory write and one drop" + "another drop" necessary to do the effects of "!". j1-universal-16kb-quickstore.v: There are data paths for the three topmost elements of the data stack, allowing to do a memory write and two drops for "!" in one cycle. The first two differ in their stack implementations only. Their memory access model is fine for pseudo-dualport...
-
Hi Igor, division and modulo are tricky to do on the stack machine, involving a lot of stack shuffling, and that eats away cycles. Also the do ... loop needs more cycles than on ARM, because only the top of return stack is accessible directly, so running "j" and "loop" requires some shuffling also. Unfortunately, single-cycle division and modulo is quite heavy in logic, so its not included for default, but there are six to eight opcodes free (depending on core) which you can use to add these instructions....
-
Hi Aaron, looks as if you are missing build dependencies. To compile and synthesise, Mecrisp-Ice needs GForth, the Freepascal Compiler, and the oss-cad-suite for the FPGA flow one can download from here: https://github.com/YosysHQ/oss-cad-suite-build/releases Matthias
-
Hi John, pin 2 should be the RX pin on the Pi Pico, and when unconnected, its ok for it to be stuck as it is not driven. Try swapping RX and TX wires! Thats one of the most common problems to encounter at the beginning. The pins are current-limited these days and survive being swapped. Matthias
-
Hi David, good ideas, you are that close! Both UARTs share the same clock source, clk_peri, which is already up and running when using Forth, and all peripherals are out of reset after the clock init code, so you can focus on the UART registers, and the special functions for the pins. In terminal.s for the RP2040, thats these lines: UART_Baudrate: ldr r0, =UART0_BASE movs r1, #UART0_IBAUD str r1, [r0, #UARTIBRD] movs r1, #UART0_FBAUD str r1, [r0, #UARTFBRD] movs r1, #UART_8N1 | UART_FIFO str r1,...
-
Hi David, nice to read that you and Forth found each other again! For a first quick idea, have a look at the file mecrisp-stellaris-3.0.1/mecrisp-stellaris-source/rp2040-ra/terminal.s which initialises the default UART. The pin configuration registers of the Pi Pico are a bit special. When something does not work, it is most of the time caused by a missing clock, or special functions of the pins not set to the peripheral ones wishes to see there. Good night, Matthias
-
The design uses HDMI video out and USB lines directly connected to the FPGA, which is not the same as HUB75 attached LED panels and ethernet on the Colorlight, and it will require porting effort until you get a nice terminal on your blazingly bright LED wall :-) The other board has HDMI on the breakout maybe? The FemtoMSP430 processor core itself should be quite independent regarding the actual FPGA, just like the FemtoRV32. By the way... Unless you are a big fan of the MSP430 instruction set, make...
-
Thanks, too, you are welcome!
-
Dear Terry, many, many thanks for your very kind reply! I am glad you joined the project in its earliest stages, and I hope Mecrisp-Stellaris will continue to serve you well. Matthias
-
I have an ULX3S with an ECP5 85F, but the design will fit in the smaller ones, too, if you change the nextpnr-ecp5 invocation to yours. Note that you'll get much better performance for less resource usage if you use Mecrisp-Quintus or Mecrisp-Ice on the same target, as their respective processor cores are more optimised and need less cycles per instruction than the freshly baked, still experimental FemtoMSP430.
-
Hi Terry, Hi Maciek! Happy to read you both are having fun, and I am glad you take the stable base of Mecrisp-Stellaris without planned further enhancements as a rock solid ground for your own creativity. I worked on it for more than a decade, and be sure, if you find a bug, I am there to fix it. For me, both my hobby and my professional work happens on FPGAs now. I could have written an ARM Cortex M0 compatible softcore to continue using Mecrisp-Stellaris, but ARM is legally hostile against open...
-
Despite of the problems encountered with the old faithful MSP-EXP430G2, I have one good new. Using TI Uniflash online version, I have flashed "forth-mecrisp-msp430g2553-with-insight.hex" to the new MSP430G2ET board and it works perfectly. The same process worked for my MSP430FR6989 launchpad. Thats great news! I hope you are having a nice time, enjoying your freshly achieved Forth experience.
-
I do get the same wrong characters every time I hit the reset button: Yeah! Thats it. We know that we are connected, the microcontroller is alive, and it sends a message on boot, as expected. We just cannot read it, and get wrong characters instead. The problem is: The MSP430 chips have an internal oscillator (called "DCO" in datasheet), that needs to be calibrated individually for each chip in order to meet the tolerances necessary for driving the UART with a known baud rate. These calibration valiues...
-
I assume with the external adapter, it may be /dev/ttyUSB0 instead.
-
Thats interesting. You are getting something, but the characters seem to be totally wrong, possibly sent with a differnt baud rate. Do you get more wrong characters every time you hit the Reset button? By the way, maybe there are multiple /dev/tty connected to your computer, and you connected the wrong adapter/board? ls /dev/tty should give you an idea, watch for ttyACM and ttyUSB. If you have multiple results, try all these, or see which one disappears when you disconnect the Launchpad. If that...
-
One more hint: If you get more wrong characters every time you hit Reset button, then probably you managed to erase the "info flash" segment that contains the baud rate calibrations values. Let us know, and we find a way around that. I vaguely remember there was a TI app note once that allowed to re-calibrate and re-flash these constants, given you solder the 32768 Hz crystal to your board.
-
Oh, I see, you are using an external USB-serial adapter. Well, that should work, too. I am using the internal serial bridge of the Launchpad, its a vanilla 9600 baud 8N1 connection. picocom /dev/ttyACM0 -b 9600 --imap lfcrlf,crcrlf --omap delbs,crlf --send-cmd "ascii-xfr -s -l 250 -n" Also compare the attached photo of my setup, please note the jumper orientations. Could you please elaborate on the settings you tried to connect with? Have you pressed the Reset button?
-
Wow, many thanks for you chiming in! Now lets see what might be the issue... I found my MSP-EXP430G2 launchpad with a MSP430G2553, set the RXD and TXD jumpers to "HW UART" position as printed on the silkscreen (seems as if I have the later revision, the earlier needed two jumper wires), flashed a Forth image, and connected to the terminal, then pressed the RESET button on the board to get the welcome message. If you are not sure what is wrong, you can try to flash the attached hex file that will...
-
Hello and welcome to Mecrisp, nice to read you! You are the first new MSP430 Mecrisp user for years, so I am sorry you had a bad time unpacking the file. Its an old archive, and I should upload a fresh release soon. I recall that depending on the hardware revision of your MSP430G2553 Launchpad, there were two different variants regarding the RX/TX jumpers; with one requiring you to use jumper cables, the other allowing to turn the jumpers. I am not sure which, but keep this in mind. The Launchpads...
-
Also try common/value-ra.txt iff you are on a -ra core for improved performance.
-
Glad to read your success!
-
Clearly bit 5 is set but the IF test gives a different response. Can you please indicate how I can improve the code? IPSR is not an address, but gives the contents of a special register within the CPU, therefore you cannot fetch it. You need to do something like IPSR $C0C0A = IF ... ELSE UNHANDLED THEN with a suitable interrupt number, the same UNHANDLED prints when the interrupt triggers. Is it ok to call the |unhandled| at the end or does it need something else? UNHANDLED is for user convenience...
-
Within Mecrisp-Stellaris, all the interrupts that did not get their own hook go to irq-collection. Use this, switch on the current interrupt active using something like IPSR CASE ... and call UNHANDLED if this isn't the one you want. If you want to add more dedicated interrupt hooks, look here: mecrisp-stellaris-2.6.5/mecrisp-stellaris-source/stm32l432-ra/interrupts.s mecrisp-stellaris-2.6.5/mecrisp-stellaris-source/stm32l432-ra/vectors.s If you want to know how the interrupt trampolines work, they...
-
Feel welcome, and my congratulations for your first port of Mecrisp-Stellaris! Glad to know that you could trace down the mixed wires, and Robert Clausecker already taking care of your contribution.
-
Hi Jim, thank you for reporting this bug! I uploaded 1.1.1b which includes the fix. Best wishes, Matthias
-
Hi Peter, I am using this feature for bitfields in IO registers, to mix hex values with a sprinkle of binary config bits. Thats why this feature is consistent between Stellaris and Quintus :-) If you have a look at the source code, it is an easy addition to make it ignore underscore characters, feel free to change it to your needs. Matthias
-
Hi Brandon, thank you for pointing this out! Exactly as you described, I updated the USB code from the upstream source, and forgot to change the instantiation in TinyFPGA-BX, as this was a contributed port for which I do not own hardware. I added your name to the "Testing and hints" section in the CREDITS file as a little thank-you, included the change and uploaded Mecrisp-Ice 2.7c. I would be glad if you could try the included bitstream and let me know. Best wishes, Matthias
-
Hi Ronny, this is the invocation I use, see mecrisp-stellaris-2.6.5/rp2040-ra/release script: uf2conv.py --family 0xE48BFF56 --base 0x10000000 mecrisp-stellaris-pico.bin -o mecrisp-stellaris-pico.uf2 But the error message you give looks like a new problem with some version quirks of Python. I just quickly tried it and got the same error: tools/uf2conv.py:200: SyntaxWarning: invalid escape sequence '\s' words = re.split('\s+', line) Best bet is to get and try the current one from https://github.com/microsoft/uf2/tree/master/utils...
-
Hi Peter, thank you, I'll examine and include your code soon! Matthias Am 09.12.24 um 19:42 schrieb Peter Schildmann: Hi Matthias, Yes, please do so. I just added bin and hex files and a short README to the ch32l branch. Peter Support for Nanjing Qinheng Microelectronics CH32L103 MCU https://sourceforge.net/p/mecrisp/discussion/general/thread/60bec129a7/?limit=25#e33d Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/mecrisp/discussion/general/ https://sourceforge.net/p/mecrisp/discussion/general/...
-
Hi Maciek, place both "flash" and "ram" dictionary areas into RAM, make sure to initialise the complete "flash" portion first, and let hflash! jump to h! Thats all. In Mecrisp-Stellaris, I use this memory model for Linux, FreeBSD and the RP2040, as Terry already pointed out. If this places does> above the lowest 64 kb of the address range, use the switch .equ does_above_64kb, 1 and you might want to use .equ erasedflashcontainszero, 1 Matthias
-
Hi Michael, Terry is correct that I do not plan a complete rewrite for the Xtensa cores which many of the popular ESP32 chips are based on, but for the ESP32-C3 which is a native RISC-V one, there is indeed some efforts going on behing the scenes to port Mecrisp-Quintus! Best is to directly get in touch with ivand58@hotmail.com who started the effort, I notified him and he is happy to share what happened so far with you. Best wishes, Matthias
-
Hi Peter, congratulations, thats very nice! Would you like me to include your fresh port into the official release? Matthias
-
Forgot to include the second opcode: opcode [ $F2C20000 ><, ] ; see opcode 00116B96: B500 push { lr } 00116B98: F2C2 movt r0 #2000 00116B9A: 0000 00116B9C: BD00 pop { pc } The movw/movt pair tries to load constant $20004FC4 into r0, which requires using a ldr instruction instead on M0. Did you place the Forth core into RAM memory area?
-
Huh, that looks strange. It says F64470C4 as an undefined opcode... Which would be a long 32 bit opcode. The M0 only supports Thumb-1 mode, and I think the assembler tries to create code for a more capable ARM CPU. Lets disassemble it: opcode [ $F64470C4 ><, ] ; ok. see opcode 00116B7E: B500 push { lr } 00116B80: F644 movw r0 #4FC4 00116B82: 70C4 00116B84: BD00 pop { pc } This is a movw instruction with a constant too large for the movs with byte sized immediate available in M0. Maybe your new memory...
-
Sorry for being a bit late, I have a few additional hints... There is a nicely portable example for a bit-bang I2C implementation for Mecrisp-Stellaris using GPIO lines, running on a different chip: mecrisp-stellaris-2.6.5/stm32f303/imu.txt And a graphics library with lines, circles, ellipses and a few different bitmap fonts: mecrisp-stellaris-2.6.5/common/graphics-unicode-4x6.txt mecrisp-stellaris-2.6.5/common/graphics-unicode-8x8.txt mecrisp-stellaris-2.6.5/common/graphics-unicode-8x16.txt mecrisp-stellaris-2.6.5/common/graphics.txt...
-
Hi Steven, you can find the multitasker sources in the common/ directory, along with a collection of other hardware independent goodies. But let me recommend you to simply flash mecrisp-stellaris-pico-with-tools.uf2 instead that contains the multitasker and some other nice additions in a ready-to-fly fashion. By the way, welcome to Mecrisp-Stellaris and the forum, nice to read you! Best wishes, Matthias
-
Hi Steve, you need to use buffer: to get RAM for a buffer. You cannot use allot after variable. 20 buffer: steve steve 20 accept drop steve 20 type Best wishes, Matthias
-
Hi Bernard, I am glad Travis already answered your questions! The ADC needs a fixed amount of clock cycles after starting the conversion... But as you are using the RP2040 featuring a rather noisy ADC, I think quality of the readings is not of utmost importance for you. Maybe try to push the ADC by overclocking it beyond the specification of 500 ksps at 48 MHz input clock and see what happens? Selecting clksrc_pll_sys and playing with the divider should do the trick. If I were in your situation,...
-
Hi! Mecrisp-Stellaris already runs nicely on Linux and FreeBSD, if you take care of the structure necessary for Zephyr and rewrite the terminal code, I see no reason why this should not work. But... Your desire probably is to have a nice interface to all the other functions of Zephyr, and you would need to take care to make all the routines accessible from within Forth. And this is the more complex part. You can try, but I am not using Zephyr and I am not using ARM targets myself anymore, my focus...
-
Adrian, I think there is some confusion... Access to both the return and the data stacks is not by using @ and ! as the stacks are not located in addressable memory. Instead, the stacks are implemented in shift registers, see stack2.v and stack3.v for the code. In the processor Verilog code, there are dedicated datapaths for the stacks (see wires st0, st1 and st2 for data stack). In j1-universal-16kb-quickstore.v stores happen by additional logic (the ALU and data stack operation encoded is simply...
-
Hi Christopher, many thanks for your suggestions to improve the documentation of Mecrisp-Ice! I totally agree that it is time to tidy the files up. My preference would be a general readme in the top folder, a refreshed common glossary, and target specific readme files in the target folders that explain the extras that are not in the common glossary. After a lot of time, dust is settling now, and experience shows what extras are useful and included most often, to establish a "baseline feature set"...
-
Hi Christoper, many thanks for your suggestions to improve the documentation of Mecrisp-Ice! I totally agree that it is time to tidy the files up. My preference would be a general readme in the top folder, a refreshed common glossary, and target specific readme files in the target folders that explain the extras that are not in the common glossary. After a lot of time, dust is settling now, and experience shows what extras are useful and included most often, to establish a "baseline feature set"...
-
I wish to add words to the stack operations. But I wish to do this in the file j1-universal.quickstore.v. How do I do this and what other files need to be updated? You can add your new instruction to j1-universal-16kb-quickstore.v and then try it directly from Forth: juggler [ $7xxx , ] ; Note that you need to either use the Verilator target or compile a real bitstream to actually use the changed processor. For historical reasons most of the 16 bit targets do precompile their sources and emulate...
-
One more point: When jumping from point to point, it takes a little while for the capacitances to follow. On an analog scope, you get a faint glow connecting the points when set to very high brightness due to this, but on a digital scope you end up with a misplaced sample in between.
-
Hi Maciek, digital scopes mostly offer a XY-mode, too, and you can indeed watch the demos on your digital storage scope. But usually one gets artifacts due to the sampling nature of the digital scope or strange flickering. This is one of the rare cases in which the analog scope gives a much better looking result. I think you need a digital scope that simulates the decay of every single sample to get the effect right. The ones I tried simply collect samples over a predetermined time and then refresh...
-
You are welcome. I think you need to have a look at the "compile" bash script in the skeletalstructure folder, especially at the options for nextpnr-ice40. The HX8K it is configured for is in BGA package and pins are denoted in a chessboard like pattern. You have a different iCE40 FPGA in a different package - change this line accordingly: nextpnr-ice40 --freq 12 --hx8k --package ct256 --asc build/j1a.txt --pcf icestorm/j1a.pcf --json build/j1a.json --ignore-loops --pcf-allow-unconstrained
-
Get binaries: https://github.com/YosysHQ/oss-cad-suite-build/releases Set path: source ~/where-you-unpacked-it/oss-cad-suite/environment
-
Hi Christopher, many thanks for the improved README lines! I'll reply in detail and take care later. probably because there is nothing there. I think I have to generate some file, but I am not sure what I should be doing. Unless the later ones that precompile in Verilator using the logic directly, the 16 bit targets use a CPU emulator written in Pascal to generate the initial memory image. You need to install the Freepascal Compiler, and run "fpc icecreammachine-16kb.pas" in mecrisp-ice-2.6d/common-crosscompiler/...
-
The UP5K has 15 kb of dual-ported BRAM available. One can fit a single 16 bit Mecrisp-Ice core into that FPGA only. The other 128 kb are single-port memory, and not suitable for Mecrisp-Ice. If you want to use more than one one Mecrisp-Ice core, you have to use an ECP5.
-
With Mecrisp-Stellaris on a 16 kb chip, everything becomes a sizecoding challenge. I know of one application, a 7-segment display voltmeter using STM32F030F4, others were using Forth on these chips for debugging the hardware while writing the main firmware in C. I recommend getting ARM chips with at least 32 kb flash if you want to enjoy Forth on these. As Terry helpfully points out, 64 kb will also support a nice selection of tools loaded.
-
You are using undefined byte access on word registers. Whereas it might be well possible there is some bug in Mecrisp-Across (still experimental!) the most likely cause for discrepancy between JTAG emulation and running on-chip will be the use of undefined/invalid byte access to word registers, and your excessive use of "read-modify-write" instead of setting the registers directly to the value you want these to have. If you do not want to, trace the changes starting from the datasheet-published reset...
-
Hi Maciek, I do not know why the effect differs when using the IO register sequece interactively over JTAG and when compiled to real binary, running on CPU, but I spot a few weird things in your code. First, you are using cbis! everywhere ("BIt Set, byte width), which renders your code dependent on the former values of the contents of the registers (check reset values in datasheet). Why are you not using ! or c! with the final value? Second, you are using byte access on word registers, for which...
-
I see, ok. I would love if you could try the included binaries. I hope I did not break anything...
-
Hi Hans, oh sorry, you specifically gave me the links to the folder for the "ch56x" port, which I included and released with Quintus 1.0.4. Could you please give me the pointer to (the) other port(s) you created? I'll add as soon as possible! Matthias
-
Hi Christian, this is mostly a "datasheet research" question - and do not forget to see the silicon errata, too, if you encounter strange behaviour. Also, there are fake chips in blue pull boards that pretend to be a STM32F103, but only coarsely. Good luck, maybe it helps to watch out for existing code in other languages to find the necessary initialisation and configuration. My usual approach is to read code from others, if available, read the datasheet again, and try different configs until success....
-
Hi Hans, some time passed, and some of your Github repos look as if the code settled by now. Maybe time to include your efforts into the mainstream release of Mecrisp-Quintus? Let me know, please, which repos/folders/ports are ready for release. Best wishes for the new year, Matthias
-
Hi Marc, I am not working on a local variables implementation, but I am looking forward to yours. Matthias
-
Hi Marc, maybe ": ; locals-wizardy postpone ; immediate inline ;" is the solution you are looking for? ; itself is immediate, compile-only, and the combination of the flags inline+immediate is used to represent that. Cool. Locals are coming. Curious how that turns out. Let me know, please. Matthias
-
Hi Maciek, thank you for including the error message this time :-) Entirely my fault. Please replace .equ flash16bytesblockwrite, 1 with .equ flash8bytesblockwrite, 1 in the main mecrisp-stellaris...s file for your chip and it will assemble properly. Why? Well, back then I had an emulation layer for 16-bytes-at-once only, and when I added an 8-bytes-at-once layer, I also switched the flash code for these chips to be more efficient, but completely forgot the assembler switch. Will be fixed in next...
-
Hi Rudwan, Dear Terry, thank you for all the nice applause on Mecrisp-Across, that was a labour of love for my favourite architecture, and an experiment to explore global optimisations in a Forth compiler. Here is a beautifully set article of someone diving into the Mecrisp-Across compiler deeply: https://joldosh.blogspot.com/2019/12/optimized-msp430-assembly-in-mecrisp.html But I am not going to rewrite Across for ARM unless getting paid full-time for that, and Mecrisp-Stellaris is not designed...
-
Hi Ronny, congrats to your first successful compile! See mecrisp-stellaris-2.6.4a/rp2040-ra/release for details on how to generate the UF2 file. Matthias
-
Terry, whats wrong? Compiling ASL involves copying and renaming one file prior to the usual process. Here the commands required for 64-Bit Debian: cp Makefile.def-samples/Makefile.def-x86_64-unknown-linux Makefile.def make make install Unfortunately, it is not available as ready-made package for Debian. Matthias
-
Go to http://john.ccac.rwth-aachen.de:8000/as/download.html Download http://john.ccac.rwth-aachen.de:8000/ftp/as/source/c_version/asl-current.tar.gz Pick asl-current/Makefile.def-samples/Makefile.def-x86_64-unknown-linux for use (probably). If you have not read the assemblers installation instructions: You need to copy the appropriate Makefile.def... to the main folder as Makefile.def before attempting to compile, as it supports building on a huge variety of weird and wonderful machines. This step...
-
Hi Maciek, immediately after stopping the watchdog (first instruction), you set a pin direction to output, and place xor.b #ledpin, &P1OUT on different locations in the boot process. The reset entry point is in the chip specific code, "catchflashpointers" is run which may crash silently if something is slightly wrong with memory, then terminal is initialised in your own code and finally a message should be printed. If you reach terminal init after catchflashpointers, memory is fine. If you reach...
-
The problem with your demo code is that ENDCASE drops one value when coming from default branch and not two so that test2 has stack effect of ( addr len -- addr ) actually if neither of the ?OF trigger and ( addr len -- ) as specified otherwise. But I get the point.
-
That is a valid point for an use case indeed! Let me think on that for a while.
-
Hey Terry, this is of, not ?of Tillmann is examining. Matthias
-
Hi Tillmann, uh, oh! Thanks! I need to fix the glossary! The point of ?of is to check the flag, but it also needs to fit into the standard case structure, which expects the taken of...endof pair to remove the switch value from the stack. One could do this manually with a drop in every ?of...endof pair, but I think I'll rather change the glossary instead of changing the compiler behaviour on all supported architectures. Hannover, Germany, or a different one? I visited university there! Matthias
-
Hi Maciek, no, the JTAG ID isn't used nor checked in Mecrisp. The problem you describe might happen when memory map is wrong or some old contents cause initialising the dictionary pointer in mecrisp-2.0.7/mecrisp-source/common/catchflashpointers.asm to fail. Can you narrow down by toggling a LED where it crashes before reaching the welcome message? Matthias
-
Hi Gregg, better open a new thread for questions like this! The macro assembler AS by Alfred Arnold flawlessy compiles and runs on 64 bit Linux here. Go to http://john.ccac.rwth-aachen.de:8000/as/download.html Download http://john.ccac.rwth-aachen.de:8000/ftp/as/source/c_version/asl-current.tar.gz Pick asl-current/Makefile.def-samples/Makefile.def-x86_64-unknown-linux for use. If you have not read the assemblers installation instructions: You need to copy the appropriate Makefile.def... to the main...
-
Thank you for the observation and the small test to show the issue! I tried on both Mecrisp-Stellaris classic and with RA, and also on Mecrisp (for MSP430) and Mecrisp-Quintus (for RISC-V and MIPS). Behaviour is consistent. I think I implemented it with that stack effect because I understood ?of to work this way; but as you mention it, I found that ?of is not part of the Hayes test suite and undefined in both DPANS94 and Forth200x. Could you give me a reference to the official behaviour expected...
-
https://github.com/badgeteam/mch2022-firmware-ice40/tree/master/projects/Forth/fw/mch2022 https://github.com/badgeteam/mch2022-firmware-ice40/tree/master/projects/Snake/fw/mch2022
-
How can I reset the flash dictionary here pointer, after I erase the flash dictionary? After erasing flash you need to restart; use hardware reset if your chip provides one (put it into a definition called "reset" then, please), or "0 execute" to at least restart the Forth core. I looked and could not find where it is stored. Nowhere. It is searched for on every boot, and kept in variable (dp) or its shadow copy while running. (latest) is dictionary link. Keep in mind there are two sets of (latest)...
-
Should that be zero, you can use this switch: .equ erasedflashcontainszero, 1
-
Moin Hans, I am not sure what exactly fails, but I noticed that your repo gives zero search hits for "hook". How did you actually wire the routines into the common/flash.s hooks? On the other hand there is a "rom read" routine in your code; does it need a special sequence to read back data written? The Forth core assumes that it can read and execute everything directly. For a closer examination of the whole core dictionary disappearing, could you check if the core dictionary is there when you switch...
-
Hi Hans, my congratulations for your first Quintus port! To contribute, send me a tarball of the target specific files to the official E-Mail address m-atthias@users.sf.net and I include it into the next release, along with your name in the CREDITS file. I know that flash writes can be very tricky on some targets, and a RAM-only port is nevertheless a great leap forward! By the way, if you cannot do small separate writes, but find a way to flash large blocks at once, there is a nice solution of having...
-
Hopefully the folks behind the FOMU bootloader can help: https://github.com/im-tomu/foboot
-
Hi Bernard, you are conquering additional boards with Mecrisp-Ice, glad to read that! In questions on the bootloader of the TinyFPGA-BX I have no clue what happens there. Maybe the flash chips differ in details of handling protected pages? I think I cannot really help here; I only got some ready-made USB<->ttyACM logic included, up and running :-) Good luck, Matthias
-
You are welcome! Good luck, and have fun!
-
Hi Peter, and then look at a UF2 file generator so that I can share the complete install as a UF2 that you can load up. you are making great progress! Just a short note that there is already the combination with thumbulator included in the vanilla Mecrisp-Stellaris package that you can use to generate uf2 files with precompiled Forth sources! Hats off, Matthias
-
Hi Bernard, I am glad you could get 2.6 release up and running now! For multitasking, you need to load mecrisp-ice-2.6/common/multitask.txt and perhaps have a look at multitask-examples.txt as well. Define a task for your own code; quit with the Forth compiler will continue to run as usual in the "boot-task". Matthias
-
Yes, I told you to replace all the core build utilities :-) Reason for that is that there is now the interrupt vector at $0002 so everything moved by two bytes. And execute is deeply necessary for @ as there is no spare read port for reading data from memory, so fetching is done by executing a high address with $4000 bit set which causes dedicated logic in the CPU to store the "instruction" fetched from memory as-is on the data stack and return. And for that, the address of execute needs to be known...
-
Hi Bernard, thank you for the quick test; I uploaded 2.6 release now. Yes, on the Verilog side, I changed the IRQOPCODE parameter (both in CPU for the default, and also in the target-specific file, in where no IRQOPCODE parameter is necessary then. On the Forth side, a lot of files changed in subtle ways: First target-specific basisdefinitions.fs does not containt "place the alu exit opcode here" anymore, as the return opcode is placed at the beginning in common-forth/nucleus-16kb-quickstore.fs now....
-
Oh, wait. I found that with the new usb_cdc code, it does not work on the FOMU anymore. Therefore: Back to the old, known good usb_cdc. I am in good faith that the moved interrupt vector will work nicely.
-
Hi Bernard, I found that I still had an ancient copy of Ulixxes usb_cdc project, and updated from the upstream Git. I also moved the interrupt vector from the end of memory to the beginning, address $0002, so that changes in memory size do not require changing the interrupt vector anymore. Could you please flash the new version and try it before I release the package? Matthias
-
Wow, great specs and a nice use case for Mecrisp-Ice! Can you add a link to your repo, please?
-
Hi Bernard, many thanks, I included you into the CREDITS file as first contributor ever for Mecrisp-Ice and released version 2.5. I left the LED flashing for now. That can be changed later when someone starts using your port. Then more sophisticated pin IO will be added probably. I wish you good luck with your BLDC motor controller!
-
Many thanks for your efforts, I would love to include the script-based build version into the next release!
-
A double cell number of milliseconds passed. As (ms) is updated in interrupt handler and double variables are read in a non-atomic way, one has to resort to read high-low-high, compare and repeat if not the same values for high.
-
Maybe you wrote "6 load" instead of "d# 6 load" in nucleus.fs? That is a quirky assembler with a Forth-like look-and-feel, but for internal reasons you need to do literals with d# 1234 or h# CAFE in the parts that are build using Gforth. Later parts (as basisdefinitions.fs) compile on the actual core in emulation and are true Forth with the usual literals.
-
Another idea that I found useful, but have not included in HX8K yet: if (io_wr & io_addr[5] & (io_addr[1:0] == 0)) pmod_out <= io_dout; if (io_wr & io_addr[5] & (io_addr[1:0] == 1)) pmod_out <= pmod_out & ~io_dout; // Clear if (io_wr & io_addr[5] & (io_addr[1:0] == 2)) pmod_out <= pmod_out | io_dout; // Set if (io_wr & io_addr[5] & (io_addr[1:0] == 3)) pmod_out <= pmod_out ^ io_dout; // Toggle For this to work, one has to reserve io_addr[1:0] but I think on some IO registers it is very useful to...
-
Mecrisp-Ice RAM images for HX8K are 16 kb, and they are aligned in flash to the 64 kb erase block size. Bitstream is in blocks 0 to 2, in your case with the bootloader present, your bitstream should be in blocks 3 to 5. You can start using block 6 then if you erase it first
-
On your issues with the load command, it depends on the contents you actually have in the SPI flash memory at this block. If random data is read into the memory it will crash, of course. If I understand right, the TinyFPGA-BX has a bootloader bitstream, and your own bitstream follows, so probably 3 load will read parts of the bitstream into the RAM. Take care with the block numbers, do not delete your bootloader bitstream! And then (without inserting 3 load into nucleus.fs) at the prompt, try erasing...
-
Hi Bernard, these pin names are a relict of the past, better change these to the actual functions! If you get all $FFs when trying to communicate with the flash chip, then maybe the SPI flash was put in deep sleep mode by the FPGA bitstream. It depends on whether the chip knows the deep sleep command; the one on HX8K did not. You can add the -s option to icepack in order to omit the sleep command. My code for a different target with deep sleep supported by the memory sends the wakeup sequence this...
-
Just a short note, not having examined the code yet: Yes, very good hint, SPI flash is accessed directly in mecrisp-ice-2.4/hx8k/nucleus.fs: main dint \ Disable interrupts welcome \ Emit welcome message d# 3 load \ Try to load image from sector 3 if available. Bitstream is in sectors 0, 1, 2. \ quit ; If you change this into main dint \ Disable interrupts welcome \ Emit welcome message quit ; It will boot without using SPI. I was not thinking on that problem because you would have seen the welcome...
-
Thank you a lot for the correction! I am thinking on it and I hope I find time at the weekend to investigate this. If you like, could you send me a tarball of your efforts so that I can search for possible issues?
-
tinyfpga-bx has the same UP5K FPGA, and I already have the FOMU port included in Mecrisp-Ice... Why did you start with the HX8K port of Mecrisp-Ice instead of just changing the pin assignments in mecrisp-ice-2.4/fomu/icestorm/fomu-pvt.pcf and recompile? You find Mecrisp-Ice releases here: https://sourceforge.net/projects/mecrisp/files/
-
Swapforth was more or less abandoned by James Bowman a long time ago, when the FOSS flow still was in its early days and had no automatic RAM inference. Initialised RAM can be defined much easier by now: // ###### MEMORY ######################################## wire mem_wr; wire [12:0] code_addr; reg [15:0] insn_from_memory; reg [15:0] mem [0:MEMWORDS-1]; initial $readmemh("build/iceimage.hex", mem); always @(posedge clk) begin insn_from_memory <= mem[code_addr]; if (mem_wr) mem[io_addr[13:1]] <=...
-
I am running ulixxe usb_cdc on the FOMU which is a UP5K with direct connections to D+ and D-. It has no USB driver chip, only a serial SPI flash. See documentation here, with ready-made examples for TinyFPGA-BX: https://github.com/ulixxe/usb_cdc/ https://github.com/ulixxe/usb_cdc/tree/main/examples/TinyFPGA-BX Changing the pin constraint file probably is all you need to port Mecrisp-Ice for FOMU to your Tiny_FPGA_BX board. Hi, I don't think I can use the ulixxe usb_cdc code, as it expects a USB driver...
1 >
