Markdown source

#How to timely turn on the WiFi interface on the CM3-HOME

<abstract>
The CM3-HOME is equipped with the well known Acmesystems USB Wi-Fi (IEEE 802.11b).
However such interface is not powered on by default.
A suitable systemd script is proposed here.
</abstract>

This is the CM3-HOME schematic for what concerns WiFi interface:

<img src="./cm3-home-wifi.PNG">

as can be easily seen, the WiFi interface (GWF-3M-08) is powered only if the Q17 is turned on, 
bringing the WiFi module GND ping to ground.

In order to do that, the WiFi_ON signal has to be put at high logical level;
the script below is useful just for that purpose:

	/bin/echo 37  > /sys/class/gpio/export ; 
	/bin/echo out > /sys/class/gpio/gpio37/direction ; 
	/bin/echo 1   > /sys/class/gpio/gpio37/value
	
Now, we need to configure the systm to execute that three lines on each boot.	

The first idea in order to activate at boot the WiFi could be to use  __/etc/rc.local__ where,  in the past, all the applications 
that implemented the system functionalities were started.  

So, __rc.local__ could be setup as the following:

	cat /etc/rc.local
	
	#!/bin/sh -e
	#
	# rc.local
	#
	# This script is executed at the end of each multiuser runlevel.
	# Make sure that the script will "exit 0" on success or any other
	# value on error.
	#
	# In order to enable or disable this script just change the execution
	# bits.
	#
	# By default this script does nothing.
	
	/bin/echo 37  > /sys/class/gpio/export ; 
	/bin/echo out > /sys/class/gpio/gpio37/direction ; 
	/bin/echo 1   > /sys/class/gpio/gpio37/value
	
	exit 0

In this example a three rows script is executed that create access to GPIO pin #37 and outputs on it a logical one, that, turning on the fet Q17, brings the WiFI_Ground
to system ground, finally turning on the WiFi interface.
However it happens that, as the rc.local is the __last_ script executed at boot, the networking services 
(started well before) are finding no WiFi interface at all as it is still turned off.

What we need is a way to force the systemd to execute our script __before__ the network services are started avoiding
to incur into the previously described pitfall, that network services are failing just because the WiFi physical interface has not yet powered.

With systemd a different and more integrated approach is feasible. Instead of adding something to a shell script, 
a proper service file can be created and added to the systemd.


Let's create a service file for the power on script. Create as root
a file called __poweronwifi.service__ in __/lib/systemd/system__ directory.

	sudo nano /lib/systemd/system/poweronwifi.service
	
then save inside it the following lines:	

	[Unit]
	Description=Poweron WiFi
	Before=network-pre.target
	Wants=network-pre.target
	
	[Service]
	ExecStart=/bin/bash -c '/bin/echo 37 > /sys/class/gpio/export ; /bin/echo out > /sys/class/gpio/gpio37/direction ; /bin/echo 1 > /sys/class/gpio/gpio37/value'
	
	[Install]
	WantedBy=multi-user.target

Next systemd has to be configured, enabling the service so at the next reboot it will be started automatically.
First off, though, the systemd itself has to be reloaded in order to detect the new service definition:

	sudo systemctl daemon-reload

Next, the new service is enabled

	sudo systemctl enable poweronwifi.service

Check if it is really enabled:

	sudo systemctl list-unit-files | grep enabled

Of course, it can be started manually just now:

	sudo systemctl start poweronwifi.service


##How to see full log from systemctl status service ?

Use the journalctl command, as in:

	journalctl -u poweronwifi.service

nothing should be there as far the procedure is succeffully executed.
## Links

* [Understanding Systemd Units and Unit Files](https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files)
* [Systems tutorial on Linux Magazine](http://www.linux-magazine.com/Issues/2017/200/Tutorials-Systemd)


@include='bio_andrea_montefusco'



Le attività del TanzoLab si svolgono ogni mercoledi sera, salvo casi speciali, dalle ore 18:30 presso i locali della Acme Systems srl e consistono in:

  • Talk monotematici a cura di professionisti in vari settori tecnologici
  • Workshop pratici su elettronica embedded, produzione e informatica
  • Progettazione e realizzazione di nuovi prodotti embedded per l'IT

Le attività vengono coordinate tramite questo sito, in cui vengono pubblicati tutti i lavori svolti o in via di sviluppo, e tramite un gruppo Telegram con cui per interagire direttamente via chat con gli altri membri.