<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mjb/altos/src/drivers, branch master</title>
<subtitle>AltOS - the operating system for Altus Metrum products
</subtitle>
<id>https://git.ethernal.org/mjb/altos/atom?h=master</id>
<link rel='self' href='https://git.ethernal.org/mjb/altos/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/'/>
<updated>2019-08-13T00:30:48+00:00</updated>
<entry>
<title>altos: Use fast timer for buttons instead of edge-triggered ISR</title>
<updated>2019-08-13T00:30:48+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-08-13T00:30:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=fcb5d55e94058810fc8b31ad5e8caa99fa61200c'/>
<id>urn:sha1:fcb5d55e94058810fc8b31ad5e8caa99fa61200c</id>
<content type='text'>
If the button bounces between the triggering interrupt and the button
state check, we could lose the final state change of the button and
send an incorrect event to the application. In the worst case, the button
would end up in exactly the wrong state, toggling in the wrong direction.

Use the fast timer to poll all buttons instead so that there is only
one check of each button at each poll interval (instead of the
interrupt and the state check). This makes buttons reliably debounced.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: Record all failed sensors and report status at power up</title>
<updated>2019-07-16T18:12:49+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-07-16T18:12:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=8b2e457db8c4536440ecd7dc35d06f827fc008dc'/>
<id>urn:sha1:8b2e457db8c4536440ecd7dc35d06f827fc008dc</id>
<content type='text'>
Use DATA bits to mark which sensors have failed, then report that in
beeps at startup time to help diagnose hardware failures while still
allowing the board to be used over USB.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: Allow ms5607 driver to either set ao_sensor_errors or panic</title>
<updated>2019-07-15T20:26:30+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-07-15T20:26:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=245a49a85dd7b6a7cb9ec36ad02f6bb66e42f4e2'/>
<id>urn:sha1:245a49a85dd7b6a7cb9ec36ad02f6bb66e42f4e2</id>
<content type='text'>
Products that want to remain usable (over USB) after a sensor failure
don't want to panic when the ms5607 fails, but products with limited
ROM space don't want to have extra code to check for the sensor
failure and panic. Change the MS5607 driver to allow either option,
and then make the micropeak based devices use it.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: Don't dump MS5607 eeprom in 'B' command</title>
<updated>2019-06-19T06:14:54+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-06-19T06:14:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=835faccc2c1141f7cd8ff93629d583fcaf785e48'/>
<id>urn:sha1:835faccc2c1141f7cd8ff93629d583fcaf785e48</id>
<content type='text'>
MicroPeak v2 now has config stuff where these values get shown

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos/micropeak-v2.0: expose log and config commands over USB</title>
<updated>2019-06-18T21:50:53+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-06-18T21:50:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=ee7a54b3215ffa1eb38f16a151c0740b14b60857'/>
<id>urn:sha1:ee7a54b3215ffa1eb38f16a151c0740b14b60857</id>
<content type='text'>
This lets AltosUI handle the eeprom data

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: Support ao_ms5607_dump when no ms5607 task</title>
<updated>2019-06-18T06:43:02+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-06-18T06:43:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=ff7fa802f632700f73418246f1be5017ac0a09b4'/>
<id>urn:sha1:ff7fa802f632700f73418246f1be5017ac0a09b4</id>
<content type='text'>
MicroPeak v2.0 has tasking support, but doesn't have a separate ms5607
task. That means the device isn't getting initialized when not running
the flight code, so in cmd mode we need to make sure it's initialized,
and we also need to actually fetch a value to display.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: Add preliminary TeleStatic v3.0 code</title>
<updated>2019-04-22T01:30:43+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-04-22T01:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=0800970a4c9c6ed38bb76bfed6374093ca16b459'/>
<id>urn:sha1:0800970a4c9c6ed38bb76bfed6374093ca16b459</id>
<content type='text'>
This adds the pin definitions and all of the code except for the
ads131a04 driver.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: Change MAX6691 driver to run its own thread</title>
<updated>2019-04-22T01:18:55+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-04-22T01:18:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=83823e4ee901edb893db68e36deb2b92ffec3958'/>
<id>urn:sha1:83823e4ee901edb893db68e36deb2b92ffec3958</id>
<content type='text'>
This just captures temp data continuously; it takes 100ms to get the
temp data from the sensor, so the maximum rate is around 10 samples/sec.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: get ao_max6691 driver working</title>
<updated>2019-04-21T23:54:54+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-04-21T23:49:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=5d3436ed8551537287dc6cf418f93b0989e1aee8'/>
<id>urn:sha1:5d3436ed8551537287dc6cf418f93b0989e1aee8</id>
<content type='text'>
The driver uses a timer connected to a DMA engine to measure pulse
widths from the chip. We get 11 pulses for 4 channels; the first pulse
is caused by the timer starting up, the next two are the marker pulse
and then 8 more indicating the end of the high and low periods for
each channel.

The driver API returns the 8 pulse widths; the caller is expected to
know what to do with those values as using them requires knowing the
value of the configuration resistor and the characteristics of the
thermistors.

The test code assumes a 1k configuration resistor, using that it computes
the resistance of the four thermistors.

Signed-off-by: Keith Packard &lt;keithp@keithp.com&gt;
</content>
</entry>
<entry>
<title>altos: Work on MAX6691 driver</title>
<updated>2019-04-21T23:54:54+00:00</updated>
<author>
<name>Keith Packard</name>
<email>keithp@keithp.com</email>
</author>
<published>2019-04-12T06:54:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.ethernal.org/mjb/altos/commit/?id=49ce3e9a2eb4e1918773b80c355d720a3dadc7e0'/>
<id>urn:sha1:49ce3e9a2eb4e1918773b80c355d720a3dadc7e0</id>
<content type='text'>
</content>
</entry>
</feed>
