Rather than using a full w1_read_byte() to wait for the temperature
sensor to indicate a result is ready introduce a w1_read_bit() and
use that instead. This lets us service USB requests more often while
waiting for the result.
A client can decide to reset us if we fail to reply to USB messages
appropriately while doing the 1-Wire bits for temperature retrieval.
This may leave us in the state were we have a message ready to go,
but the client isn't going to read it. If we see a USB reset, reset
our state and clear any indication that we have a message to go.
Add initial temperature reading via DS18B20 device
Actually plumb the 1-Wire support into the temperature query and
use an attached DS18B20 to retrieve the current temperature. This
*mostly* works with the existing TEMPer clients but there are
occasional USB issues, I think due to timing on the 1-Wire delays
affecting USB responses.
Add initial 1-Wire support and use it for the USB serial #
Introduce some basic bit-banging 1-Wire functions and use them to
detect if there is a 1-Wire device present and if so use its ROM ID
as the USB serial number.
This is a clone of the pcsensors.com TEMPerV1.2 device. At present
we just lie and claim 15°C rather than supporting a temperature
sensor. Tested with pcsensor-temper, temper-python + TEMPered.
Use existing OSCCAL as starting point for calibration
If we're being loaded from micronucleus it will have already
performed calibration on OSCCAL, so use that as the starting point
for our recalibration. This seems to improve things on an older Dell
host that previously had issues enumerating the device.
Move to micronucleus assembly for OSCCAL calibration
Some issues have been observed with OSCCAL calibration on older Dell
hosts. The micronucleus firmware enumerates correctly, but the Riso
clone then fails. Move to the assembly calibration code from
micronucleus to try and improve the situation.