I didn't update the buildinstructions.md file after I added the Tools folder to the github project. I have done so now.

I have modified the source code to declare the time field in the software reset data as 32 bits unsigned, with casts to and from time_t where necessary. This will be in the 1.21RC3 source code.

Oh, silly me. Thanks for the heads up.

Constant time password comparison is now implemented and will be released in 1.21RC2.

The tacho will only read correctly when the fan is operating at full speed, not if you are using PWM to reduce the speed. But if it is the hot end fan that you want to monitor, you are probably running that at full speed already.

The firmware is already set up to read and display the RPM of one fan. Connect the tacho wire through a diode (1N4148 or similar should work) to pin PB6 on the expansion connector. The cathode of the diode (the end with the stripe) goes to the tacho wire.

Confirmed, it will be FreeRTOS. It's small, well-documented, and the source code is MISRA-compliant. I have started work on adapting RRF to use it already. I am using version 10.0.0.

Yes.

@fma:

Good!

But I think I found the issue. The string:

"${workspace_loc:/${CoreName}/SAM4E8E/cores/arduino/syscalls.o}"

should be :

"${workspace_loc}:/${CoreName}/SAM4E8E/cores/arduino/syscalls.o}"

There where a missing bracket at the end of the workspace_loc var…

Can you confirm?

Recently I was getting this issue intermittently. I think it is an Eclipse bug. So in the latest commit I changed the path to this:

"${workspace_loc}/${CoreName}/SAM4E8E/cores/arduino/syscalls.o"

This seems to have resolved it.

Btw I just experienced the problem that some other users have reported, which is that the expression "${workspace_loc:/${CoreName}/SAM4E8E/cores/arduino/syscalls.o}" in the linker command line got expanded to "". Right-clicking on the project and selecting Refresh resolved it.

Support could be added to PanelDue and DWC to accept gcodes passed to it through messages.

So the message would include the prompt to the user, then some syntax that provides a button (or series of buttons) that the user can press that executes gcode.

Obviously, this only works well if the message is presented at the end of a gcode file, and gives the user options to initiate other gcode macros.

I would also be interested in a way to get the current position (triggered by an input being made high or low, or when an analog sense pin reaches a certain value). Maybe looking at the firmware code for how the endstops/homing works can help.

This was available in Marlin and was very useful for my printer. Hopefully get_position() can be incorporated into RRF.

Ok, thanks.

See https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins.