More than one interrupt event received

[ethrbh]

Hello,

I would like to use one of the Pi’s GPIO-27 as interrupt pin. For this I configured the GPIO as input, than I configured the interrupt condition of this. My test module is a pure gen_server, where I can handle the {gpio_interrupt, Pin, Condition} message in the handle_info/2.

Here is the interrupt circuit schematic. The Interrupt Pin connected to Ground by default when the switch is open. If the switch is closed the pin goes to 3.3VDC, what generates an interrupt.

                      |GPIO-27
Gnd---[RES=1kOhm]-----|--------------------/ (switch) --------3.3VDC

When an interrupt occurred, the event has arrived to my server process, but unfortunately there is not only one event comes, but many, and it looks the incoming events are never stopped. Once the Pi kernel stops the whole operation by killing the Erlang VM. I would like to ask you did I something wrong, or is this the “normal” behavior? Have you ever seen this behavior ?

The kernel on the Pi pi@raspberrypi ~/ethrbh/erlang-ale $ uname -a Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux pi@raspberrypi ~/ethrbh/erlang-ale $

Erlang version what I use pi@raspberrypi ~/ethrbh/erlang-ale $ erl Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1>

Here is the test module %% @author ethrbh %% @doc @todo Add description to gpio_int_test.

-module(gpio_int_test).
-behaviour(gen_server).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).

-define(SERVER, ?MODULE).
-define(INT_PIN, 27).

%% ====================================================================
%% API functions
%% ====================================================================
-export([start_link/0]).

start_link() ->
    gen_server:start_link({local, ?SERVER}, ?MODULE, [], []).

%% ====================================================================
%% Behavioural functions 
%% ====================================================================
-record(state, {}).

%% init/1
%% ====================================================================
%% @doc <a href="http://www.erlang.org/doc/man/gen_server.html#Module:init-1">gen_server:init/1</a>
-spec init(Args :: term()) -> Result when
    Result :: {ok, State}
            | {ok, State, Timeout}
            | {ok, State, hibernate}
            | {stop, Reason :: term()}
            | ignore,
    State :: term(),
    Timeout :: non_neg_integer() | infinity.
