<a id='Package-Development-1'></a>

# Package Development


<a id='Host-computer-development-environment-1'></a>

## Host computer development environment


If you want to develop the code in LabConnections.jl, then this is how you setup a development environment. First, open up a Julia REPL and type


```
] dev https://gitlab.control.lth.se/labdev/LabConnections.jl
```


Open a new terminal and navigate to `.julia/dev/LabConnections`, where the package source code is now located. Then type


```
git checkout julia1
git pull
```


to ensure that you are working on the correct development branch for Julia v1.0.X. You can now edit the code in `.julia/dev/LabConnections` and run it using a Julia REPL. When you are satisfied with your changes, simply commit and push the changes in the `.julia/dev/LabConnections` directory to the GitLab server.


<a id='Development-with-the-BeagleBone-1'></a>

## Development with the BeagleBone


<a id='Transferring-development-code-from-host-to-the-BeagleBone-1'></a>

### Transferring development code from host to the BeagleBone


Because of the limited performance of the BeagleBone (BB), it is often preferable to do most code development on the host computer. However, you will also do testing of the code locally on the BB, and will thus need to transfer the latest code from the host computer to the BB. To do this, there is a handy utility shell script found in `/util` that handles this. Open a terminal on the host computer and type


```
cd ~/.julia/dev/LabConnections/util
./copyfoldertobb.sh
```


This will transfer the current development version of `LabConnections.jl` found in the `/dev` directory to the BB.


<a id='Development-with-hardware-in-the-loop-1'></a>

### Development with hardware in the loop


When testing `LabConnections.jl` with hardware in the loop, the external hardware will be connected to the pin headers on the BB. For reference, the pin map of the BeagleBone (BB) is shown below.


<p align="center"> <img src="../fig/beaglebone*black*pinmap.png" height="500" width="900"> </p>


When running examples and tests with hardware in the loop, take caution not to short the BB ground with any output pin, as this will damage the board. For instance, if connecting a diode to the output pins, always use a resistor of >1 kOhm in parallel.


<a id='Notes-on-updates-with-the-v.4.14-kernel-1'></a>

## Notes on updates with the >=v.4.14 kernel


At the time of writing, the image used to flash the beaglebone is a v4.14 kernel, more specifically Linux beaglebone 4.14.71-ti-r80.


Since the deployment of the v4.14 kernel, the slots file and bone_capemgr have been permanantly disabled. This means that there is no need for compiling the device tree overlays as we did for the v0.6 version of the software stack. Instead, we need to configure the /boot/uEnv.txt file to enable the PWM pins correctly. Simply open the `/boot/uEnv.txt` file, add the line


```
cape_enable=bone_capemgr.enable_partno=univ-all,BB-ADC,BB-PWM0,BB-PWM1,BB-PWM2
```


and uncomment the line


```
disable_uboot_overlay_video=1
```


Reboot the BeagleBone, and you should now have access to the PWM pins.


<a id='Changes-to-the-device-maps-1'></a>

### Changes to the device maps


The filesystem has also changed with 4.14. we now have a pwm device in `/sys/class/pwm` where we can export and then write to the PWM pins of of the BBB. However, in order to do this, we first need to idetify which pwm chip that corresponds to which pin.


The address of each PWM interface is


```
> ls -lh /sys/class/pwm

lrwxrwxrwx 1 root pwm 0 Oct  7 16:40 pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip0
lrwxrwxrwx 1 root pwm 0 Oct  7 16:40 pwmchip1 -> ../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip1
lrwxrwxrwx 1 root pwm 0 Oct  7 16:40 pwmchip3 -> ../../devices/platform/ocp/48302000.epwmss/48302100.ecap/pwm/pwmchip3
lrwxrwxrwx 1 root pwm 0 Oct  7 16:40 pwmchip4 -> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip4
lrwxrwxrwx 1 root pwm 0 Oct  7 16:40 pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip6
lrwxrwxrwx 1 root pwm 0 Oct  7 16:40 pwmchip7 -> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip7
```


