Search found 105 matches
- Wed Jan 17, 2024 11:21 am
- Forum: Cortex-M0, M3, M4 and M7
- Topic: RP2040: Library & Tools for Astrobe Available
- Replies: 11
- Views: 10804
Re: RP2040: Library & Tools for Astrobe Available
Made a few library changes, mostly to the text output machinery: https://oberon-rtk.org/description/changes-2024-01-17/ Added a new example program, showing how to avoid busy waiting for a peripheral: https://oberon-rtk.org/examples/nobusywaiting/ Edited the kernel description for structure and hope...
- Mon Jan 15, 2024 9:45 am
- Forum: Cortex-M0, M3, M4 and M7
- Topic: RP2040: Library & Tools for Astrobe Available
- Replies: 11
- Views: 10804
RP2040: Library & Tools for Astrobe Available
Today, I have made available a first set of Oberon modules to program the RP2040 using Astrobe for Cortex-M0, v9.0.3. There's also a tool to transmogrify Astrobe '.bin' file to the contents and UF2 format for the RP2040. The library contains as of today: 1) Basics to get off the ground: clocks, rese...
- Mon Dec 18, 2023 1:37 pm
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Buffer Address for DMA
- Replies: 3
- Views: 10083
Re: Buffer Address for DMA
Interesting. Yes, this works, again a) checking the code and b) running a test program. Surprising though. The Astrobe docs about module system say: ADR returns the absolute address of the given variable. Now, that SYSTEM.ADR of a VAR procedure parameter would return the actual address of the argume...
- Mon Dec 18, 2023 10:13 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Buffer Address for DMA
- Replies: 3
- Views: 10083
Buffer Address for DMA
To avoid busy-waiting at a serial output peripheral (USART), I am implementing buffered text output to a terminal. The intention is to use the DMA peripheral on the M0. Among other configuration, the DMA channel expects 1) a memory address of the buffer, and 2) the number of data items to transfer f...
- Fri Nov 17, 2023 9:54 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Interrupt Handlers
- Replies: 2
- Views: 8616
Re: Interrupt Handlers
Wow. Smart. I am impressed. Thanks for that.
- Thu Nov 16, 2023 12:26 pm
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Interrupt Handlers
- Replies: 2
- Views: 8616
Interrupt Handlers
For the Cortex-M0, the prologue and epilogue generated for interrupt handlers is the same as for normal parameterless procedures. That is, they are the same for PROCEDURE p0; END p0; 0B500H push { lr } 046C0H nop 0BD00H pop { pc } 046C0H nop and PROCEDURE p1[0]; END p1; 0B500H push { lr } 046C0H nop...
- Sat Jun 17, 2023 4:41 am
- Forum: Astrobe for FPGA RISC5
- Topic: SYSTEM.LDREG
- Replies: 4
- Views: 92622
Re: SYSTEM.LDREG
SYSTEM.LDREG is also used in Oberon.Mod, and its sibling SYSTEM.REG in Kernel.Mod, Modules.Mod, System.Mod, as well as in the bootloader. SYSTEM.H, probably another undocumented feature, is used in Kernel.Mod. Hence, without undocumented features, no Oberon system as we know it.
- Wed Jun 14, 2023 1:08 pm
- Forum: Astrobe for FPGA RISC5
- Topic: SYSTEM.LDREG
- Replies: 4
- Views: 92622
Re: SYSTEM.LDREG
Just re-reading some old forum posts... and it occurred to me that, undocumented or not, SYSTEM.LDREG is arguably the most central feature of the compiler. Without it, the system would not even boot. See the bootloader, it's literally the first instruction the system executes. :)
- Fri Jun 02, 2023 6:17 am
- Forum: Astrobe for FPGA RISC5
- Topic: Embedded Project Oberon on Altera FPGA
- Replies: 0
- Views: 20008
Embedded Project Oberon on Altera FPGA
I have implemented the Embedded Project Oberon (EPO) RISC5 CPU and environment in an Intel Altera FPGA, specifically, using the Terasic Cyclone V GX Starter Kit board [1]. It's a nice board in the same price range as the Digilent Arty A7 100, with lots of LEDs, switches, buttons, SRAM, seven segment...
- Thu Apr 20, 2023 5:16 am
- Forum: Astrobe for FPGA RISC5
- Topic: Stack Trace
- Replies: 0
- Views: 24192
Stack Trace
I have always found a "stack trace", ie. the display of the chain of procedure calls that lead to an error, very useful to find the causes of run-time problems. This chain is unrolled by walking the stack backwards from the error point -- or from any state of calls -- frame by frame using the frame ...