Remora - Rpi Software Stepping Using External Microcontroller via SPI

 

I bought a 3d printerboard from btt with a 407 (and 103, but was for another picnc port)  to specifically play with your port of picnc, and was rather disappointed when it disappeared from github the other day, but I see it has come back in a better form. I can assume its the stm32 remora? On the 103, is the ram/flash limitation only an issue if you load it directly to the board? The configuration, can you elaborate more on that?  On time sent over serial or like at the start of every boot (like a mesa or something) ? 

Yes you have to reprogram every boot. I plan on attaching an eeprom to my board, when I figure out
how to attach my rtc/eeprom combo board and actually learn how to read and write an eeprom

Hi Scott,
thanks. I'm just learning on the fly praticing my google-fu.
I will try and check Mbed tho.
What I really wanted is to build something I could fix myself.

mhel wrote:

Hi Scott,
thanks. I'm just learning on the fly praticing my google-fu.
I will try and check Mbed tho.
What I really wanted is to build something I could fix myself.

both are supported by mbed. also, does the config need to be loaded every time because you are using  dev boards?  

mhel wrote:

Hi Scott,
thanks. I'm just learning on the fly praticing my google-fu.
I will try and check Mbed tho.
What I really wanted is to build something I could fix myself.

Hi, Just thinking how this could evolve. Having a core code base that can call in LPC176x and STM32 dependencies would ease future maintainability. Of course we'd need to move to a community development and support mode as well.

Should I put together a schematic, gerbers and a BOM to give out to the Chinese to clone using STM32? Then everyone can get cheap boards with docs. Worst case you'll just have to add the parts they leave out to save a few $$.

I'd like to know which chip they are using as fake STM32's.

 

Hi, Just thinking how this could evolve. Having a core code base that can call in LPC176x and STM32 dependencies would ease future maintainability. Of course we'd need to move to a community development and support mode as well.

 

I think Mbed platform is the way to go, it's well supported.
I downloaded the IDE, if I could make a blinky and a serial working with it, I could probably get it going.

The board Aaroncnc posted is a very good candidate, If I have a 3d printer, I'd get one myself.

FYSETC S6 V2

cakeslob wrote:

 does the config need to be loaded every time because you are using  dev boards?  

Yes, I don't have an sdcard on my board. this is exactly what I have STM32F4
The advantage of the PRU is, if your board has the same chip but different layout
you could (most likely) still use the firmware.
If I didn't make my port programmable  it would have been way better for me.
That configuration by serial port literally gave me a headache

mhel wrote:

 

Hi, Just thinking how this could evolve. Having a core code base that can call in LPC176x and STM32 dependencies would ease future maintainability. Of course we'd need to move to a community development and support mode as well.

 

I think Mbed platform is the way to go, it's well supported.
I downloaded the IDE, if I could make a blinky and a serial working with it, I could probably get it going.

The board Aaroncnc posted is a very good candidate, If I have a 3d printer, I'd get one myself.

FYSETC S6 V2

I need to do some more research, but I think the STM32 boards that support Marlin firmware are utilising a bootloader to flash the bin file from the SD card, just like the LPC176x boards. We'd need to be able to configure Mbed Studio for the appropriate STM target and be able to output a bin file with the correct starting address for the bootloader to jump to. It should be possible, as it was one of the first steps I had to do for the LPC176x boards. It was more straight forward though as Smoothieware was originally based on the Mbed framework.

u-boot wiki.st.com/stm32mpu/wiki/U-Boot_overview

www.denx.de/wiki/U-Boot