Page 184 of the TI AM335x and AMIC110 Sitara Processors Technical Reference Manual gives the memory map for the PWM chips


```
    PWM Subsystem 0: 0x48300000
        eCAP0: 0x48300100
        ePWM0: 0x48300200
    PWM Subsystem 1: 0x48302000
        eCAP1: 0x48302100
        ePWM1: 0x48302200
    PWM Subsystem 2: 0x48304000
        eCAP2: 0x48304100
        ePWM2: 0x48304200
```


From this we can conclude that


```
ECAP0   (eCAP0) is pwmchip0
EHRPWM0 (ePWM0) is pwmchip1
eCAP1   (eCAP1) is pwmchip3
EHRPWM1 (ePWM1) is pwmchip4
eCAP2   (eCAP2) is pwmchip6
EHRPWM2 (ePWM2) is pwmchip7
```


Based on the headers on the BeagleBone expansion cape


```
EHRPWM0A = P9_22
EHRPWM0B = P9_21
EHRPWM1A = P9_14
EHRPWM1B = P9_16
EHRPWM2A = P8_19
EHRPWM2B = P8_13
ECAP0    = P9_42
```


which means that we get a mapping


```
const pwm_pins = Dict(
    "P9.22" => ("PWM0A", "pwmchip1", "0"),
    "P9.21" => ("PWM0B", "pwmchip1", "1"),
    "P9.14" => ("PWM1A", "pwmchip4", "0"),
    "P9.16" => ("PWM1B", "pwmchip4", "1"),
    "P8.19" => ("PWM2A", "pwmchip7", "0"),
    "P8.13" => ("PWM2B", "pwmchip7", "1"),
)
```


note that before the v4.14 kernel, this mapping was


```
const pwm_pins = Dict(
    "P9.22" => ("PWM0A", "pwmchip0", "0"),
    "P9.21" => ("PWM0B", "pwmchip0", "1"),
    "P9.14" => ("PWM1A", "pwmchip2", "0"),
    "P9.16" => ("PWM1B", "pwmchip2", "1"),
    "P8.19" => ("PWM2A", "pwmchip4", "0"),
    "P8.13" => ("PWM2B", "pwmchip4", "1"),
)
```


<a id='Changes-to-the-file-system-1'></a>

### Changes to the file system


Before the v4.14 kernel, the file system was structured in such a way that, after export, P9.22 could be enabled by writing to the file 


```
/sys/class/pwm/pwmchip0/pwm0/enable
```


however, in the new kernel


```
/sys/class/pwm/pwmchip1/pwm-1:0/enable
```


is used to enable the PWM on the P9.22 pin.


<a id='Testing-the-PWM-pins-individually-1'></a>

### Testing the PWM pins individually


In order to test the PWM pins from the terminal, make sure that you have added the lines in the /boot/uEnv.txt file, and then configure the desired pin to a PWM pin. For instance, if we wish to control the P9.22 pin, run


```
config-pin P9.22 pwm
```


and make sure that it is configured correctly by running


```
config-pin -q P9.22
```


which should return "P9_22 Mode: pwm". Now you first need to export the correct pin, which, according the the device mapping above, can be done by


```
echo 0 > /sys/class/pwm/pwmchip1/export
```


once this is done, we set a period and duty cycle to the pin


```
echo 1000000000 > /sys/class/pwm/pwmchip1/pwm-1\:0/period
echo 800000000 > /sys/class/pwm/pwmchip1/pwm-1\:0/duty_cycle
```


and enable it through


```
echo 1 > /sys/class/pwm/pwmchip1/pwm-1\:0/enable
```


disable and unexport the PWM pin by


```
echo 0 > /sys/class/pwm/pwmchip1/pwm-1\:0/enable
echo 0 > /sys/class/pwm/pwmchip1/unexport
```


Alternatively, this can be done using the Julia, by writing


```
p = PWM(1)
write!(p, (1, "1"))
write!(p, (2, "1000000000"))
write!(p, (3, "800000000"))
```