Checklist
Feature description
Some devices have a reset circuitry that are sensitive to slow RTS/DTR changes. The current await this.transport.setDTR() and await this.transport.setRTS() seems to cause enough delay on some platforms to make the reset fail.
This is the current reset sequence:
export class ClassicReset implements ResetStrategy {
resetDelay: number;
transport: Transport;
constructor(transport: Transport, resetDelay: number) {
this.resetDelay = resetDelay;
this.transport = transport;
}
async reset() {
await this.transport.setDTR(false);
await this.transport.setRTS(true);
await sleep(100);
await this.transport.setDTR(true);
await this.transport.setRTS(false);
await sleep(this.resetDelay);
await this.transport.setDTR(false);
}
}
Using this work around was enough to make those devices reset as expected:
/**
* Custom reset sequence
*/
const resetConstructors: ResetConstructors = {
classicReset: (transport: Transport, resetDelay: number) => {
const classicReset = new ClassicReset(transport, resetDelay);
// Override the reset function
classicReset.reset = async () => {
console.log("Using classic reset sequence");
const serialDevice: NativeSerialPort = transport.device;
// D0|R1|W100|D1|R0|W50|D0
await serialDevice.setSignals({
dataTerminalReady: false,
requestToSend: true
});
await new Promise((r) => setTimeout(r, 100));
await serialDevice.setSignals({
dataTerminalReady: true,
requestToSend: false
});
await new Promise((r) => setTimeout(r, 50));
await serialDevice.setSignals({
dataTerminalReady: false,
requestToSend: false
});
return Promise.resolve();
};
return classicReset;
}
};
I propose that we expose a new function in Transport for setting both RTS/DTR signals at the same time and modify the Classic reset to use that function.
Use cases
This will make the reset sequence more reliable on a wider set of devices with different reset circuitry.
Alternatives
In our case we need to apply our own reset constructor and override the default reset logic if this is not changed upstream.
Additional context
This is the project:
https://github.com/breiler/fluid-installer/blob/custom-reset/src/utils/flash.ts#L77
PS, thanks for your efforts with this library!
Checklist
Feature description
Some devices have a reset circuitry that are sensitive to slow RTS/DTR changes. The current
await this.transport.setDTR()andawait this.transport.setRTS()seems to cause enough delay on some platforms to make the reset fail.This is the current reset sequence:
Using this work around was enough to make those devices reset as expected:
I propose that we expose a new function in
Transportfor setting both RTS/DTR signals at the same time and modify the Classic reset to use that function.Use cases
This will make the reset sequence more reliable on a wider set of devices with different reset circuitry.
Alternatives
In our case we need to apply our own reset constructor and override the default reset logic if this is not changed upstream.
Additional context
This is the project:
https://github.com/breiler/fluid-installer/blob/custom-reset/src/utils/flash.ts#L77
PS, thanks for your efforts with this library!