%% ====================================================================
init([]) ->
    {ok, _} = gpio:start_link({?INT_PIN, input}),
    ok = gpio:set_int(?INT_PIN, rising),
    {ok, #state{}}.

%% handle_call/3
%% ====================================================================
%% @doc <a href="http://www.erlang.org/doc/man/gen_server.html#Module:handle_call-3">gen_server:handle_call/3</a>
-spec handle_call(Request :: term(), From :: {pid(), Tag :: term()}, State :: term()) -> Result when
    Result :: {reply, Reply, NewState}
            | {reply, Reply, NewState, Timeout}
            | {reply, Reply, NewState, hibernate}
            | {noreply, NewState}
            | {noreply, NewState, Timeout}
            | {noreply, NewState, hibernate}
            | {stop, Reason, Reply, NewState}
            | {stop, Reason, NewState},
    Reply :: term(),
    NewState :: term(),
    Timeout :: non_neg_integer() | infinity,
    Reason :: term().
%% ====================================================================
handle_call(_Request, _From, State) ->
    Reply = ok,
    {reply, Reply, State}.

%% handle_cast/2
%% ====================================================================
%% @doc <a href="http://www.erlang.org/doc/man/gen_server.html#Module:handle_cast-2">gen_server:handle_cast/2</a>
-spec handle_cast(Request :: term(), State :: term()) -> Result when
    Result :: {noreply, NewState}
            | {noreply, NewState, Timeout}
            | {noreply, NewState, hibernate}
            | {stop, Reason :: term(), NewState},
    NewState :: term(),
    Timeout :: non_neg_integer() | infinity.
%% ====================================================================
handle_cast(_Msg, State) ->
    {noreply, State}.

%% handle_info/2
%% ====================================================================
%% @doc <a href="http://www.erlang.org/doc/man/gen_server.html#Module:handle_info-2">gen_server:handle_info/2</a>
-spec handle_info(Info :: timeout | term(), State :: term()) -> Result when
    Result :: {noreply, NewState}
            | {noreply, NewState, Timeout}
            | {noreply, NewState, hibernate}
            | {stop, Reason :: term(), NewState},
    NewState :: term(),
    Timeout :: non_neg_integer() | infinity.
%% ====================================================================
handle_info({gpio_interrupt, Pin, Condition},State) ->
    error_logger:info_report(["Interrupt occurred.", {gpio, Pin}, {interrupt_condition, Condition}]),
    {noreply, State};

handle_info(_Info, State) ->
    {noreply, State}.

%% terminate/2
%% ====================================================================
%% @doc <a href="http://www.erlang.org/doc/man/gen_server.html#Module:terminate-2">gen_server:terminate/2</a>
-spec terminate(Reason, State :: term()) -> Any :: term() when
    Reason :: normal
            | shutdown
            | {shutdown, term()}
            | term().
%% ====================================================================
terminate(_Reason, _State) ->
    ok.

%% code_change/3
%% ====================================================================
%% @doc <a href="http://www.erlang.org/doc/man/gen_server.html#Module:code_change-3">gen_server:code_change/3</a>
-spec code_change(OldVsn, State :: term(), Extra :: term()) -> Result when
    Result :: {ok, NewState :: term()} | {error, Reason :: term()},
    OldVsn :: Vsn | {down, Vsn},
    Vsn :: term().
%% ====================================================================
code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

%% ====================================================================
%% Internal functions
%% ====================================================================

Here is the log about the test run (ale@raspberrypi)3> gpio_int_test:start_link(). FullMsg={from_port,{port_reply,{<0.54.0>,#Ref<0.0.0.52>},ok}} {ok,<0.54.0>} (ale@raspberrypi)4> =INFO REPORT==== 20-Mar-2015::21:24:45 === "Interrupt occurred." gpio: 27 interrupt_condition: rising

(ale@raspberrypi)4> 
=INFO REPORT==== 20-Mar-2015::21:24:53 ===
    "Interrupt occurred."
    gpio: 27
    interrupt_condition: rising

=INFO REPORT==== 20-Mar-2015::21:24:53 ===
    "Interrupt occurred."
    gpio: 27
    interrupt_condition: rising

=INFO REPORT==== 20-Mar-2015::21:24:53 ===
    "Interrupt occurred."
    gpio: 27
    interrupt_condition: rising

=INFO REPORT==== 20-Mar-2015::21:24:53 ===
    "Interrupt occurred."
    gpio: 27
    interrupt_condition: rising

….

thanks for your help /Robi

[fhunleth]

Are you on a Raspberry Pi 2? I had noticed some flakiness with ALE and interrupts on the Raspberry Pi 1, and it might be worse with multiple cores. I ended up rewriting the GPIO code for https://github.com/fhunleth/elixir_ale and would be curious if that worked better. If it's easier, I have an old fork of Erlang/ALE at https://github.com/fhunleth/erlang_ale that has similar GPIO code updates, but I haven't maintained it in a long time. I was going to work on ALE issues next week at Erlang Factory, so if either fork fixes your issue, that would be good to know.

[ethrbh]

hello Frank,

Thanks for your reply. Yes, I have the Raspberry Pi B 1G RAM. It has 4 core CPU.

I tried my test code with your erlang-ale fork, but it did not helped. The same number of interrupt has received what I had with the original version. I also tried to start Erlang VM with "no smp", but it also did not helped. And let me ask you about your elixir_ale. I don't know much about it. I just looked the gpio.ex source file, and I realized that the naming is similar to Erlang gen_server (handle_call, handle_info, ect) Does it possible to use within Erlang/OTP? I'm interested that this has better behavior in interrupt point of view that erlang-ale.

thanks for your help, /Robi

[fhunleth]

It starting to sound like the issue is lower level than Erlang. I know this sounds stupid, but have you checked that the signal isn't really flaky with a logic analyzer. It seems hard to believe, but just in case. My next route would be to verify that Linux isn't doing anything funny. Hopefully someone lurking on this project can bring an RPI2 to Erlang Factory next week so I can try it out. If not, I'll be picking one up when they get in stock again.

[fhunleth]

Robi - I forgot to answer your question about elixir_ale. You noticed correctly, it is very similar to Erlang/ALE - almost to the API level. The only difference is that it's written in Elixir rather than Erlang, but that's pretty minor since they both run on the Erlang VM and use OTP. The right answer is for me to get many of the changes that I made in elixir_ale back in Erlang/ALE, and for there to be one code base. For a variety of reasons, but mostly due to time, I haven't gotten things in order to contribute back.

I have another suspicion on your issue and that's that semantics for the interrupt notification from the Linux subtly changed or the current code makes an incorrect assumption on how it's supposed to work and we got lucky. I promise to look into this more Friday or Saturday this week. Sorry I won't have time to do it sooner. Please post if you figure anything out in the mean time.

[ethrbh]

hello Frank,

Thanks for your answers. I also thought that this issue is not Erlang, but somehow may related to the Linux kernel behavior. I have made two type of test this interrupt. First I changed the condition from rising to falling, but of course it did not changed the behavior. Than I replaced the external button with an Pi's GPIO. I mean, I connected two GPIO to each other, and configured one as input, interrupt receiver, and configured the 2nd as output as interrupt source. Than I triggered the interrupt by setting the logical level to 1 or 0 of the 2nd GPIO depending what was set as interrupt condition of the 1st GPIO. The behavior is the same on all cases. When the interrupt condition has happened for example when the condition was set to rising, the logical level on the 2nd GPIO went from 0 to 1, and back to 0, the interrupt has received in the test app, but as I have mentioned before many-many messages has received as interrupt, and it never stopped. After a while the Linux has stopped the whole story by killing the Erlang VM.

Unfortunately I do not have logical analyzer, but the same "interrupt source with a button" was fine for My Microchip PIC MCU, and I think it should be fine for the Pi :-)

I try learn more about Elixir (http://elixir-lang.org/), and hope I can try out your code.

I also can say, if you will not have Pi HW, but you will have time, I can share my Pi, by giving an access to able to login from outside, and see whatever you want. Just let me know.

thanks for your, /Robi

[ethrbh]

hello Frank,

One more additional info. I tried reduce the number of cores to 1, just "simulate" a single core CPU. I used the following commands fro this: sudo sh -c "echo '1' > /sys/devices/system/cpu/cpu1/online" sudo sh -c "echo '1' > /sys/devices/system/cpu/cpu2/online" sudo sh -c "echo '1' > /sys/devices/system/cpu/cpu3/online"

Unfortunately during the execution of the first command, I completely lost the connection to Pi :-( Now I do re-image it. Btw, if you know other way how to turn off the cores for this purpose, let me know. Maybe we can get closer to understand what may cause this interrupt issue.

thanks for your help, /Robi

[knewter]

I am in the Erlang factory hotel with a pi2 right now just waiting for you to arrive Frank :D

[ghost]

:) I'll be there Wednesday afternoon.

[ethrbh]

hello,

I'm happy that you working on this issue. I hope you can give me some positive feedback soon.

thanks for your help, /Robi

[lehoff]

For what it is worth: I have seen double events coming in, but only in case of something actually happening or during initialisation. E.g., pressing a button can cause more than one interrupt. Almost always got a spurious interrupt with starting up a gen_server, but never a continued stream of them.

Cheers, Torben

Róbert Balogh writes:

Hello,

I would like to use one of the Pi’s GPIO-27 as interrupt pin. For this I configured the GPIO as input, than I configured the interrupt condition of this. My test module is a pure gen_server, where I can handle the {gpio_interrupt, Pin, Condition} message in the handle_info/2.

Here is the interrupt circuit schematic. The Interrupt Pin connected to Ground by default when the switch is open. If the switch is closed the pin goes to 3.3VDC, what generates an interrupt.

                    |GPIO-27

Gnd---[RES=1kOhm]-----|--------------------/ (switch) --------3.3VDC

When an interrupt occurred, the event has arrived to my server process, but unfortunately there is not only one event comes, but many, and it looks the incoming events are never stopped. Once the Pi kernel stops the whole operation by killing the Erlang VM. I would like to ask you did I something wrong, or is this the “normal” behavior? Have you ever seen this behavior ?

The kernel on the Pi pi@raspberrypi ~/ethrbh/erlang-ale $ uname -a Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux pi@raspberrypi ~/ethrbh/erlang-ale $

Erlang version what I use pi@raspberrypi ~/ethrbh/erlang-ale $ erl Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [kernel-poll:false]

Eshell V5.9.1 (abort with ^G) 1>

Here is the test module %% @author ethrbh %% @doc @todo Add description to gpio_int_test.

-module(gpio_int_test). -behaviour(gen_server). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]).

-define(SERVER, ?MODULE). -define(INT_PIN, 27).

%% ==================================================================== %% API functions %% ==================================================================== -export([start_link/0]).

start_link() -> gen_server:start_link({local, ?SERVER}, ?MODULE, [], []).

%% ==================================================================== %% Behavioural functions %% ==================================================================== -record(state, {}).

%% init/1 %% ==================================================================== %% @doc gen_server:init/1 -spec init(Args :: term()) -> Result when Result :: {ok, State} | {ok, State, Timeout} | {ok, State, hibernate} | {stop, Reason :: term()} | ignore, State :: term(), Timeout :: non_neginteger() | infinity. %% ==================================================================== init([]) -> {ok, } = gpio:start_link({?INT_PIN, input}), ok = gpio:set_int(?INT_PIN, rising), {ok, #state{}}.

%% handle_call/3 %% ==================================================================== %% @doc gen_server:handle_call/3 -spec handle_call(Request :: term(), From :: {pid(), Tag :: term()}, State :: term()) -> Result when Result :: {reply, Reply, NewState} | {reply, Reply, NewState, Timeout} | {reply, Reply, NewState, hibernate} | {noreply, NewState} | {noreply, NewState, Timeout} | {noreply, NewState, hibernate} | {stop, Reason, Reply, NewState} | {stop, Reason, NewState}, Reply :: term(), NewState :: term(), Timeout :: non_neg_integer() | infinity, Reason :: term(). %% ==================================================================== handle_call(_Request, _From, State) -> Reply = ok, {reply, Reply, State}.

%% handle_cast/2 %% ==================================================================== %% @doc gen_server:handle_cast/2 -spec handle_cast(Request :: term(), State :: term()) -> Result when Result :: {noreply, NewState} | {noreply, NewState, Timeout} | {noreply, NewState, hibernate} | {stop, Reason :: term(), NewState}, NewState :: term(), Timeout :: non_neg_integer() | infinity. %% ==================================================================== handle_cast(_Msg, State) -> {noreply, State}.

%% handle_info/2 %% ==================================================================== %% @doc gen_server:handle_info/2 -spec handle_info(Info :: timeout | term(), State :: term()) -> Result when Result :: {noreply, NewState} | {noreply, NewState, Timeout} | {noreply, NewState, hibernate} | {stop, Reason :: term(), NewState}, NewState :: term(), Timeout :: non_neg_integer() | infinity. %% ==================================================================== handle_info({gpio_interrupt, Pin, Condition},State) -> error_logger:info_report(["Interrupt occurred.", {gpio, Pin}, {interrupt_condition, Condition}]), {noreply, State};

handle_info(_Info, State) -> {noreply, State}.

%% terminate/2 %% ==================================================================== %% @doc gen_server:terminate/2 -spec terminate(Reason, State :: term()) -> Any :: term() when Reason :: normal | shutdown | {shutdown, term()} | term(). %% ==================================================================== terminate(_Reason, _State) -> ok.

%% code_change/3 %% ==================================================================== %% @doc gen_server:code_change/3 -spec code_change(OldVsn, State :: term(), Extra :: term()) -> Result when Result :: {ok, NewState :: term()} | {error, Reason :: term()}, OldVsn :: Vsn | {down, Vsn}, Vsn :: term(). %% ==================================================================== code_change(_OldVsn, State, _Extra) -> {ok, State}.

%% ==================================================================== %% Internal functions %% ====================================================================

Here is the log about the test run (ale@raspberrypi)3> gpio_int_test:start_link(). FullMsg={from_port,{port_reply,{<0.54.0>,#Ref<0.0.0.52>},ok}} {ok,<0.54.0>} (ale@raspberrypi)4> =INFO REPORT==== 20-Mar-2015::21:24:45 === "Interrupt occurred." gpio: 27 interrupt_condition: rising

(ale@raspberrypi)4> =INFO REPORT==== 20-Mar-2015::21:24:53 === "Interrupt occurred." gpio: 27 interrupt_condition: rising

=INFO REPORT==== 20-Mar-2015::21:24:53 === "Interrupt occurred." gpio: 27 interrupt_condition: rising

=INFO REPORT==== 20-Mar-2015::21:24:53 === "Interrupt occurred." gpio: 27 interrupt_condition: rising

=INFO REPORT==== 20-Mar-2015::21:24:53 === "Interrupt occurred." gpio: 27 interrupt_condition: rising

….

thanks for your help /Robi

---

Reply to this email directly or view it on GitHub: https://github.com/esl/erlang_ale/issues/18

Torben Hoffmann CTO, erlang-solutions.com T: +45 25 14 05 38

[ethrbh]

hej Torben,

Thanks for your email. I would like to ask you do you use the Pi2 HW with 4 cores CPU? I can confirm, that an "unexpected" interrupt has been received when the gen_server starting up, but lots of interrupt messages are coming when I generate an interrupt by pressing a button, or set High/Low another GPIO of Pi.

Had you have time to check my example code? Maybe I did something wrong when configure the GPIO for able to use for receiving interrupt.

thanks for your help, /Robi

[fhunleth]

Robi - I wanted to give you an update. I'm able to reproduce your issue on the Pi2. I've also verified that Elixir/ALE does not have this problem. I've made several changes to Elixir/ALE, but my suspicion is that changing the GPIO interrupt detection logic from being multithreaded in C to singlethreaded is the likely one.

[ethrbh]

hello Frank, Thanks for your update. I glad that you could reproduce my fault, this means that I did not do anything wrong. What do you think would it be good to start improve C code for handle the interrupts in a multithread environment, or just forget Erlang/ALE and try use Elixir/ALE instead? If you think that the 2nd option is the way forward, please try help me with some kind of directions how to use Elixir/ALE from my Erlang App.

thanks for your help, /Robi

[fhunleth]

I'd like to fix the Erlang/ALE code. I'll chat with Josh at Erlang Factory to strategize on how to pull in the Elixir/ALE C code.

[ethrbh]

hello Frank, That sounds good. If it is not a big problem, please let me know if you have some update. thanks for your grate support and help, /Robi

[fhunleth]

Hi Robi,

Could you try out the "ale2" branch in https://github.com/fhunleth/erlang_ale? I pulled my Elixir/ALE changes over, so I think that it should fix your problem. Note that the API has changed a bit, but I added example code to the README.md that should be helpful. I haven't updated the examples directory yet, though. Also, I'm using rebar3, but plain old rebar seems to still work.

[ethrbh]

hello Frank,

Thanks for your update. I have tried your changes, and the interrupt handling looks much-much better. Only one interrupt message has been received by my test process when the interrupt condition has been made. But I would like to have a question. I tried all interrupt conditions variant, and I do not see any different between the behaviors. So here is how I tested it. I used GPIO 27 as interrupt input pin and GPIO 22 as interrupt source. Set GPIO 22 to 1 means a rising edge, set to 0 means a falling edge. Both falling and raising edge generates interrupt with enabled, summerize and both interrupt conditions.

I would like to ask you, did I miss understand something, or did I something wrong? Or this is how it works, and my application should take care and handle which interrupt edge is what is "important" for me. Anyway, please find the logs about my test. I will follow to check I2C and SPI, and of course I will let you know if I see something wrong.

Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1>
1>
1> {ok,IntP}=gpio:start_link(27,input).
{ok,<0.69.0>}
2> {ok,BtnP}=gpio:start_link(22,output).
{ok,<0.71.0>}
3> gpio:register_int(IntP).
ok
4> gpio:set_int(IntP,summerize).
Notif={gpio_interrupt,27,falling}, [<0.67.0>]
ok
5> gpio:write(OutP,1).
* 1: variable 'OutP' is unbound
6> gpio:write(BtnP,1).
Notif={gpio_interrupt,27,rising}, [<0.67.0>]
ok
7> gpio:write(BtnP,0).
Notif={gpio_interrupt,27,falling}, [<0.67.0>]
ok
8>
8> gpio:write(BtnP,0).
ok
9> gpio:set_int(IntP,enabled).
ok
10>
10> gpio:write(BtnP,1).
Notif={gpio_interrupt,27,rising}, [<0.67.0>]
ok
11> gpio:write(BtnP,0).
Notif={gpio_interrupt,27,falling}, [<0.67.0>]
ok

Thanks for your help again. /Robi

[fhunleth]

It looks like it is working as expected. I disabled the rising and falling filters inside Erlang/ALE when I discovered that they didn't work right during fast transients. It didn't look like they ever did, for what it's worth, but it was a race condition. The Linux gpio sysfs documentation didn't help, so I punted for now. Please discard the events that you're not interested in for now. I'll get to it eventually.

[ethrbh]

hello Frank,

Thanks for your update. I think this is a not a big problem that you have filtered out the falling/rising filters, I can handle it within my application. I read what enabled/summerize/both/none conditions means in the gpio_port.c source, so I understand which means what, and this is fine for me. Last night I had no time to check I2C and SPI, but today I will do that.

Thanks for your grate support and help again. br, /Robi

[fhunleth]

Hi Robi,

Thanks for testing everything. I made so many changes that it is good to have independent verification. Also, I added the rising and falling filters back if you'd like to use them.

I'm planning on sending a pull request to get these changes back in the main Erlang/ALE repository. I've only done light testing on I2C and SPI, so I'd be curious if you run into trouble with them in your setup. If you don't get a chance to try them, that's ok. I'll just send the pull request anyway to get the process started.

Thanks, Frank

[ethrbh]

hello Frank,

Yesterday late night I had time to test I2C, not in robustness yet, but it was enough for beginning :-) It works as I expected. I'm almost finished with the implementation a "driver" for MCP23017, MCP23S17 IO expander devices and MCP7940n RTC device. On top of these modules I have implemented "hadler" process for supervise the I2C and SPI and GPIO processes what was started by eq: i2c:start_link/2. I registered a monitor (erlang:monitor/2) for the Pid produced when starting I2C, and my idea was to re-start the I2C with the same parameters what was introduced when it was started initially once the I2C process dies for same reason. The monitor can send a message {'DOWN', MonitorRef, Type, Object, Info} to the process from where monitor was raised ("the handler process"), but because the I2C process is started with start_link, the mother process dies too when the I2C dies. So the monitor could not works with this setup, thus I have made a small changes in the i2c.erl. I added start/2 function like this: -spec(start(devname(), addr()) -> {ok, pid()} | {error, reason}). start(Devname, Address) -> gen_server:start(?MODULE, {Devname, Address}, []).

With this, the monitor can re-start I2C automatically when it dies: (aws@raspberrypi)42> P=erlang:list_to_pid("<0.319.0>"). <0.319.0> (aws@raspberrypi)43> erlang:process_info(P). {current_function,{gen_server,loop,6}}, {initial_call,{proc_lib,init_p,5}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[#Port<0.1250>]}, {dictionary,[{'$ancestors',[i2c_handler,<0.315.0>]}, {'$initial_call',{i2c,init,1}}]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.31.0>}, {total_heap_size,377}, {heap_size,377}, {stack_size,9}, {reductions,58}, {garbage_collection,[{min_bin_vheap_size,46368}, {min_heap_size,233}, {fullsweep_after,65535}, {minor_gcs,0}]}, {suspending,[]}44> erlang:exit(P,kill).

=ERROR REPORT==== 4-Apr-2015::04:54:32 ===
    "I2C process has been died."
    monitorRef: #Ref<0.0.0.1132>
    type: process
    object: <0.319.0>
    info: killed
true
(aws@raspberrypi)45>
=INFO REPORT==== 4-Apr-2015::04:54:32 ===
    "I2C process has been re-registered"
    i2cDevieName: "i2c-1"
    i2cHwAddr: 32
    i2cPid: <0.327.0>

I would be very happy if you can make start function for I2C, SPI and gpio too, thus I do not need "hack" your source once I "git pull" for the latest.

Today I try continue to test SPI and make some kind of robustness test on both I2C and SPI.

And thanks that you have put back the falling and raising interrupt conditions, I will try out these.

Thanks for your help. /Robi

[knewter]

Robi,

If you know what you'd like to see, can you just send a pull request? That way everyone can benefit from your needs. I'd be glad to walk you through how to do it if you haven't before.

[fhunleth]

I just submitted a pull request for the mega-patch. Hopefully, we can iterate on improving it the normal way with much smaller pull requests. At least, that's my hope, and I'll help out too to make that happen.

[knewter]

And just as an update, the patch has now been merged and I've pushed v0.1.0 tag (older code is tagged v0.0.1)

On Sat, Apr 4, 2015 at 10:46 AM, Frank Hunleth notifications@github.com wrote:

I just submitted a pull request for the mega-patch. Hopefully, we can iterate on improving it the normal way with much smaller pull requests. At least, that's my hope, and I'll help out too to make that happen.

— Reply to this email directly or view it on GitHub https://github.com/esl/erlang_ale/issues/18#issuecomment-89602352.

Josh Adams CTO | isotope|eleven http://www.isotope11.com cell 215-3957 work 476-8671 x201

[mail] 3800 Colonnade Pkwy Suite 140 Birmingham, AL 35242

[ethrbh]

hello Josh and Frank,

Thanks for all your support and help. I try contribute to this grate project, but first I need move my project settings from erlang.mk to rebar3, because I could not able to use erlang_ale as dependency with erlang.mk. Once I will be ready with this moving, I will continue to "test" this new erlang_ale, and I also try finalize the "handlers" for I2C, SPI and GPIO and the drivers for the IO expander and RTC devices.

thanks again, /Robi

[fhunleth]

I know that a lot of people like erlang.mk. I don't use it, so I didn't added it. It was on my list of "nice-to-haves", though, so if you're familiar with it, feel free to add an erlang.mk Makefile. The previous one needed enough work that I punted for the mega-patch.

[fhunleth]

BTW, I can't do it, but I'm thinking that this specific issue is resolved. Would you mind moving the conversation to new issues?

[ethrbh]

hello Frank,

Yes, it is a good idea to try improve erlang_ale for support erlang.mk. I will try and if it works, I try add this changes to the project.

Sure, this "interrupt issue" looks solved, so you can close it, and we can open a new issue if there is.

thanks for your grate support again. br, /Robi

[ethrbh]

hello,

This issue is already fixed, so I think I will not do anything wrong if I close this ticket.

br, /Robi