1-wire buttons

[MaurinElectroTextile]

My project is to implement multiple 1-wire buttons for an user interface. I don't need a low latency system +-500 ms is ok. Each button act as a resistive sensor so I will need an ADC with a software threshold. Could you give me some guidance to configure/modify your code for that application ?

[smurfix]

On 24.06.2015 20:35, Maurin Donneaud wrote:

My project is to implement multiple 1-wire buttons for an user interface. I don't need a low latency system +-500 ms is ok. Each button act as a resistive sensor so I will need an ADC with a software threshold. Could you give me some guidance to configure/modify your code for that application ?

—

The easiest way would be to just use the ADC as it is, and set high/low thresholds as appropriate.

Let's assume ADC over 500 is "button touched", so you write adc.1 = 65535,500 (no low boundary). Then poll for alerts. alert/status says "adc", alert/adc says "1", you read adc.1 and get 550 (or whatever), so you know the button has been pressed. You now write adc.1 = 500,0 so that it'll tell you when the touch goes away.

If reading returns something <500 then the touch went away faster than your code managed to process it, you don't need to do anything else.

-- Matthias Urlichs

[stromnet]

I'm looking at something similar; a typical alarm dual-loop circuit, sensed using a simple voltage divider. A pullup on the CPU side, then a line to the switch with a parallel resistor (which is "removed" when switch is closed), and then through a End-of-line resistor, back to ground.

The switch output would have four states: Circuit broken/cut (5V, pullup fully active) SW Open (EOL + SW resistor in series) SW Closed (EOL resistor only) Circuit shorted (0V)

My first thoughts was to use a DS2408-like device and somehow convey 2bit sensed-values rather than 1bit. With MOAT it might be better/simpler to use something fully custom. Latch-style alarms ofcourse.

How and where would such a feature fit?

[smurfix]

On 25.06.2015 08:30, Johan Ström wrote:

I'm looking at something similar; a typical alarm dual-loop circuit, sensed using a simple voltage divider. A pullup on the CPU side, then a line to the switch with a parallel resistor (which is "removed" when switch is closed), and then through a End-of-line resistor, back to ground.

Workable. My first thoughts was to use a DS2408-like device and somehow convey 2bit sensed-values rather than 1bit. With MOAT it might be better/simpler to use something fully custom.

How and where would such a feature fit?

Basically, you can use the ADC as-is. Read current value, set new limits, use conditional search to get notified when the voltage crosses the upper or lower threshold, repeat.

-- Matthias Urlichs

[stromnet]

I've always thought in the lines of adding the detection logic in the AVR, and just return 0-4 depending on the level. But it could as well be done in the master using alarms. tweaking the limits would sure be easier!

However, a third threshold would be required, since I have 4 different levels I want to differentiate between. Looking at the code, it seems to be quite easy to just add another threshold. But one probably wants to make configurable number of thresholds instead. What do you think?

From my quick look, thresholds does not seem to be loaded from eeprom. Am I missing something or is this lacking?

[smurfix]

On 25.06.2015 21:58, Johan Ström wrote:

