WhyCan Forum(哇酷开发者社区)

xiaohui -

i'm trying to get a bare-metal port of newest FreeRTOS working. I have a bootloader that will load my code, i've got everything compiling and console output BEFORE vTaskStartScheduler(), console output from the beginning of the first task (only task besides idle).

all programming/compiling on Windows with the C-Sky Development Suite.

my problem is that my tick interrupt isn't working. i haven't been able to figure the 32 physical address for the MTIME and MTIMECMP

#define configMTIME_BASE_ADDRESS     ( ? )
#define configMTIMECMP_BASE_ADDRESS ( ? )

i've read through D1/F133 manuals and C906 manual and can't quite get the proper address. i think i've got to use the CLINT base + some offsets.

any guidance or suggestions would be very much appreciated.

-Ed

Similar information request. Working on a SPL for F133. BUT as a Windows Eclipse xpack GNU risc-v project.

Have a lot working but trying to do simple DRAM init.

Have researched D1 mainline SPL, xboot, and xfel github source code. Almost got it by grabbing mctl_hal.s from xfel. But this environment chokes on the assembler code. I think it has T-head extensions in it (lrbu for one).

mctl_hal.s appears to be compiler generated code. Do xboot/xfel authors have access to mctl_hal.c? I found an old one from 2014 on github but doubt if it will play we'll.

Assistance or guidance much appreciated.

Thanx,

Ed

@unturned3

after years of fighting flash/ram sizes in MCU (PIC32, PSOC5, XMC4500, etc) the ability to program/buffer in a 64MB memory is unbelievable. we've had 10Base-T, then 100Base-T but very few MCU have 1000Base-T. one thing we fight in professional lighting displays is latency so the faster/wider the pipelines the better. we use an FPGA to take a buffer of lighting data and custom generate peripherals that are tailored to the pixel protocols. no need for fooling spi/uart to do the job with our custom drivers nailed to the protocol. not the only way to get there, just a path we are taking. we are near production on SSD212 products but they have been so difficult to work with on documentation. porting the drivers from linux to freertos when you don't know the register bits has been a pain in the ....

just our humble opinion after many years of product development.

there are no rules, and those are the rules  (Fraggle Rock)

Thanx all for input. Next Month is Monday, i'll order then  ;^)

@Blueskull
Not targeting SDIO, just an example. i can control the interface into my FPGA but can't on other chips. i may have need for other chips that will use SPI and by moving FPGA hi speed channel to SDIO it would free up SPI channels. Not reinventing the wheel, just porting years of knowledge/development on MCU platforms to this environment.