Connecting to a PICAXE

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I've just started a new project to build an electronic timer for use in  
an electric freeflight model aircraft.  

My current plot is to use an RPi model B fitted with a 3.5" TFT display  
as the control box and a PICAXE 14m2 chip as the timer, which means it  
needs to read a set of switches and to emit pwm pulse trains to drive the  
ESC (motor control) and an RC servo (other flight functions, e.g a  
dethermaliser, which is a device to bring the model down when the timer  
says the flight should end).  

The reason for using the RPi is because I can and because I hope that  
doing so it will teach me about fitting TFT displays and using GTK to  
handle them.  

The control box will be used to configure the timer which is connected to  
via an AXE027 USB serial cable. This is working: I currently have the  
PICAXE compiler up and running under jessie and talking to the PICAXE  
over an AXE027 cable.  

The next step is to port SerialPort, a daemon I wrote some time back to  
give Java programs access to serial ports, to the RPi. It is a daemon  
written in C that drives serial ports in response to commands sent by a  
client program over a socket connection. The application on the RPi will  
be a C program using GTK to interact with the user and the SerialPort  
daemon to send configuration data to the PICAXE. For completeness, I'd  
also like to be able to run this setup on any of my Fedora boxes.

So, two questions:

1) The AXE027 cable needs the Debian ftdi_sio kernel module.  
   This is present and working on my RPi, but dnf on a Fedora box has
   never heard of it. Do any of you know what the equivalent Fedora  
   module is called?  

2) Each time the RPi is booted, its necessary to run the following
   commands as root:

      modprobe ftdi_sio
      chmod 777 /sys/bus/usb-serial/drivers/ftdi_sio/new_id
      echo "0403 bd90" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
   which creates and initialises a new device, /dev/ttyUSB0

   I know how to set up a start script for SYSVinit to do this and then
   start the SerialPort daemon, but I'd appreciate and pointers for doing
   the same under systemd without cheating by using a sysVinit script.

   In particular: can I put everything into a serialport.service or it be
   better to declare that it wants /dev/ttyUSB0 and, by doing so,
   trigger a .device unit configuration file to set it up?  

   The /dev/ttyUSB0 device needs to be created each time the RPi is
   booted, though this can be done just before trying to do anything to
   the PICAXE, but it only needs to be created once no matter how often
   programs use it.

martin@   | Martin Gregorie
gregorie. | Essex, UK
We've slightly trimmed the long signature. Click to see the full one.
Re: Connecting to a PICAXE
On Mon, 19 Jun 2017 23:16:09 +0000, Martin Gregorie wrote:

Quoted text here. Click to load it
Sorted: the ftdi_sio kernel module is installed by default in Fedora 25,
so doing this as root:

       modprobe ftdi_sio chmod 777
       /sys/bus/usb-serial/drivers/ftdi_sio/new_id echo "0403 bd90" >

works and the device is accessible once I've added the 'dialout' group to  
my user.

martin@   | Martin Gregorie
gregorie. | Essex, UK
We've slightly trimmed the long signature. Click to see the full one.
Re: Connecting to a PICAXE
On 20/06/2017 12:17, Martin Gregorie wrote:
Quoted text here. Click to load it
Can't you replace all that guff with a udev rule so it just happens on  
plug in?

Re: Connecting to a PICAXE
On Tue, 20 Jun 2017 17:57:58 +0100, mm0fmf wrote:

Quoted text here. Click to load it

I don't think so, but am willing to be proved wrong:

- 'modprobe' forces the kernel to load and initialise the ftdi_sio
  module, which in turn extends the /sys/bus structure to include the
  ftdi_sio data structure when it is initialised

- 'chmod' makes this device world accessible but I don't know why.
  When the USB device is plugged in its readable and writable by owner
  (root) and group (dialout). The group permission allows the PICAXE
  compilers write compiled Basic directly into the chip. Their compilers
  can't be configured to write to a file and anyway they use special ARM
  IOctrl instructions to put the chip into EEPROM flashing mode. This
  is needed because the serial connection is also available for use by
  the programs running on the chip as well as for displaying debugging

- 'echo' changes an ID that's stored in the cable's USB<->serial
  adapter. I'm unclear why this should be needed but its stated as a

In any case, I've now hidden this stuff in a machine-portable way. I've  
just written a systemd service unit to manage the SerialPort daemon I'll
be using to interface my control box program to the USB cable and PICAXE  
chip, and have set these three commands up as an ExecStartPre command  
string in the [Service] section of the unit, where it can silently do its  
stuff at boot time.  

This is up and working on a laptop running Fedora. Next job is to move it  
SerialPort and the service unit to my RPi.

After its working on the RPi I'll put a couple of web pages documenting  
this and also referencing a few other useful sites for PICAXE development  
on my website.  
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Site Timeline