Tag Archives: Linux

Basilisk II Emulator Floating Point Bug

Basilisk II Emulator Floating Point Bug

I’m not sure if it is just my specific installation, but I’ve noticed an issue in Basilisk II regarding floating point values, where the value displayed is incorrect. This has caused me problems a few times, but this evening, I worked out a partial solution.

The issue seems to be in the FPU emulation itself. I use a IIci ROM in my installation. I found that if I set the CPU to either a full 68040 or a 68030 + FPU, floating point values were wildly wrong. I then found that the vanilla “SANE” routines work, so if you set the emulator to 68030 (without an FPU) everything works just fine.

This will slightly reduce software compatibility (although I doubt software that required the FPU would function correctly with the completely incorrect values I was getting), but will mean that software that doesn’t require a hardware FPU will run correctly.

Update – dougg3 has noticed that the issue happens when he uses the IIci ROM, but not if he uses a later (LC 630) ROM.

I have made a small testing tool, which is available for download here :

https://github.com/Phipli/FPUCheckhttps://github.com/Phipli/FPUCheck

USB Relay Boards

FTDI USB Relay Board

A while back I wrote a post about using an FTDI breakout board as a GPIO board from Python. Since then, I have discovered that there are USB relay boards based on this concept available from China. SainSmart seem to sell them, but they are available on ebay, Banggood and Aliexpress. The boards are interesting as they do not contain a microcontroller – just an FTDI chip and an ULN2803 array of Darlington pairs to drive the relay coils.

Relay Board
SainSmart 8 Channel USB Relay Board

Using the setup previously detailed in my other post, it is possible to control one of these boards from Linux. The process is exactly the same as using one of the little red USB UART adapter boards.

To use one of these boards from Linux :

  1. Follow the process to set up your computer as per my old post.
  2. Plug the board into a 12v DC supply, and your computer’s USB.
  3. Run the following example (as root / with sudo if you haven’t set up permissions for your user to access the device).
#!/usr/bin/env python

import os
import sys
import ftdi1 as ftdi
import time

ftdic = ftdi.new()
if ftdic ==0:
	print( 'new failed: %d', ret )
	os._exit( 1 )

# try to list ftdi devices 0x6010 or 0x6001
ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6010 )
if ret <= 0:
    ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6001)

