ok in a fit of impulse, I've got one of this in the mail bag
https://github.com/WeActStudio/WeActStu ... CoreBoard/
viewtopic.php?p=14821#p14821
it is quite a nice board (looking at it really)
but that I'm yet to try anything on it
I'm not sure if it'd help to try probe the sd over SPI at least maybe read some registers etc, before even trying a full SDIO.
SDIO should be really fast I'd guess (if it works), possibly in the mega(Bytes) per second type of benchmarks, at least for read
But I'd think in addition, things like DMA would need to be involved, if one really wants to go the distance, without DMA megabytes level transfer rates would continue to be a pipe dream.
STM32H562 board and STM32SD - problems
Re: STM32H562 board and STM32SD - problems
oh yes, if you got it all up and running
try the whetstone benchmark, with FPU and all
viewtopic.php?p=106#p106
https://github.com/stm32duino/STM32Exam ... ePrecision
it'd be good if it can clock like 200 Mflops (single precision)
but it'd be amazing if it can clock 500 Mflops, this is only possible if it can really do 2xSIMD per clock cycle and that the calcs are a fit for that, I'm not sure if whetstone calcs may after all be vectorized, maybe not.
a 'nagging' feel is that, multi-(smp)-core may be a next thing to happen, it complicates programming and IO handling and it may require simplifications as like only one core handles the io given the highly memory constrained environment.
it turns out 'real' smp requires hardware more than a 'simple' NVIC concept.
https://developer.arm.com/documentation/ihi0048/latest/
^ this is only there in cortex A multi-core
try the whetstone benchmark, with FPU and all
viewtopic.php?p=106#p106
https://github.com/stm32duino/STM32Exam ... ePrecision
it'd be good if it can clock like 200 Mflops (single precision)
but it'd be amazing if it can clock 500 Mflops, this is only possible if it can really do 2xSIMD per clock cycle and that the calcs are a fit for that, I'm not sure if whetstone calcs may after all be vectorized, maybe not.
a 'nagging' feel is that, multi-(smp)-core may be a next thing to happen, it complicates programming and IO handling and it may require simplifications as like only one core handles the io given the highly memory constrained environment.
it turns out 'real' smp requires hardware more than a 'simple' NVIC concept.
https://developer.arm.com/documentation/ihi0048/latest/
^ this is only there in cortex A multi-core
Re: STM32H562 board and STM32SD - problems
I'm currently working on STM32SD library and found a bug around the setxxx api.
I've fixed it --> https://github.com/stm32duino/STM32SD/pull/76
In the meantime I've bought this board and do the test.
If no SD DETECT set it works.
Anyway, it fails with SD Detect set as PA8.
The pin is properly configured but the level detection is set to Low while on this board it is high.
This is the first board like this. So, I've made another PR to allow to specify SD detect level --> https://github.com/stm32duino/STM32SD/pull/77
Now it works like this using a new generic I've made for the H562RGT:
I've fixed it --> https://github.com/stm32duino/STM32SD/pull/76
In the meantime I've bought this board and do the test.
If no SD DETECT set it works.
Anyway, it fails with SD Detect set as PA8.
The pin is properly configured but the level detection is set to Low while on this board it is high.
This is the first board like this. So, I've made another PR to allow to specify SD detect level --> https://github.com/stm32duino/STM32SD/pull/77
Now it works like this using a new generic I've made for the H562RGT:
Code: Select all
#ifndef SD_DETECT_PIN
#define SD_DETECT_PIN PA8
#endif
void setup()
{
Serial.setRx(PA10);
Serial.setTx(PA9);
Serial.begin(9600);
while (!Serial);
SD.setDx(PC8, PC9, PC10, PC11);
SD.setCMD(PD2);
SD.setCK(PC12);
/* Test begin() method */
while (!SD.begin(SD_DETECT_PIN, HIGH))