mirror of https://github.com/Desuuuu/klipper.git
docs: Add backticks around commands in Firmware Commands
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
This commit is contained in:
Kevin O'Connor
parent
d73340474b
commit
d7a1111955
|
|
@ -42,13 +42,13 @@ in "cycle_ticks=16000" on a micro-controller with a 16Mhz clock.
|
|||
|
||||
Common startup commands:
|
||||
|
||||
* set_digital_out pin=%u value=%c : This command immediately
|
||||
* `set_digital_out pin=%u value=%c` : This command immediately
|
||||
configures the given pin as a digital out GPIO and it sets it to
|
||||
either a low level (value=0) or a high level (value=1). This command
|
||||
may be useful for configuring the initial value of LEDs and for
|
||||
configuring the initial value of stepper driver micro-stepping pins.
|
||||
|
||||
* set_pwm_out pin=%u cycle_ticks=%u value=%c : This command will
|
||||
* `set_pwm_out pin=%u cycle_ticks=%u value=%c` : This command will
|
||||
immediately configure the given pin to use hardware based
|
||||
pulse-width-modulation (PWM) with the given number of
|
||||
cycle_ticks. The "cycle_ticks" is the number of MCU clock ticks each
|
||||
|
|
@ -58,7 +58,7 @@ Common startup commands:
|
|||
and 255 indicating a full on state. This command may be useful for
|
||||
enabling CPU and nozzle cooling fans.
|
||||
|
||||
* send_spi_message pin=%u msg=%*s : This command can be used to
|
||||
* `send_spi_message pin=%u msg=%*s` : This command can be used to
|
||||
transmit messages to a serial-peripheral-interface (SPI) component
|
||||
connected to the micro-controller. It has been used to configure the
|
||||
startup settings of AD5206 digipots. The 'pin' parameter specifies
|
||||
|
|
@ -80,7 +80,7 @@ for more information). After the data dictionary is obtained the host
|
|||
will check if the firmware is in a "configured" state and configure it
|
||||
if not. Configuration involves the following phases:
|
||||
|
||||
* get_config : The host starts by checking if the firmware is already
|
||||
* `get_config` : The host starts by checking if the firmware is already
|
||||
configured. The firmware responds to this command with a "config"
|
||||
response message. At micro-controller power-on the firmware always
|
||||
starts in an unconfigured state. It remains in this state until the
|
||||
|
|
@ -90,7 +90,7 @@ if not. Configuration involves the following phases:
|
|||
host/firmware session then no further action is needed by the host
|
||||
and the configuration process ends successfully.
|
||||
|
||||
* allocate_oids count=%c : This command is issued to inform the
|
||||
* `allocate_oids count=%c` : This command is issued to inform the
|
||||
firmware the maximum number of object-ids (oid) that the host
|
||||
requires. It is only valid to issue this command once. An oid is an
|
||||
integer identifier allocated to each stepper, each endstop, and each
|
||||
|
|
@ -99,9 +99,9 @@ if not. Configuration involves the following phases:
|
|||
firmware so that the firmware may allocate sufficient memory to
|
||||
store a mapping from oid to internal firmware object.
|
||||
|
||||
* config_XXX oid=%c ... : By convention any command starting with the
|
||||
"config_" prefix creates a new firmware object and assigns the given
|
||||
oid to it. For example, the config_digital_out command will
|
||||
* `config_XXX oid=%c ...` : By convention any command starting with
|
||||
the "config_" prefix creates a new firmware object and assigns the
|
||||
given oid to it. For example, the config_digital_out command will
|
||||
configure the specified pin as a digital output GPIO and create an
|
||||
internal object that the host can use to schedule changes to the
|
||||
given GPIO. The oid parameter passed into the config command is
|
||||
|
|
@ -111,9 +111,9 @@ if not. Configuration involves the following phases:
|
|||
the host sending finalize_config) and after the allocate_oids
|
||||
command has been sent.
|
||||
|
||||
* finalize_config crc=%u : The finalize_config command transitions the
|
||||
firmware from an unconfigured state to a configured state. The crc
|
||||
parameter passed to the firmware is stored in the firmware and
|
||||
* `finalize_config crc=%u` : The finalize_config command transitions
|
||||
the firmware from an unconfigured state to a configured state. The
|
||||
crc parameter passed to the firmware is stored in the firmware and
|
||||
provided back to the host in "config" response messages. By
|
||||
convention, the host takes a 32bit CRC of the firmware configuration
|
||||
it will request and at the start of subsequent host/firmware
|
||||
|
|
@ -127,34 +127,34 @@ Common firmware objects
|
|||
|
||||
This section lists some commonly used config commands.
|
||||
|
||||
* config_digital_out oid=%c pin=%u default_value=%c max_duration=%u :
|
||||
This command creates an internal firmware object for the given GPIO
|
||||
'pin'. The pin will be configured in digital output mode and set to
|
||||
an initial value as specified by 'default_value' (0 for low, 1 for
|
||||
high). Creating a digital_out object allows the host to schedule
|
||||
GPIO updates for the given pin at specified times (see the
|
||||
schedule_digital_out command described below). Should the firmware
|
||||
go into shutdown mode then all configured digital_out objects will
|
||||
be set back to their default values. The 'max_duration' parameter is
|
||||
used to implement a safety check - if it is non-zero then it is the
|
||||
maximum number of clock ticks that the host may set the given GPIO
|
||||
to a non-default value without further updates. For example, if the
|
||||
default_value is zero and the max_duration is 16000 then if the host
|
||||
sets the gpio to a value of one then it must schedule another update
|
||||
to the gpio pin (to either zero or one) within 16000 clock
|
||||
ticks. This safety feature can be used with heater pins to ensure
|
||||
the host does not set the heater to a value of one and then go
|
||||
off-line.
|
||||
* `config_digital_out oid=%c pin=%u default_value=%c
|
||||
max_duration=%u` : This command creates an internal firmware object
|
||||
for the given GPIO 'pin'. The pin will be configured in digital
|
||||
output mode and set to an initial value as specified by
|
||||
'default_value' (0 for low, 1 for high). Creating a digital_out
|
||||
object allows the host to schedule GPIO updates for the given pin at
|
||||
specified times (see the schedule_digital_out command described
|
||||
below). Should the firmware go into shutdown mode then all
|
||||
configured digital_out objects will be set back to their default
|
||||
values. The 'max_duration' parameter is used to implement a safety
|
||||
check - if it is non-zero then it is the maximum number of clock
|
||||
ticks that the host may set the given GPIO to a non-default value
|
||||
without further updates. For example, if the default_value is zero
|
||||
and the max_duration is 16000 then if the host sets the gpio to a
|
||||
value of one then it must schedule another update to the gpio pin
|
||||
(to either zero or one) within 16000 clock ticks. This safety
|
||||
feature can be used with heater pins to ensure the host does not set
|
||||
the heater to a value of one and then go off-line.
|
||||
|
||||
* config_pwm_out oid=%c pin=%u cycle_ticks=%u default_value=%c
|
||||
max_duration=%u : This command creates an internal object for
|
||||
* `config_pwm_out oid=%c pin=%u cycle_ticks=%u default_value=%c
|
||||
max_duration=%u` : This command creates an internal object for
|
||||
hardware based PWM pins that the host may schedule updates for. Its
|
||||
usage is analogous to config_digital_out - see the description of
|
||||
the 'set_pwm_out' and 'config_digital_out' commands for parameter
|
||||
description.
|
||||
|
||||
* config_soft_pwm_out oid=%c pin=%u cycle_ticks=%u default_value=%c
|
||||
max_duration=%u : This command creates an internal firmware object
|
||||
* `config_soft_pwm_out oid=%c pin=%u cycle_ticks=%u default_value=%c
|
||||
max_duration=%u` : This command creates an internal firmware object
|
||||
for software implemented PWM. Unlike hardware pwm pins, a software
|
||||
pwm object does not require any special hardware support (other than
|
||||
the ability to configure the pin as a digital output GPIO). Because
|
||||
|
|
@ -163,13 +163,13 @@ This section lists some commonly used config commands.
|
|||
time of 10ms or greater. See the description of the 'set_pwm_out'
|
||||
and 'config_digital_out' commands for parameter description.
|
||||
|
||||
* config_analog_in oid=%c pin=%u : This command is used to configure a
|
||||
pin in analog input sampling mode. Once configured, the pin can be
|
||||
* `config_analog_in oid=%c pin=%u` : This command is used to configure
|
||||
a pin in analog input sampling mode. Once configured, the pin can be
|
||||
sampled at regular interval using the query_analog_in command (see
|
||||
below).
|
||||
|
||||
* config_stepper oid=%c step_pin=%c dir_pin=%c min_stop_interval=%u
|
||||
invert_step=%c : This command creates an internal stepper
|
||||
* `config_stepper oid=%c step_pin=%c dir_pin=%c min_stop_interval=%u
|
||||
invert_step=%c` : This command creates an internal stepper
|
||||
object. The 'step_pin' and 'dir_pin' parameters specify the step and
|
||||
direction pins respectively; this command will configure them in
|
||||
digital output mode. The 'invert_step' parameter specifies whether a
|
||||
|
|
@ -180,7 +180,7 @@ This section lists some commonly used config commands.
|
|||
ticks since the last step. It is used as a check on the maximum
|
||||
stepper velocity that a stepper may have before stopping.
|
||||
|
||||
* config_end_stop oid=%c pin=%c pull_up=%c stepper_count=%c : This
|
||||
* `config_end_stop oid=%c pin=%c pull_up=%c stepper_count=%c` : This
|
||||
command creates an internal "endstop" object. It is used to specify
|
||||
the endstop pins and to enable "homing" operations (see the
|
||||
end_stop_home command below). The command will configure the
|
||||
|
|
@ -196,22 +196,22 @@ Common commands
|
|||
This section lists some commonly used run-time commands. It is likely
|
||||
only of interest to developers looking to gain insight into Klippy.
|
||||
|
||||
* schedule_digital_out oid=%c clock=%u value=%c : This command will
|
||||
* `schedule_digital_out oid=%c clock=%u value=%c` : This command will
|
||||
schedule a change to a digital output GPIO pin at the given clock
|
||||
time. To use this command a 'config_digital_out' command with the
|
||||
same 'oid' parameter must have been issued during firmware
|
||||
configuration.
|
||||
|
||||
* schedule_pwm_out oid=%c clock=%u value=%c : Schedules a change to a
|
||||
hardware PWM output pin. See the 'schedule_digital_out' and
|
||||
* `schedule_pwm_out oid=%c clock=%u value=%c` : Schedules a change to
|
||||
a hardware PWM output pin. See the 'schedule_digital_out' and
|
||||
'config_pwm_out' commands for more info.
|
||||
|
||||
* schedule_soft_pwm_out oid=%c clock=%u value=%c : Schedules a change
|
||||
to a software PWM output pin. See the 'schedule_digital_out' and
|
||||
'config_soft_pwm_out' commands for more info.
|
||||
* `schedule_soft_pwm_out oid=%c clock=%u value=%c` : Schedules a
|
||||
change to a software PWM output pin. See the 'schedule_digital_out'
|
||||
and 'config_soft_pwm_out' commands for more info.
|
||||
|
||||
* query_analog_in oid=%c clock=%u sample_ticks=%u sample_count=%c
|
||||
rest_ticks=%u min_value=%hu max_value=%hu : This command sets up a
|
||||
* `query_analog_in oid=%c clock=%u sample_ticks=%u sample_count=%c
|
||||
rest_ticks=%u min_value=%hu max_value=%hu` : This command sets up a
|
||||
recurring schedule of analog input samples. To use this command a
|
||||
'config_analog_in' command with the same 'oid' parameter must have
|
||||
been issued during firmware configuration. The samples will start as
|
||||
|
|
@ -225,16 +225,16 @@ only of interest to developers looking to gain insight into Klippy.
|
|||
thermistors controlling heaters - it can be used to check that a
|
||||
heater is within a temperature range.
|
||||
|
||||
* get_status : This command causes the firmware to generate a "status"
|
||||
response message. The host sends this command once a second to
|
||||
obtain the value of the micro-controller clock and to estimate the
|
||||
drift between host and micro-controller clocks. It enables the host
|
||||
to accurately estimate the micro-controller clock.
|
||||
* `get_status` : This command causes the firmware to generate a
|
||||
"status" response message. The host sends this command once a second
|
||||
to obtain the value of the micro-controller clock and to estimate
|
||||
the drift between host and micro-controller clocks. It enables the
|
||||
host to accurately estimate the micro-controller clock.
|
||||
|
||||
Stepper commands
|
||||
----------------
|
||||
|
||||
* queue_step oid=%c interval=%u count=%hu add=%hi : This command
|
||||
* `queue_step oid=%c interval=%u count=%hu add=%hi` : This command
|
||||
schedules 'count' number of steps for the given stepper, with
|
||||
'interval' number of clock ticks between each step. The first step
|
||||
will be 'interval' number of clock ticks since the last scheduled
|
||||
|
|
@ -248,21 +248,22 @@ Stepper commands
|
|||
queue potentially hundreds of thousands of steps - all with reliable
|
||||
and predictable schedule times.
|
||||
|
||||
* set_next_step_dir oid=%c dir=%c : This command specifies the value
|
||||
* `set_next_step_dir oid=%c dir=%c` : This command specifies the value
|
||||
of the dir_pin that the next queue_step command will use.
|
||||
|
||||
* reset_step_clock oid=%c clock=%u : Normally, step timing is relative
|
||||
to the last step for a given stepper. This command resets the clock
|
||||
so that the next step is relative to the supplied 'clock' time. The
|
||||
host usually only sends this command at the start of a print.
|
||||
* `reset_step_clock oid=%c clock=%u` : Normally, step timing is
|
||||
relative to the last step for a given stepper. This command resets
|
||||
the clock so that the next step is relative to the supplied 'clock'
|
||||
time. The host usually only sends this command at the start of a
|
||||
print.
|
||||
|
||||
* stepper_get_position oid=%c : This command causes the firmware to
|
||||
* `stepper_get_position oid=%c` : This command causes the firmware to
|
||||
generate a "stepper_position" response message with the stepper's
|
||||
current position. The position is the total number of steps
|
||||
generated with dir=1 minus the total number of steps generated with
|
||||
dir=0.
|
||||
|
||||
* end_stop_home oid=%c clock=%u rest_ticks=%u pin_value=%c : This
|
||||
* `end_stop_home oid=%c clock=%u rest_ticks=%u pin_value=%c` : This
|
||||
command is used during stepper "homing" operations. To use this
|
||||
command a 'config_end_stop' command with the same 'oid' parameter
|
||||
must have been issued during firmware configuration. When invoked,
|
||||
|
|
|
|||
Loading…
Reference in New Issue