if ret < 0:
    print( 'ftdi_usb_find_all failed: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
    os._exit( 1 )
print( 'Number of FTDI devices found: %d\n' % ret )
curnode = devlist
i = 0
while( curnode != None ):
    ret, manufacturer, description, serial = ftdi.usb_get_strings( ftdic, curnode.dev )
    if ret < 0:
        print( 'ftdi_usb_get_strings failed: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
        os._exit( 1 )
    print( 'Device #%d: manufacturer="%s" description="%s" serial="%s"\n' % ( i, manufacturer, description, serial ) )
    curnode = curnode.next
    i += 1

# open usb
ret = ftdi.usb_open( ftdic, 0x0403, 0x6001 )
if ret < 0:
    print( 'unable to open ftdi device: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
    os._exit( 1 )


# bitbang
ret = ftdi.set_bitmode( ftdic, 0xff, ftdi.BITMODE_BITBANG )
if ret < 0:
    print( 'Cannot enable bitbang' )
    os._exit( 1 )

for i in range( 8 ):
    val = 2**i
    #print( 'enabling bit #%d (0x%02x)' % (i, val) )
    ftdi.write_data( ftdic, chr(val), 1 )
    time.sleep ( 0.5 )

ftdi.write_data( ftdic, chr(0x00), 1)
time.sleep ( 0.2 )

ftdi.disable_bitbang( ftdic )
print( '' )



# close usb
ret = ftdi.usb_close( ftdic )
if ret < 0:
    print( 'unable to close ftdi device: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
    os._exit( 1 )

print ('device closed')
ftdi.free( ftdic )

This code is lightly modified from the code found here, without which I’d have struggled.

HID USB Relay Board

Similar boards exist which use an Atmel microcontroller interfacing with the computer through a software HID implementation. These boards are cheaper, but otherwise similar on the relay side and in appearance.

Red USB Relay Board
Red USB Relay Board

These boards can be controlled from Linux by installing the “usbrelay” program from the repository (on Ubuntu and Debian at least) using “sudo apt-get install usbrelay”. Otherwise the developer has a github page for the project here : https://github.com/darrylb123/usbrelay. Once installed and with the device connected, simply typing “sudo usbrelay” (without quote marks) at your command line reports back on connected devices. One of my devices calls itself “VXCMF”, while another calls itself “6QMBS”. Where a device is called “VXCMF”, the first two relays can be turned on with the following command “sudo usbrelay VXCMF_1=1 VXCMF_2=1” and off again with “sudo usbrelay VXCMF_1=0 VXCMF_2=0”.

If you want to use the boards without sudo, you’ll have to add it to /etc/udev/rules.d. There are detailed instructions on the github linked above, but in short, if you’re using a Debian family OS, put the following in a file called “50-usbrelay.rules” in the folder /etc/udev/rules.d :

SUBSYSTEM=="usb", ATTR{idVendor}=="16c0",ATTR{idProduct}=="05df", MODE="0666"
KERNEL=="hidraw*",  ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", MODE="0660", GROUP="plugdev", TAG+="systemd" ENV{SYSTEMD_WANTS}="usbrelayd.service"
KERNEL=="hidraw*",  ATTRS{idVendor}=="0519", ATTRS{idProduct}=="2018", MODE="0660", GROUP="plugdev", SYMLINK+="usbrelay%b"

SUBSYSTEM=="usb", ATTR{idVendor}=="5131",ATTR{idProduct}=="2007", MODE="0666"
KERNEL=="hidraw*",  ATTRS{idVendor}=="5131", ATTRS{idProduct}=="2007", MODE="0660", GROUP="plugdev", SYMLINK+="usbrelay%b"

Then make sure your user is in the plugdev group and restart. If you’re using Windows or macOS, there are other instructions in forks such as this one https://github.com/corerd/usbrelay, although it looks a little old.

Both boards detailed in this post are available with various numbers of relays. The red boards are probably easier to use as it is simply a case of installing usbrelay. Hopefully the instructions here and in my previous post can help people get their boards running. I haven’t tested, but both should work fine with a Raspberry Pi and many other SBCs.

Good luck!

AVRprog2 Config Settings

AVRprog2 Config Settings

As I add config files for different AVRs to my AVRprog2 setup, I intend to detail them here. Please see my other post here, for how to set AVRprog2 up on Linux and get it working with the Arduino IDE.

These files should be saved as text files in the style of (for the ATmega16) “atmega16.xml”, and placed in the folder “/usr/local/share/avrprog2/”. Super user permissions are required.

Additional Configuration Files :

The following are non-standard implementations – note they may contain errors.

ATmega32 :

<device>
	<name>ATmega 32</name>
	<signature>0x1e9502</signature>
	<flashSize>32768</flashSize>
	<flashPageSize>128</flashPageSize>
	<eepromSize>1024</eepromSize>
	<numOfFuses>2</numOfFuses>
</device>

ATmega162 :

<device>
	<name>ATmega 162</name>
	<signature>0x1e9404</signature>
	<flashSize>16384</flashSize>
	<flashPageSize>128</flashPageSize>
	<eepromSize>512</eepromSize>
	<numOfFuses>3</numOfFuses>
</device>

ATmega328P :

<device>
	<name>ATmega 32</name>
	<signature>0x1e950F</signature>
	<flashSize>32768</flashSize>
	<flashPageSize>128</flashPageSize>
	<eepromSize>1024</eepromSize>
	<numOfFuses>3</numOfFuses>
</device>

Standard Configuration Files :

ATmega16 :

<device>
	<name>ATmega 16</name>
	<signature>0x1e9403</signature>
	<flashSize>16384</flashSize>
	<flashPageSize>128</flashPageSize>
	<eepromSize>512</eepromSize>
	<numOfFuses>2</numOfFuses>
</device>

ATmega128 :

<device>
	<name>ATmega 128</name>
	<signature>0x1e9702</signature>
	<flashSize>131072</flashSize>
	<flashPageSize>256</flashPageSize>
	<eepromSize>4096</eepromSize>
	<numOfFuses>3</numOfFuses>
<!--<socket>TQFP64</socket>	use autodetection-->
</device>

ATmega1280 :

<device>
	<name>ATmega 1280</name>
	<signature>0x1e9703</signature>
	<flashSize>131072</flashSize>
	<flashPageSize>256</flashPageSize>
	<eepromSize>4096</eepromSize>
	<numOfFuses>3</numOfFuses>
<!--<socket>TQFP100</socket>	use autodetection -->
</device>

ATmega2560 :

<device>
	<name>ATmega 2560</name>
	<signature>0x1e9801</signature>
	<flashSize>262144</flashSize>
	<flashPageSize>256</flashPageSize>
	<eepromSize>4096</eepromSize>
	<numOfFuses>3</numOfFuses>
<!--<socket>auto</socket>	use autodetection -->
</device>

 

GPIO Using a Cheap FTDI Board

During a discussion with my dad about doing GPIO style projects from a regular, full fat computer,  I was telling him about the Adafruit FT232H Breakout board. These boards allow you to use several different serial protocols such as SPI, I2C and UART as well as provide a GPIO mode if you are willing to get involved enough. It provides an elegant solution to connecting external electronic devices, because it doesn’t require any software to be loaded into the device itself – all your code is running on your computer. The one downside is that, here in the UK at least, these boards cost in the region of £15, meaning that personally I would usually just grab a cheap Arduino and write some kind of pass-through program for most things I’d want to do.

AdafruitFT232H
Adafruit FT232H Breakout

Yesterday evening, I installed the various software identified in Adafruit’s “Learning System” page relating to the product to allow me to set up various pins as inputs and outputs from a python program, in a similar style to how you might use the GPIO pins on a Raspberry Pi. Looking at what I needed to install and the fact that you had to specifically tell some of the libraries what chip you were connecting got me thinking that perhaps some of the software tools would work more generally with FTDI chips. I knew it was possible to use FTDI chips such as the FT232RL (commonly used in USB to UART serial adapters) as external USB connected GPIO, but my previous investigations hadn’t found clear (and simple enough) instructions to get anywhere in the time I had available. Today I dug out a cheap FT232RL based board and decided to have a play. At £1.38 each, these boards don’t exactly break the bank, and I have a pile of them already. I also like that you can easily switch the voltage using the jumper on these boards.

FT232RL
FT232RL USB to Serial Board

The following instructions relate specifically to Linux (Ubuntu 17.10), but following the instructions given on the Adafruit website may get you up and running on Windows or MacOS. Hardware-wise, any sensible computer with USB, a USB cable (Type A to Mini-B), a breadboard, a run-of-the-mill LED, an appropriate current limiting resistor (I used a 560 Ω resistor, which should be fine in most cases) and a FT232RL based board similar to the one above. The circuit is as follows (note the +ve side of the LED is identified by the longer lead, and the -ve by a flat on the side of the lens) :

FT232RL Circuit
FT232RL Circuit

Following the Adafruit instructions for Linux, carefully enter the following commands in a terminal :

sudo apt-get update
sudo apt-get install build-essential libusb-1.0-0-dev swig cmake python-dev libconfuse-dev libboost-all-dev
wget http://www.intra2net.com/en/developer/libftdi/download/libftdi1-1.2.tar.bz2
tar xvf libftdi1-1.2.tar.bz2
cd libftdi1-1.2
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX="/usr/" -DPYTHON_INCLUDE_DIR="/usr/include/python2.7" -DPYTHON_LIBRARIES="/usr/lib/python2.7/" ../
make
sudo make install

This installs the dependencies, fetches the source code for libftdi1, compiles it and finally installs it.

To test that everything installed correctly, launch the python interpreter by typing “python” (excluding quotes) at the command line and pressing enter, then type “import ftdi1” and press enter. If there are no errors, then it installed just fine. Exit the interpreter by typing “exit()” and pressing enter.

Now would probably be a good time to return to your home directory and perhaps create a folder for your python project. We’ll then create a new file called LEDBlink.py and open it in nano (a text editor) :

cd ~
mkdir ftdiGPIO
cd ./ftdiGPIO/
nano ./LEDBlink.py

Once you have the empty file open in the window, enter the following python program (which is based on the code found here). Note you can copy and paste from here – but use the copy button in the top right of the code container to ensure consistent formatting :

#!/usr/bin/env python

import ftdi1 as ftdi
import time

ftdic = ftdi.new()

# try to list ftdi devices 0x6010 or 0x6001
ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6010 )
if ret <= 0:
    ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6001)

# open usb
ret = ftdi.usb_open( ftdic, 0x0403, 0x6001 )

# bitbang
ret = ftdi.set_bitmode( ftdic, 0xff, ftdi.BITMODE_BITBANG )

for i in range( 64 ):
    ftdi.write_data( ftdic, chr(0x02), 1)
    time.sleep ( 0.5 )
    ftdi.write_data( ftdic, chr(0x00), 1)
    time.sleep ( 0.2 )

ftdi.disable_bitbang( ftdic )

# close usb
ret = ftdi.usb_close( ftdic )
print ('device closed')
ftdi.free( ftdic )

This is a basic program with no error checking – it assumes that a device of the correct type is connected an available. Note that it will probably need to be run as root to access the hardware. The program finds and connects to the FT232RL (assuming it is plugged in), then blinks the LED 64 times, being on for 0.5 seconds and off for 0.2 seconds each time. Once the code is entered, press ctrl-x, then “y” and finally enter to exit and save. Check that everything is wired up as follows :

FT232RL Circuit Breadboard
FT232RL Circuit Breadboard

If everything is OK, plug the USB into the computer and enter the following commands :

chmod +x ./LEDBlink.py
sudo ./LEDBlink.py

The first command sets permissions to allow the python program to be executed, the second executes it. If all goes well you’ll be asked for your password and then the LED will start blinking.

If it doesn’t, then… erm… well it worked on my machine…

The following code does the same thing, but includes error checking. A lot of it!

#!/usr/bin/env python

import os
import sys
import ftdi1 as ftdi
import time

ftdic = ftdi.new()
if ftdic ==0:
	print( 'new failed: %d', ret )
	os._exit( 1 )

# try to list ftdi devices 0x6010 or 0x6001
ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6010 )
if ret <= 0:
    ret, devlist = ftdi.usb_find_all( ftdic, 0x0403, 0x6001)

if ret < 0:
    print( 'ftdi_usb_find_all failed: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
    os._exit( 1 )
print( 'Number of FTDI devices found: %d\n' % ret )
curnode = devlist
i = 0
while( curnode != None ):
    ret, manufacturer, description, serial = ftdi.usb_get_strings( ftdic, curnode.dev )
    if ret < 0:
        print( 'ftdi_usb_get_strings failed: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
        os._exit( 1 )
    print( 'Device #%d: manufacturer="%s" description="%s" serial="%s"\n' % ( i, manufacturer, description, serial ) )
    curnode = curnode.next
    i += 1

# open usb
ret = ftdi.usb_open( ftdic, 0x0403, 0x6001 )
if ret < 0:
    print( 'unable to open ftdi device: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
    os._exit( 1 )


# bitbang
ret = ftdi.set_bitmode( ftdic, 0xff, ftdi.BITMODE_BITBANG )
if ret < 0:
    print( 'Cannot enable bitbang' )
    os._exit( 1 )

for i in range( 64 ):
    #val = 2**i
    #print( 'enabling bit #%d (0x%02x)' % (i, val) )
    #ftdi.write_data( ftdic, chr(val), 1 )
    #time.sleep ( 1 )
    ftdi.write_data( ftdic, chr(0x02), 1)
    time.sleep ( 0.5 )
    ftdi.write_data( ftdic, chr(0x00), 1)
    time.sleep ( 0.2 )

ftdi.disable_bitbang( ftdic )
print( '' )



# close usb
ret = ftdi.usb_close( ftdic )
if ret < 0:
    print( 'unable to close ftdi device: %d (%s)' % ( ret, ftdi.get_error_string( ftdic ) ) )
    os._exit( 1 )

print ('device closed')
ftdi.free( ftdic )

Line 51 turns on the LED connected to the RX pin on my board which is the second pin out of 8. Pins are defined as follows :

Pin #0 = 0x01
Pin #1 = 0x02
Pin #2 = 0x04
Pin #3 = 0x08
Pin #4 = 0x10
Pin #5 = 0x20
Pin #6 = 0x40
Pin #7 = 0x80

Obviously these are binary sequence in Hex, meaning each bit represents a pin. To turn on multiple pins at once, just add the values together. 0x00 on line 53 turns all pins off.

The example code I previously mentioned was the basis of this program also contains a commented out section showing how to use pins as inputs. It is commented out because it doesn’t work with Python 3, but should work fine under Python 2.x.

UPDATE…

I’ve discovered that SainSmart produce relay boards that work in a similar way to this. Building on the above, I have produced a new post showing how to use these with Python on Linux.

Linux Based Camera

Introduction

The following details how to put together a system to automatically take and upload photos using a webcam attached to a small Linux computer. I have previously built a system that automatically took a photo when a user connected to a webpage, but this time I think I will just schedule photos to be taken at a fixed time interval for simplicity. This also means that I can upload to my hosting provider’s servers and share links without exposing my home IP.

This should provide a convenient way to check on your pets when you’re feeling bored at work. I will use specific hardware for this project, but the solution will be very portable. The reason for this is that I’m planning to use the operating system “Armbian“, a variant of Debian, primarily used on ARM based Single Board Computers (SBC). Armbian will run on a huge number of different boards and is similar in compatibility to Raspbian, the default operating system for the Raspberry Pi. I expect that, with a minimum of changes, the instructions here will work on most of these supported boards, and others.

Hardware

NanoPi NEO
NanoPi NEO

I will be using the following hardware :

  • A Friendly ARM NanoPi NEO with 512M of RAM. Mine is a v1.1
  • A micro SD card
  • An ethernet cable, a passive POE injector and splitter, plus an adapter to connect to the power connector on the NanoPi and a mains to 5v adapter for the other end
  • A USB webcam – almost anything will do. Mine is out of a “smart” birdbox
  • Not really hardware, but somewhere to upload the pictures is also required
  • Optional – A case for the NanoPi, or even better, a waterproof case for the NanoPi and the webcam
  • Optional – An infrared light, for nighttime viewing

While setting everything up, the following are needed / will be useful :

  • Another computer to remotely set things up
  • A USB to UART (3.3v in my case) adapter plus cable
  • A card reader for the micro SD card if required
  • A USB power adapter

It is worth noting that my selected board doesn’t have a display output – set up would be simpler if it did, but once it is in place there is no need for a display.

Step 1 – Setting up the card

I downloaded a disk image from https://www.armbian.com/nanopi-neo/ specifically the legacy kernel version 5.30. There are links to tools to flash an image for various platforms, as I’m using Linux, I tend to just use the command line tool dd to clone the image to an SD card this method should also work on MacOS X.

The file I downloaded is a .7z compressed archive. The file I’m interested in is called “http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO”. I will extract this to somewhere handy.

Armbian Archive Contents
Armbian Archive Contents

To write the image to an SD card, unmount it (carefully, don’t overwrite the wrong disk), navigate to the folder where the disk image is located using cd and use the following command :

sudo dd if=./<imagename.img> of=/dev/<drive> bs=4M && sync

Replace <imagename.img> with the name of of your disk image and replace <drive> with the name of your drive. My SD card was called mmcblk0. You can probably find the name of the device by running the command ‘df -h’ before, and then again after, placing the device in the computer. SD cards often start with mmcblk, while other disk types might be sda, sdb, sdc etc. Take extra care as the chances are that sda and similar are disks in your computer. Make sure you’re certain before you overwrite anything! The bs argument means block size. if is the source, of is the destination. The final part, “&& sync” is a second command tacked on the end to ensure that the content of the SD card (and all other drives) are synchronised and fully up to date.

There isn’t much feedback from the command dd, but once it is finished it spits out a bit of info about the transfer and returns to the command prompt. It is now OK to eject the SD card and place it in the NanoPi.

USB to UART Adapter
USB to UART Adapter

The UART adapters I like (because they’re cheap) have a jumper to select between 3.3v and 5v. Make sure you check this before plugging it in. It is worth getting these adapters as they let you program all sorts of MCUs as well as use the serial debug ports on all sorts of devices.

Plug in an ethernet cable, the UART (set to 3.3v for this board). For my v1.1, the UART port is against the USB port, this has moved for later versions of the board. For my board, GND is the furthest from the edge of the board, I have left the next pin (5v) unconnected. The next two pins are TX and RX in that order. Remember to connect the SBC’s RX to the adapter’s TX and SBC’s TX to the adapter’s RX. The following is the pinout for newer versions of the NanoPi Neo. Be sure to use the correct pinout for your device.

NEO Pinout
NEO Pinout

With the USB to UART plugged into a computer, you will need to open a serial terminal. On Linux, the simplest way is to use the command “screen” if it is installed (it usually is). On Windows, Putty would be my preference. “screen” may be installed on MacOS X, I’m not sure. If it isn’t google search for a MacOS serial terminal program and see what the internet recommends.

To find the correct port and open the connection, use the following commands at the command line on Linux. Plug the USB to UART adapter into the computer after typing the command on line 1 (not the example prompt I’ve included, that is, only type starting with ls… etc)  :

exampleuser:~$ ls /dev/tty*
/dev/tty    /dev/tty19  /dev/tty3   /dev/tty40  /dev/tty51  /dev/tty62
/dev/tty0   /dev/tty2   /dev/tty30  /dev/tty41  /dev/tty52  /dev/tty63
/dev/tty1   /dev/tty20  /dev/tty31  /dev/tty42  /dev/tty53  /dev/tty7
/dev/tty10  /dev/tty21  /dev/tty32  /dev/tty43  /dev/tty54  /dev/tty8
/dev/tty11  /dev/tty22  /dev/tty33  /dev/tty44  /dev/tty55  /dev/tty9
/dev/tty12  /dev/tty23  /dev/tty34  /dev/tty45  /dev/tty56  /dev/ttyGS0
/dev/tty13  /dev/tty24  /dev/tty35  /dev/tty46  /dev/tty57  /dev/ttyS0
/dev/tty14  /dev/tty25  /dev/tty36  /dev/tty47  /dev/tty58  /dev/ttyS1
/dev/tty15  /dev/tty26  /dev/tty37  /dev/tty48  /dev/tty59  /dev/ttyS2
/dev/tty16  /dev/tty27  /dev/tty38  /dev/tty49  /dev/tty6   /dev/ttyS3
/dev/tty17  /dev/tty28  /dev/tty39  /dev/tty5   /dev/tty60
/dev/tty18  /dev/tty29  /dev/tty4   /dev/tty50  /dev/tty61
exampleuser:~$ ls /dev/tty*
/dev/tty    /dev/tty19  /dev/tty3   /dev/tty40  /dev/tty51  /dev/tty62
/dev/tty0   /dev/tty2   /dev/tty30  /dev/tty41  /dev/tty52  /dev/tty63
/dev/tty1   /dev/tty20  /dev/tty31  /dev/tty42  /dev/tty53  /dev/tty7
/dev/tty10  /dev/tty21  /dev/tty32  /dev/tty43  /dev/tty54  /dev/tty8
/dev/tty11  /dev/tty22  /dev/tty33  /dev/tty44  /dev/tty55  /dev/tty9
/dev/tty12  /dev/tty23  /dev/tty34  /dev/tty45  /dev/tty56  /dev/ttyGS0
/dev/tty13  /dev/tty24  /dev/tty35  /dev/tty46  /dev/tty57  /dev/ttyS0
/dev/tty14  /dev/tty25  /dev/tty36  /dev/tty47  /dev/tty58  /dev/ttyS1
/dev/tty15  /dev/tty26  /dev/tty37  /dev/tty48  /dev/tty59  /dev/ttyS2
/dev/tty16  /dev/tty27  /dev/tty38  /dev/tty49  /dev/tty6   /dev/ttyS3
/dev/tty17  /dev/tty28  /dev/tty39  /dev/tty5   /dev/tty60  /dev/ttyUSB0
/dev/tty18  /dev/tty29  /dev/tty4   /dev/tty50  /dev/tty61
exampleuser:~$ screen /dev/ttyUSB0 115200

The second type you enter the command ls /dev/tty*, there will be a single extra entry. This is the device you plugged in. In my case, it was called /dev/ttyUSB0. The third command, screen /dev/ttyUSB0 115200 opens a serial terminal at 115200 baud. The baud is the communication speed. I know that my NanoPi uses 115200 because I guessed what it used and got it right on my second try. It would have taken longer to look it up.

You will be rewarded with a blank screen. Plug the NanoPi into a power source (of the correct type) and a large amount of text should scroll past. Once it finishes, you will be presented with a login prompt. With the image I have used, the default credentials are root and 1234. As soon as these are entered, you will be asked to update the password for root… and then to create a new user account – follow the on screen instructions. You do not need to enter anything other than usernames and passwords, the rest can be left blank. After that you will be asked to restart. Do that by typing “reboot” and pressing enter.

Your OS is now installed, and your user account created.

While we are at this point, it is worth making a note of the network address of the device. With Armbian, your IP address is provided when you log in – there are two columns of information under the device name written in ASCII art, on my device, IP is the last item in the right hand column. Alternatively, you can connect using the name of the device (in my case “nanopineo”,  as per the command prompt) instead of the IP, although this doesn’t seem to work from all machines – for example it never works from an Android machine due to how they’re set up.

Logged Into NanoPi
Logged Into NanoPi

If you need to power off the NanoPi, use the command “sudo shutdown now -h” and enter your password. Once the board says “Power down.” you can remove the power.

Step 2 – Installing Required Software

Software to be used :

  • fswebcam – to interface with the webcam
  • crontab – to schedule image updates
  • ftp – an ftp client
  • sshpass – tool for passing the password to other commands we’ll be using
  • Optional – ImageMagick – not used here, but this is a very flexible tool that can be used to process images in a script – allows you to generate montages, scale images and much much more.

Power up and log into the NanoPi, the USB UART adapter is no longer needed, so you can plug the NanoPi in anywhere as long as it has ethernet and power. First things first, we make sure that all the software lists and software is up to date, to do this, enter the following command and then go and make a cup of tea, and perhaps have a slice of cake :

sudo apt-get update && sudo apt-get upgrade

Once the computer returns to the command prompt, we’ll install the programs that we’ll need with the following command:

sudo apt-get install fswebcam sshpass ftp

While these programs install, set up an sftp server into your webserver that you already have. Write down the server address, username and password.

Enter the following command :

sudo nano /root/script.sh

This will open a command line editor, editing a new file located in the folder /root/, called script.sh. Type, or paste in the following (ctrl-v won’t work, you’ll need to right click in the window and select paste).

fswebcam --fps 15 -r 640x480 --jpeg 85 -D 0 /home/<username>/picture.jpg -S 8
sshpass -f /root/data sftp <SFTPUserName>@<SFTPDomain> << EOT
put /home/<username>/picture.jpg ./
quit
EOT

You will need to change <username> to read the name of the username you set up on your NanoPi, SFTPUserName to the username for your SFTP server and SFTPDomain to the address of your SFTP server. Once done, press ctrl-x followed by the ‘y’ key, followed by the enter key, to exit and save your file.

Next, we store the password for your SFTP server. Storing passwords as text is never a good idea. My provider hasn’t given me a way of generating a key and so I’m a little stuck. To minimise the chance of issues, I am storing the password in a file controlled only by root, but if someone gets your root password and access to the machine, they’ll be able to read it. My machine will be behind a firewall with not external access. Suggestions for better ways of doing this are welcome.

Use the following command to store the password in the root account, in a file called “data”  :

sudo echo <yourSFTPpassword> /root/data

Obviously, replace <yourSFTPpassword> with the password for your SFTP server.  SFTP stands for SSH file transfer protocol – similar to regular FTP, but using an SSH to encrypt the traffic.

The script we have written takes a picture, saves it as picture.jpg, connects to our SFTP server using an encrypted connection and the password stored in the file “data”. It then uses feeds the put command into the sftp software to send picture.jpg to the remote server, specifically saving it to the current active directory. In my case this would be the top level of the domain, so the image would appear at http://elephantandchicken.co.uk/picture.jpg (which it doesn’t, because this is an example and not actually what I did).

The script we wrote currently is not executable and to make this useful we want to run the command every so often automatically. To do this, we use a built in command called crontab. Enter the following two commands :

sudo chmod +x /root/script.sh
sudo crontab -e

The first command gives permission for the file script.sh to be executed as a script. The second command opens the settings file for cron, our scheduler. The sudo at the start means that we will be running it as root, and so can run the command we created as it belongs to root. Move to the bottom of the file using the cursor keys and add a line with the following :

*/15 * * * * sudo /root/script.sh

Save and exit as before, with ctrl-x, ‘y’, and enter.

This is a bit of a rushed description and I’ll try to come back to refine / improve. I’m currently waiting on some power injector / splitter cables so I can set up the board in the shed with only a single cable (ethernet) from the house. This works well as I have some weatherproof ethernet.

Note for some cameras

When using a SQ11 type camera, I found that I was getting an error when trying to fetch a picture over USB. This was fixed by executing the following command on the command line :

echo "options uvcvideo quirks=2" >> /etc/modprobe.d/uvcvideo.conf

 

Fan control on the UDOO x86

The other day I got myself an UDOO x86 (specifically the penultimate “Advanced Plus” model). An interesting device that sits between most of the ARM SBCs and an older PC in performance. Steam games such as Bastion, Rogue Legacy and Super Meat Boy seem to work OK, Youtube plays fullscreen just fine although Steam game preview videos lag – watching processor usage I suspect that the graphics chipset (Intel 400) is not providing any acceleration in this context. I was not impressed by the fact that the quoted CPU frequencies are a misleading “Up to 2.24Ghz”, which really means, “2.24Ghz boost, 1.7Ghz operation” – I have not seen the board exceed 1.7Ghz while running Linux.

UDOO x86 Top
UDOO x86 Top

Another unusual feature of the board is that the built in eMMC shows up as an SD card. Probably unrelated, but I had more difficulty installing dual boot Linux on the internal eMMC and a plugged in M.2 drive than I ever have had on any machine – many of which weren’t even intended to run Linux! The main issue related to an error when installing GRUB

UDOO x86 Bottom
UDOO x86 Bottom

I spent a huge amount of time looking for a 2260 M.2 ssd (60mm length) and couldn’t find one in stock anywhere of a brand I’d trust. Suddenly I realised that the offset between the two sockets meant that a 2242 (42mm) board would fit in the top slot using the 30mm screw fitting for the lower slot (intentional I’m sure, but not obvious!). 42mm boards seem to be more common and so I was able to get a 64GB Transcend part.

I got the offered fan with my device, but it really isn’t needed. Getting the fan to start with the default settings is difficult as even at full processor usage (all cores) I wasn’t able to get the processor hot enough to need it. I poked the internet and found the instructions for the BIOS. There was a section that mentioned editing the default fan temperatures and speeds so I did a bit of a tweak. The fan now starts at a lower temperature, and runs at a lower speed.

BIOS Top Level Menu
BIOS Top Level Menu

To change your fan settings, press escape as soon as the board powers on to get to the bios homescreen. Selecting the SCU option leads to a detailed settings page which looks like the following screen :

BIOS SCU Page
BIOS SCU Page

Selecting the “Power” section from the options at the top, you are presented with various options including one called “Thermal Zone Configuration”. As per page 54 / section 4.5.3 of the manual you can edit various settings, I’ve changed “AC1 Temperature” to 55°C and “FAN Duty Cycle (%) Above AC1” to 50%. This means the fan is nice and quiet when it does start.

I’ve yet to experiment with much on the board. I’m interested in having a look at the Arduino capabilities – care should be taken as next to the Arduino headers are some lower voltage (1.8v) pins for the main chipset. Wiring something into these accidentally would likely cause damage.

UDOO Arduino Pinout
UDOO Arduino Pinout

UDOO Main Processor Pinout
UDOO Main Processor Pinout

More details about the connectors are available here for the Arduino connectors, and here for the main processor connectors.

(Pictures used in this post are all from the UDOO website)