ask question about G2 for porting to STM32F415 MCU

[wjzhang]

Hi: I'm now try porting tinyG2 edge branch to STM32F415 MCU.
i use USART to communicate with PC. I have some questions:

1. the MoatateBuffer: the RXBuffer to start transfer, it call UART/UARTUSB/... module startRXTransfer() function, it seem unbreakable, it need receive all request datas. first time it about 1024 bytes. then return. why use this design?

2. the dda_timer, exec_timer, fwd_plan_timer are just 3 simple timer, No necessary use necessary. right?

[justinclift]

@aldenhart @giseburt ping

[wjzhang]

sorry, type error. question 2: "No necessary use TimerChannel"

[giseburt]

Hello,

Sorry for the slow response.

1. The transfer is generally handled using DMA or DMA-like interrupts, and so there are two asynchronous loops nested here. The outer-most loop exists completely in g2core, and consists of other parts of the system calling readline (which there is a global readline that calls the individual port readlines and eventually the LineRXBuffer one here) and from there the process goes roughly:

   1. If the buffer is not full, call LineRXBuffer::_restartTransfer() which is actually RXBuffer::_restartTransfer() which handles all the logic to determine what contiguous space in the circular buffer can be filled next and then calls _owner->startRXTransfer(write_pos, transfer_size, write_pos_extra, transfer_size_extra)

   2. _owner is the object that handles the hardware directly. It can be a UART, USART, USB serial, etc. RXBuffer doesn’t care, really. RXBuffer just asks that something setup the hardware to fill this buffer asynchronously.

   3. When the transfer is “done” (as done as it will get, either fully or as much as the hardware can for now) then the function set in _owner->setRXTransferDoneCallback(...) gets called by _owner. Note that RXBuffer sets that.

   4. At some point later _restartTransfer() is called again from the outer logic and the loop continues.

TXBuffer works in much the same way, except g2core doesn’t really wrap any extra logic around it, so it’s used directly to send a buffer and report back when it’s done. (LineRXBuffer handles the line and special character processing that RXBuffer knows nothing about, and shouldn’t.)

One other vital function is _owner->getRXTransferPosition() which must report back the last received character (as position in the buffer currently being filled) so that the system knows what portion of the buffer has valid and new data in it. This is something the DMA subsystem generally provides in a register. If simulating DMA with interrupts then the hardware object will need to track this is a similar way.

2. I’m not sure about this question. Yes, they are somewhat simple timers, in that they simply setup the hardware timer to fire an interrupt at the requested frequency at the requested interrupt level. However, they are vital to the functionality of g2core, so they must be used and available functionality.

[giseburt]

Note I updated my last comment, so if reading via email you might want to check the website.

[wjzhang]

giseburt, Thanks! I see. the _owner->startRXTransfer() is prepare receive datas, and use _owner->getRXTransferPosition() update real receive datas.

[Tardusas]

Hi, has anybody ported G2 to STM32F407VGT6, is it possible?

I have an SKR 2.0 board with STM32F407VGT6 I would love to use g2core with TMC2209 without any additional shields.

@wjzhang have you managed to port it to STM32F415?

[wjzhang]

@Tardusas: No. It's postponed.