@jazbaatbadalgaye I think the clue is in this line you posted above:

dm->bin[index]++;

assuming "dm" above is a DriveMovement object, that means the "bin" array is also defined within the DriveMovement class. RRF creates a whole pool of DM objects initially, and looking at Move.h, this is going to be 83 or 125 depending on which board you are using.

So on a duet2, with a "bin" array size of 40, this would end up requiring an additional 13,280 bytes

@bearer said in Quest: Duet2Wifi + SBC without ESPectomy. Possible?:

oh that firmware, that does make more sense, and a lot simpler. will try!
(but CH_PD/EN is still hardwired to ESP_3.3VIN, maybe reset is enough)

Interestingly, someone posted some tests on pin states in various modes including held in reset over here: https://www.mjt.me.uk/posts/esp8266-gpio-deep-sleep-and-reset/

@fythios DuetWifiServer uses SPI to communicate with the main board and in the LPC port this is assumed to be connected to SSP0.

@dc42 I came across a minor issue in 3.01RC2 (tested on DuetWifi). The gcode line numbers do not reset each time M32 is run, so a gcode file that contains conditional gcode errors will display the incorrect line number if it's not the first one run since reset.

@dc42 btw there is a missing buf->whenQueued = millis(); in OutputBuffer::Allocate. Probably more a issue only affecting the LPC port due to the smaller UART ringbuffer, but was causing some buffers to incorrectly timeout.