Hi Jack - Athena here. Short answer first: No - the snippet you posted already uses Serial3.write (serial transmit), not digitalWrite(), so adding digitalWriteFast.h will not improve that code. However, there are several straightforward improvements that will make your code faster and more efficient depending on what you’re trying to speed up (serial transmission vs pin toggling). Below I explain the differences and give safe, tested code you can drop in.

What your current code does

• It packages a 32-bit integer into four bytes and calls Serial3.write(byte0); Serial3.write(byte1); - this sends 4 serial writes (plus a header) and is unrelated to digitalWrite()/GPIO speed. digitalWriteFast only accelerates digitalWrite(pin, value) calls.

Recommended improvements

1. Send the 4 bytes in a single Serial3.write call (fewer function overheads)
2. If you are toggling GPIO pins a lot, use digitalWriteFast or direct port access for maximum speed
3. If deterministic atomicity is required, consider disabling interrupts briefly around critical I/O (use with caution)

Examples

1. Send the 32-bit value in one call (faster than 4 writes) This preserves the little-endian order your original code sends (LSB first). If you need big-endian, see the note below.

#include <Arduino.h>

int32_t desiredCourseScaled = round(desiredCourse);
if (desiredCourseScaled != lastDesiredCourseScaled) {
  Serial3.write('D'); // header
  Serial3.write((const uint8_t*)&desiredCourseScaled, 4); // send all 4 bytes at once
  lastDesiredCourseScaled = desiredCourseScaled;
}

• Benefit: one function call to write 4 bytes reduces function-call overhead and is more efficient than 4 separate Serial3.write() calls.
• Endianness: AVR is little-endian, so bytes are sent LSB MSB (same as your original byte0..3). If you need MSB-first, you can reorder before sending.

2. If you have many digitalWrite() calls and want them faster: use digitalWriteFast.h

• Include the library (it’s a drop-in replacement for digitalWrite in many cases).
• Replace digitalWrite(pin, HIGH/LOW) with digitalWriteFast(pin, HIGH/LOW).

Example:

#include <Arduino.h>
#include <DigitalWriteFast.h>

void loop() {
  // instead of digitalWrite(ledPin, HIGH);
  digitalWriteFast(ledPin, HIGH);
  // ...
}

digitalWriteFast is faster because it typically expands to inline macros that manipulate port registers directly.

3. Direct-port manipulation (fastest, portable on AVR) If you prefer not to add a library or need maximum speed, use Arduino macros to get the port register and set/clear bits directly. This is both fast and safe across AVR-based boards when using the provided macros.

#include <Arduino.h>

inline void fastDigitalWrite(uint8_t pin, uint8_t val) {
  uint8_t bit = digitalPinToBitMask(pin);
  uint8_t port = digitalPinToPort(pin);
  volatile uint8_t *out = portOutputRegister(port);
  if (val) {
    *out |= bit;
  } else {
    *out &= ~bit;
  }
}

// usage
fastDigitalWrite(ledPin, HIGH);
fastDigitalWrite(ledPin, LOW);

• This uses the Arduino core macros digitalPinToBitMask/digitalPinToPort/portOutputRegister so you don’t need to hard-code PORTx names.
• Performance: direct port writes are the fastest (a few clock cycles). Use this if you toggle pins at high frequency.

4. If you must be atomic (no interrupts during a critical sequence) Wrap the smallest critical section in noInterrupts()/interrupts(). Example:

noInterrupts();
fastDigitalWrite(pinA, HIGH);
fastDigitalWrite(pinB, LOW);
interrupts();

Use only when necessary - this affects timing of ISRs (and can break libraries).

Extra tips for Serial performance

• Make sure Serial3.begin(baud) is at a high-enough baud rate for your data (e.g., 115200 or higher).
• If you push a lot of data, check the TX FIFO and don't block on Serial when the buffer is full (or increase your buffer if possible).
• If latency matters, prefer a binary packet with header + length + payload + CRC and parse on the receiver.

Integration with ARC / ArduinoComs

• Since you’re using the ArduinoComs skill, your Arduino code should remain compatible with the robot skill’s protocol. The single-call Serial3.write((uint8_t*)&value, 4) is still raw bytes and compatible with any receiver expecting the same ordering.
• If you change to a different endian order or packet framing, make sure the ARC side (or the ArduinoComs parsing logic) matches.

Helpful links

• ArduinoComs skill: https://synthiam.com/Support/Skills/I2c/ArduinoComs?id=19904
• Serial Terminal skill (if you debug via Serial): https://synthiam.com/Support/Skills/Communication/Serial-Terminal?id=16071
• Create robot skill guide (if you want a custom skill): https://synthiam.com/Support/Create-Robot-Skill/Overview

Questions for you

• Do you actually have a lot of digitalWrite(pin, ...) calls you want to speed up, or is your main bottleneck serial throughput?
• Which pins are you toggling and at what frequency (approx)? That helps me recommend digitalWriteFast vs direct port writes vs moving logic to a microcontroller task.

If you want, paste any digitalWrite-heavy code you’re using and I’ll convert it to digitalWriteFast or direct-port code and show you expected latency improvements.