However, a third threshold would be required, since I have 4 different levels I want to differentiate between. Looking at the code, it seems to be quite easy to just add another threshold. But one probably wants to make configurable number of thresholds instead. What do you think? Umm, you're thinking about this the wrong way around. You read the current value, then send a new upper and lower boundary to the slave. If/when the ADC's value exceeds one of these, it'll trigger an alarm; to clear that, you'll have to send new bounds. (Reading the current value also clears the flags, but if the condition persists that won't help you.)

So obviously you can only have two boundary values.

From my quick look, thresholds does not seem to be loaded from eeprom. Am I missing something or is this lacking?

No, I don't load thresholds from the EEPROM; initially they are not set. There is an "I have just booted" alarm condition which you can use to trigger the master's setting up your device.

-- Matthias Urlichs

[stromnet]

Ah, that is of course the natural way to solve it :) Somewhat more work for the master though, and more load on the bus, but should be negligible for my scenario, which is door switches (i.e. won't switch with less than a few seconds interval, and not that often). Thanks!

[smurfix]

On 26.06.2015 08:16, Johan Ström wrote:

Ah, that is of course the natural way to solve it :) Somewhat more work for the master though, and more load on the bus, but should be negligible for my scenario, which is door switches (i.e. won't switch with less than a few seconds interval, and not that often). Thanks!

My tests say that 25 poll requests/seconds are no problem. Checking whether/which ADC triggered it (if necessary) and then reading that and updating the value should be doable in at most 0.2 seconds. That's tolerable for a light or door switch.

You could do it faster by eliminating (all, or part of) the CRC calculations. The time required to set up a new partial bus transfer on the master is what's killing the transmission speed. In fact I'll add an option for that sometime.

-- Matthias Urlichs

[stromnet]

That is absolutely acceptable speed, esp since it only happens when there actually is a condition. The ADC is running all the time, right? (No "Conversion" command required to trigger alarm, like the DS2450).

What are you referring to with "partial bus transfer"?

Out of curiosity, what do you use on the master end for polling for alarms, and how often? In my setup with my pyowmaster project I'm reading /uncached/alarm every 0.2s with good results. When my temp sensors are read there is a bit of delay, but using simultaneous conversion and prioritising alarm-polling before reading conversion results gives good results!

[smurfix]

On 26.06.2015 10:16, Johan Ström wrote:

That is absolutely acceptable speed, esp since it only happens when there actually is a condition. The ADC is running all the time, right? (No "Conversion" command required to trigger alarm, like the DS2450).

Right. It's running in the idle loop and polls every configured ADC input in turn.

What are you referring to with "partial bus transfer"?

Whenever the master needs to process results, or switch directions, bus transfer is paused because it needs to talk to the bus controller (USB, serial, I²C). That additional communication takes a lot of time.

Out of curiosity, what do you use on the master end for polling for alarms, and how often?

I'm using my own "moat" daemon via owserver; I've set it to one poll every 0.1sec.

-- Matthias Urlichs

[stromnet]

Ah, yes the interface<->owfs<->master-sw roundtrips takes a significant amount of time. Thanks!

[MaurinElectroTextile]

If I set up the world.cfg for an ATTiny85 do you think it compile ?

[smurfix]

On 02.07.2015 19:01, Maurin Donneaud wrote:

If I set up the world.cfg for an ATTiny85 do you think it compile ?

— Reply to this email directly or view it on GitHub https://github.com/M-o-a-T/owslave/issues/2#issuecomment-118093235.

I just checked in fixes so that it does compile. I do have a couple of tiny85 here so I might actually be able to test that if you run into problems.

NB, if you want PWM, you'll have to adapt timer.c to use timer 1.

-- Matthias Urlichs

[MaurinElectroTextile]

I had a compilation ERROR pgm_read_byte_near is not on my avr-gcc 4.8.2 I need to downgrade to 3.4.5

[smurfix]

Hi,

I have a compilation ERROR, sorry to put all it here :-(

Not a problem.

[chevrette@Chevrette]──[master] % sudo make test85

You shouldn't use "sudo make". There's no reason to.

mkdir device/test85 mkdir: impossible de créer le répertoire «device/test85»: Aucun fichier ou dossier de ce type

Fixed.

NB: please use "export LC_ALL=C" before submitting a bug, not everybody understands French.

avr-gcc -g -mmcu=attiny85 -Wall -Wstrict-prototypes -Os -mcall-prologues -fshort-enums -Idevice/test85 -c -o device/test85/moat.o moat.c moat.c: In function ‘moat_read’: moat.c:160:2: warning: implicit declaration of function ‘pgm_read_ptr_near’ [-Wimplicit-function-declaration]

This works on my system. Which version of avr-gcc and friends are you using?

-- Matthias Urlichs

[MaurinElectroTextile]

% avr-gcc --version
% avr-gcc (GCC) 4.8.2

[smurfix]

Hmm. Looks like an incompatible change.

I have pushed a new version without the _near. Please test.

-- Matthias Urlichs

[MaurinElectroTextile]

ERROR is now : moat.c:160: undefined reference to `pgm_read_ptr'

[smurfix]

On 04.07.2015 14:08, Maurin Donneaud wrote:

ERROR is now : moat.c:160: undefined reference to `pgm_read_ptr'

Sigh.

I don't know what else to tell you. All of these files include <avr/pgmspace.h> where this is supposed to be defined.

Please send me your device/*/dev_config.h file and /usr/lib/avr/include/avr/pgmspace.h

Also, run "avr-gcc -g -mmcu=attiny85 -Idevice/test85 -E -dD moat.c > /tmp/moat.c.cpp" and send that file.

Please use attachments, don't include or copy+paste into your email text. Thanks.

-- Matthias Urlichs

[smurfix]

Looks like a toolchain issue. Closing for now.