jlorek

Where to call Nerves.UART.start_link?

Hi,

im using Nerves in a project where i do some UART communication to control an old plotter. Control over the plotter is provided via a Phoenix frontend.
My question is where to call start_link from Nerves.UART and initialize the communication.
Nerves.UART.start_link(name: Plotter)
Nerves.UART.open(Plotter, “ttyAMA0”, speed: 9600, active: false)
I get that UART is a GenServer, but i have no idea how to wrap this up in a module so that i can simply call it like this from my Phoenix controllers
Module.Write(“Plotter_Commands_Here”)
Is it valid to just use a name (Plotter) for start_link so i don’t have to store and use the pid for all subsequent calls?
I guess this is a more general Elixir question, but im really stuck on this.

Thanks!

4 comments

/nerves #uart #genserver

1 1924 4

2019-02-24 10:53:44 UTC

Marked As Solved

ConnorRigby

Nerves Core Team

I don’t know your exact requirements, but when working with Nerves.UART i usually do something along the following:

defmodule Plotter.UARTHandler do
   use GenServer

   alias Plotter.UARTHandler
   defstruct [:uart]

   def start_link(args, opts), do: GenServer.start_link(__MODULE__, args, opts)

   def interact_with_device(plotter, timeout), do: GenServer.call(plotter, {:interact, timeout}, timeout + 100)

   def init(_args) do
     {:ok, uart} = Nerves.UART.start_link()
     :ok = Nerves.UART.open(uart, "ttyAMA0", 9600, active: false)
     {:ok, struct(UARTHandler, uart: uart)}
   end

   def handle_call({:interact, timeout}, _from, state) do
     :ok = Nerves.UART.write(state.uart, "SOME FORMATTED BINARY")
     case Nerves.UART.read(state.uart, timeout) do
       {:ok, data} -> {:reply, {:ok, data}, state}
       {:error, reason} -> {:reply, {:error, reason}, state}
     end
   end
end

since it seems like you are using Phoenix, you will then likely want to do something like this in your application.ex file.

defmodule Plotter.Application do
  use Application

  # See https://hexdocs.pm/elixir/Application.html
  # for more information on OTP Applications
  def start(_type, _args) do
    import Supervisor.Spec

    # Define workers and child supervisors to be supervised
    children = [
      # Start the endpoint when the application starts
      supervisor(PlotterWeb.Endpoint, []),
      # Start your own worker by calling: Plotter.Worker.start_link(arg1, arg2, arg3)
      # worker(Plotter.Worker, [arg1, arg2, arg3]),
      {Plotter.UARTHandler, [[], name: GlobalHandler]}, # <- this is the important change.
    ]

    # See https://hexdocs.pm/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [strategy: :one_for_one, name: Plotter.Supervisor]
    Supervisor.start_link(children, opts)
  end

  # Tell Phoenix to update the endpoint configuration
  # whenever the application is updated.
  def config_change(changed, _new, removed) do
    PlotterWeb.Endpoint.config_change(changed, removed)
    :ok
  end
end

then you can make a controller like:

defmodule PlotterWeb.PlotterController do
  use PlotterWeb, :controller

  def plot(conn, _, ) do
    case Plotter.UARTHandler.interact_with_device(GlobalHandler, 2000) do
      {:ok, data} -> send_resp(conn, 200, data)
      {:error, reason} -> send_resp(conn, 501, "an error occured: #{inspect reason}")
    end
  end
end

Post #1

Also Liked

ConnorRigby

Nerves Core Team

This isn’t always true. In this case you don’t want it to be supervised by some other supervisor, since it is specific to the module handling it’s messages. Calling start_link should link the UART process to the calling process, which will cause the calling process to crash if it crashes. Because the GenServer wrapping the UART GenServer should be supervised, it will also be restarted essentially making it supervised.

For example you can just make a sample test worker:

defmodule UartTest.Worker do
  use GenServer

  def start_link(args) do
    GenServer.start_link(__MODULE__, args)
  end

  def init(_args) do
    IO.puts "Starting UART GenServer"
    {:ok, pid} = Circuits.UART.start_link()
    {:ok, %{pid: pid}}
  end
end

In observer you can see:

Now if you kill the Circuits.UART GenServer (<0.269.0>),
you will see that the UartTest.Worker is also killed, and restarted by UartTest.Supervisor.
You will see Starting UART GenServer again.

It works both ways. If you’d have killed the UartTest.Worker GenServer (<0.268.0>)
the Circuits.UART (<0.269.0>) would have been killed also.

Side note: I’ve been using Nerves.UART in production for a few years, and have never had the UART GenServer crash.

Post #3

Folo

Hi @ConnorRigby,

I’m still a little confused about where to call Nerves.UART.start_link() (or Circuits.UART.start_link() as it is now known).

I use Nerves.UART in active mode, this way I can receive a continuous stream of data from the serial port without polling. The way I’ve done this in the past is similar to your Plotter.UARTHandler example: wrapping the call to Nerves.UART.start_link() in the init() callback of a GenServer, then implementing the handle_info() callback to capture the resulting active mode messages.

However, every Nerves.UART process is a GenServer, and isn’t the proper thing with GenServers to start them as part of a Supervisor? Unfortunately, starting Nerves.UART in a Supervisor would cause all of the active mode messages to go to it.

What’s the right thing to do here?

It would be nice to be able to specify a pid that receives messages from a Nerves.UART process in active mode that was different from the pid that called Nerves.UART.start_link(). Or specify a callback for a Nerves.UART process to call when new data comes in, especially since sometimes the only reason I’m calling Nerves.UART.start_link() from the init() of a GenServer is to be able to catch messages in the GenServer’s handle_info() callback.

One solution might be to invoke Nerves.UART.start_link() in the init() of a module that implemented the Parent.Genserver behaviour from parent, by @sasajuric. That way, messages would be caught by the wrapping GenServer’s handle_info(), while Nerves.UART remained supervised.

Any suggestions would be much appreciated.

Post #2

Last Post!

Folo

Ah, that makes perfect sense. Thanks a lot for explaining.

It would be more useful to have a hybrid GenServer/Supervisor like in parent if one needed to combine supervising multiple GenServers with managing some state common to all of them/receiving messages from all of them.

Post #4