What’s the stance on RRF on none Duet boards?

jay_s_uk

@zapta that board won't get added in its current form.
They've chosen an MCU with only 512kb of flash and the firmware as it stands is already bigger than that for a wifi build
They are releasing a 407 version I believe. Lets just hope they choose the right processor

zapta

@jay_s_uk said in What’s the stance on RRF on none Duet boards?:

Lets just hope they choose the right processor

Just posted an EDIT. The RRF processor is STM32F407VGT6

jay_s_uk

@zapta thats the same processor used on the Fly-E3, E3-Pro, SKR-RRF-E3 and SKR 2.
The next challenge is getting the information for it or even getting a board for testing.

zapta

@jay_s_uk, when I click on Compatible Boards at https://www.reprapfirmware.org/ it shows only Duet3d boards.

Have you tried discussing with reprapfirmware.org owners (Duet3d?) having a more vendor neutral page that lists all boards?

The boundary between RRF and Duet3d is confusing to me.

jay_s_uk

@zapta
Never even thought about that page.
I would have to approach duet3d about it.

dc42

@jay_s_uk said in What’s the stance on RRF on none Duet boards?:

@zapta that board won't get added in its current form.
They've chosen an MCU with only 512kb of flash and the firmware as it stands is already bigger than that for a wifi build

Bigger than 512kb? Sounds odd to me. Duet2CombinedFirmware for the Duet WiFi and Ethernet is currently 500kb and has the code for both WiFi and Ethernet included. It's only the Duet 3 and 3 Mini builds with CAN support that are bigger than 512kb.

jay_s_uk

@dc42 Yep, this is from Andy

The latest development WiFi build (which by default loads at address 0x08008000 (so we allow 32K for the bootloader) already uses flash memory up to 0x0808fecc which is a total of 543Kb of flash which means a total size (with the bootloader) of 575kBytes.

dc42

@jay_s_uk I see, it's because 32kb is already taken up by the bootloader.

jay_s_uk

@dc42 yep

I also don't know how much the board.txt functionality and multiple board support takes up.
We also produce separate builds for wifi and SBC

gloomyandy

@dc42 There is a further 32K that is used for NVM emulation to hold the stack/registers after a reset. This is rather wasteful but on the chips we currently support not really an issue.

Some other things are also a little different in that we have additional code to support any mixture of TMC2208/2209/5160 drivers. A software based UART (for TMC drivers) and software SPI. I'm also pretty sure that our CoreN2G has rahter more in it than strictly needed.