New development projects for 2018 – SQL Data-base management, Psion Series 5 second life, Element 14 PiDesktop

I have three news Development projects and Study areas that I have been working on in January 2018 as follows:

Asus Tinker Board SQL Data base server.

Almost all computer based projects including those in the Makers community at some point need to (create , story and retrieve data), this data can be in the form of (configuration parameters, users/sensor input, log files and statistics analysis). This data can be stored locally within each application design, however there are some considerable advantages to storing all application data externally from application related data files and their constants and variables.

One clear advantage of this is that if you use an external data-base management system such as an SQL-server, your data and its structurer will both be available to any external application that wishes to use it. SQL servers are fully structured systems and document within themselves the structure of any database they contain and manage. So you can then use any available management tools (e.g. pgadmin3), of which there are many that relate to an SQL data-base management system, to view the structure of tables to include in your code.

The ability to analyses the data structures involved within applications is one of the biggest restrictions when in comes to extending or debugging applications , some of which may have been written many years before and where documentation may be poor or lost altogether. You can if permitted access and view the structure of data files from a good SQL managment tool within minutes and begin to design or debug your application within the hour.

Also as a rule a fully featured SQL server application also places your data behind a secure curtain along with providing fully secure backup and restore facilities, one of the issues with small scale SBC applications is that they are viewed mainly from a local system perspective, yet the data they produce can often be mission critical, as such all their data should be transfered to remote systems for the reasons of (security, analysis and backup).

Debian based Linux, the most popular distribution of Linux for the SBC(Single Board computer) maker market, including the ASUS Tinker board and the Raspberry Pi, have the ability to install versions of MYSQL and POSTGRESQL 9.6 or newer, so that you can store all your applications data locally on the same SBC (however as stated above this is not advisable). In my own project here I will make use of two ASUS Tinker boards, one acting as a client and the other as the SQL-server using TCP/IP based SQL drivers and coding applications in (C++ and/or Python) and using a client/server connection between the two systems. Constructing this Client/server model will show how its possible to connect any SBC based application into a much larger industrial based environment, such as in a factory setting where application data may need to be logged in order to provide control information and production reporting statistics.

In the bigger picture, I hope to use 2018 in order to update my SQL data based management skill, using this project as a starting point adding some new and up-to date qualifications including certificates in postgresQL and possibly MYSQL. My I.T. background is located firmly in this area having worked on IBM UNIX/LINUX and MS-Windows server installations for many years.

The other two projects I am currently working on are as follows :

Psion Series 5 – Second life Project

I have almost completed a project to give the 1990’s Psion series 5 and new life as a serial terminal within a SBC network, this is a great use for this old machine. The Series 5 from Psion is widely still held with respect within the Retro Hardware community. During my current projects with it I am amazed as to how usable I still fine this machine.

Way back in the late 1990’s Psion assembled a large team of designers and makers to get this product to market and its amazing that they completed the project within twelve months, whats even more amazing is that despite for one fault with the screen cable that even some twenty years on can be repaired and returned within two weeks, these machine are still working and stayed in great condition.

The Photo above is of the Ericsson version of the Psion 5MX, basically the same machine, with some stronger parts added and a small shift in the great set of applications installed on the ROM , including a full set of office based applications and more importantly for this project a full Programming language OPL used to transfer daat via a serial cable, along with a full VT100 serial terminal application allowing for a terminal into the BASH sheel, Amazing for 1999!.

This project added a text based terminal to a single board computer, allowing for such areas as (Shell terminal control, Text based monitoring, SQl text based command control, VIM editing, Python script running and editing, etc …..). Its worth noting that many Raspberry pi and SBC projects can involve running the PI from battery power , so can the Psion 5 system also work using two AA batteries that will last for some twenty + hours of constant use, providing for a great Raspbery pi companion!.

Raspberry PI Element 14 PIDesktop project

The third on going project I am working on is the creation of a Raspberry PI 3 desktop computer.

The Element 14 creation, the PiDestop is a late introduction to the Raspberry Pi extended product range , it includes one of the best cases every produced for this system , however this is not the most impressive feature!

This kit also includes a HAT board for the Raspbery Pi that includes an system on/off switch, a system battery (using a CR2032 ,3.0V,Lithium, 210 mAh) for the system clock backup and an interface for an SSD drive unto 1TB.

It is the ability to both boot an OS from and SSD drive and use the same drive for system storage that interested me the most about this project, upto the Raspberry Pi 3 all storage on the raspberry pi systems had to be limited to using an SD card, using an SSD drive however should increase available storage and speed up access times.

I will during a series of posts detail how to setup this system and make the best use of all the new features provided by the Element 14 product.

It also worth noting that this kit can be used with any SBC that has the same layout and GPIO pin configuration as the Raspberry PI 3 such as the ASUS tinker board and the Pine systems ROCK64 Boards.

Posted in Development board hardware, Development boards, Development Languages, Hardware construction, Linux, Nigel Borrington, Programming skills, Python, Second life Hardware, Study guides and exams, Uncategorized | Tagged , , , , , , , , , , , , , , , , , , , | Leave a comment

Linux Shell- command history

Linux Shell Command History

Linux Shell
Command History

NB : Please note that this post follows on from Linux Shell command tricks

The second of the tools available for the command line interface to a Linux shell is command History, Just like Command and file completion this set of tools provides the terminal user with a very fast method of command entry and processing.

Whenever a terminal users enters a command it is stored into a file within the users /home directory.

An example of the used file for a shell is:

For the BASH shell “/home/.bash_history”

Firstly as with many shell services it is worth noting that you can customise their configuration, for your own use if you so wish. The default setting are usually ok but if your a very heavy user such as a systems administrator however you may want to deviate somewhat from the norm/defaults.

An example of this is with the configuration of a shells history functions.

If you use the BASH shell, your main configuration file is /home/.bashrc and as default it contains the following lines for the bash history functions.



# don’t put duplicate lines or lines starting with space in the history.
# See bash(1) for more options

# append to the history file, don’t overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)


You can take the following facts out of looking through these lines of code !!

1. By default lines that begin with spaces or are already to be found in /home/.bash_history, will not be written to the file.

2. By default all commands during every shell session with be added to the /home/.bash_history file, not just the commands entered during the current and thus this, shell session.

3.. There is a shell history command called “shopt” you can look up in the man pages, in order to understand how it can be used to configure the shells history functions.

4.. The two variable’s HISTSIZE and HISTFILESIZE exist in order to limit the number of individual commands stored and/or the total size of the /home/.bash_history file.

These configuration options can best be explained as follows along with other options not configured as default :


Better shell history

By default, the Bash shell keeps the history of your most recent session in the .bash_history file, and the commands you’ve issued in your current session are also available with a history call. These defaults are useful for keeping track of what you’ve been up to in the shell on any given machine, but with disks much larger and faster than they were when Bash was designed, a little tweaking in your .bashrc file can record history more permanently, consistently, and usefully.
Append history instead of rewriting it

History append option

You should start by setting the histappend option, which will mean that when you close a session, your history will be appended to the .bash_history file rather than overwriting what’s in there.

shopt -s histappend

Allow a larger history file

The default maximum number of commands saved into the .bash_history file is a rather meager 500. If you want to keep history further back than a few weeks or so, you may as well bump this up by explicitly setting $HISTSIZE to a much larger number in your .bashrc. We can do the same thing with the $HISTFILESIZE variable.


The man page for Bash says that HISTFILESIZE can be unset to stop truncation entirely, but unfortunately this doesn’t work in .bashrc files due to the order in which variables are set; it’s therefore more straightforward to simply set it to a very large number.

If you’re on a machine with resource constraints, it might be a good idea to occasionally archive old .bash_history files to speed up login and reduce memory footprint.

Don’t store specific lines

You can prevent commands that start with a space from going into history by setting $HISTCONTROL to ignorespace. You can also ignore duplicate commands, for example repeated du calls to watch a file grow, by adding ignoredups. There’s a shorthand to set both in ignoreboth.


You might also want to remove the use of certain commands from your history, whether for privacy or readability reasons. This can be done with the $HISTIGNORE variable. It’s common to use this to exclude ls calls, job control builtins like bg and fg, and calls to history itself:


Record timestamps

If you set $HISTTIMEFORMAT to something useful, Bash will record the timestamp of each command in its history. In this variable you can specify the format in which you want this timestamp displayed when viewed with history. I find the full date and time to be useful, because it can be sorted easily and works well with tools like cut and awk.


Use one command per line

To make your .bash_history file a little easier to parse, you can force commands that you entered on more than one line to be adjusted to fit on only one with the cmdhist option:

shopt -s cmdhist

Store history immediately

By default, Bash only records a session to the .bash_history file on disk when the session terminates. This means that if you crash or your session terminates improperly, you lose the history up to that point. You can fix this by recording each line of history as you issue it, through the $PROMPT_COMMAND variable:

PROMPT_COMMAND=’history -a’


Basic shell history usage

1.. Retrieving a command

The most basic way to retrieve a command from the history system is to use the UP arrow key on the Keyboard, doing so repeatedly will scroll back through your command history until you reach the wanted command. If you go past the wanted command just press the down key !

The Ctrl+P and Ctrl+N keys perform the same function respectfully

Search history for a command

The above method works well if your wanted command was entered into history with-in the last few commands but not so well if it was entered a few days or weeks ago!

In order to retrieve older commands you can search for them in the history system as follows:

By pressing Ctrl+R and typing a few characters of the command you want, you will be able to search back through the shells command history. The characters should build up to form a unique part of the command, they need not be at the start of the command but can form any part of it, i.e. a file name or ip address. If you cannot enter a unique part of a command then by pressing Ctrl+R again you will be able to scroll through all commands that do contain the characters you have entered for the search.

NB : Ctrl-S performs a forward search if you find yourself anywhere before the end of the history file, having already performed a search with Ctrl-R for example. On some systems Ctrl-S my hang the terminal , by pressing Ctrl+Q you will free up the terminal again, the command “stty -ixon” should prevent this hanging from taking place again.

Command editor

When you have retrieved a command from history, just like when you are entering a command for the first time, you will without even realising it be using the keyboard instructions and command sets from one of two possible text editors (EMACS or VI), most Linux distributions use EMACS as default but you can change to VI/VIM and back again as follows !

enter “set -o vi” or “set -o emacs ” from the terminal prompt , you can also enter this command into you users profile configuration file /home/.profile.

NB : You can find many web pages that detail the syntax of both editors and will need to know this syntax to pass these Linux exams.

history command

by typing “history” at the command prompt, you will see a full list of all your history file commands along this their reference number.

i.e. 419 ls -al ./.h*

The following command short cuts can be used quickly, to both retrieve a command using its Ref number or retrieve the very last command in the history file as a reference point.

!! = Retrieve and execute the very last command
!(x) = Retrieve and execute the command with Ref number(x)
!-(x) = Retrieve and execute the command at the (final history ref number (x) – (x)

Clearing your command shell history

To clear you command history execute the following command

history -c


Bash history expansion

Setting the Bash option histexpand allows some convenient typing shortcuts using Bash history expansion. The option can be set with either of these:

$ set -H
$ set -o histexpand

It’s likely that this option is already set for all interactive shells, as it’s on by default. The manual, man bash, describes these features as follows:

-H Enable ! style history substitution. This option is on
by default when the shell is interactive.

You may have come across this before, perhaps to your annoyance, in the following error message that comes up whenever ! is used in a double-quoted string, or without being escaped with a backslash:

$ echo “Hi, this is Tom!”
bash: !”: event not found

If you don’t want the feature and thereby make ! into a normal character, it can be disabled with either of these:

$ set +H
$ set +o histexpand

History expansion is actually a very old feature of shells, having been available in csh before Bash usage became common.

This article is a good followup to Better Bash history, which among other things explains how to include dates and times in history output, as these examples do.

Basic history expansion

Perhaps the best known and most useful of these expansions is using !! to refer to the previous command. This allows repeating commands quickly, perhaps to monitor the progress of a long process, such as disk space being freed while deleting a large file:

$ rm big_file &
[1] 23608
$ du -sh .
3.9G .
$ !!
du -sh .
3.3G .

It can also be useful to specify the full filesystem path to programs that aren’t in your $PATH:

$ hdparm
-bash: hdparm: command not found
$ /sbin/!!

In each case, note that the command itself is printed as expanded, and then run to print the output on the following line.
History by absolute index

However, !! is actually a specific example of a more general form of history expansion. For example, you can supply the history item number of a specific command to repeat it, after looking it up with history:

$ history | grep expand
3951 2012-08-16 15:58:53 set -o histexpand
$ !3951
set -o histexpand

You needn’t enter the !3951 on a line by itself; it can be included as any part of the command, for example to add a prefix like sudo:

$ sudo !3850

If you include the escape string \! as part of your Bash prompt, you can include the current command number in the prompt before the command, making repeating commands by index a lot easier as long as they’re still visible on the screen.
History by relative index

It’s also possible to refer to commands relative to the current command. To subtitute the second-to-last command, we can type !-2. For example, to check whether truncating a file with sed worked correctly:

$ wc -l bigfile.txt
267 bigfile.txt
$ printf ‘%s\n’ ’11,$d’ w | ed -s bigfile.txt
$ !-2
wc -l bigfile.txt
10 bigfile.txt

This works further back into history, with !-3, !-4, and so on.
Expanding for historical arguments

In each of the above cases, we’re substituting for the whole command line. There are also ways to get specific tokens, or words, from the command if we want that. To get the first argument of a particular command in the history, use the !^ token:

$ touch a.txt b.txt c.txt
$ ls !^
ls a.txt

To get the last argument, add !$:

$ touch a.txt b.txt c.txt
$ ls !$
ls c.txt

To get all arguments (but not the command itself), use !*:

$ touch a.txt b.txt c.txt
$ ls !*
ls a.txt b.txt c.txt
a.txt b.txt c.txt

This last one is particularly handy when performing several operations on a group of files; we could run du and wc over them to get their size and character count, and then perhaps decide to delete them based on the output:

$ du a.txt b.txt c.txt
4164 a.txt
5184 b.txt
8356 c.txt
$ wc !*
wc a.txt b.txt c.txt
16689 94038 4250112 a.txt
20749 117100 5294592 b.txt
33190 188557 8539136 c.txt
70628 399695 18083840 total
$ rm !*
rm a.txt b.txt c.txt

These work not just for the preceding command in history, but also absolute and relative command numbers:

$ history 3
3989 2012-08-16 16:30:59 wc -l b.txt
3990 2012-08-16 16:31:05 du -sh c.txt
3991 2012-08-16 16:31:12 history 3
$ echo !3989^
echo -l
$ echo !3990$
echo c.txt
$ echo !-1*
echo c.txt

More generally, you can use the syntax !n:w to refer to any specific argument in a history item by number. In this case, the first word, usually a command or builtin, is word 0:

$ history | grep bash
4073 2012-08-16 20:24:53 man bash
$ !4073:0
What manual page do you want?
$ !4073:1

You can even select ranges of words by separating their indices with a hyphen:

$ history | grep apt-get
3663 2012-08-15 17:01:30 sudo apt-get install gnome
$ !3663:0-1 purge !3663:3
sudo apt-get purge gnome

You can include ^ and $ as start and endpoints for these ranges, too. 3* is a shorthand for 3-$, meaning “all arguments from the third to the last.”
Expanding history by string

You can also refer to a previous command in the history that starts with a specific string with the syntax !string:

$ !echo
echo c.txt
$ !history
history 3
4011 2012-08-16 16:38:28 rm a.txt b.txt c.txt
4012 2012-08-16 16:42:48 echo c.txt
4013 2012-08-16 16:42:51 history 3

If you want to match any part of the command line, not just the start, you can use !?string?:

$ !?bash?
man bash

Be careful when using these, if you use them at all. By default it will run the most recent command matching the string immediately, with no prompting, so it might be a problem if it doesn’t match the command you expect.
Checking history expansions before running

If you’re paranoid about this, Bash allows you to audit the command as expanded before you enter it, with the histverify option:

$ shopt -s histverify
$ !rm
$ rm a.txt b.txt c.txt

This option works for any history expansion, and may be a good choice for more cautious administrators. It’s a good thing to add to one’s .bashrc if so.

If you don’t need this set all the time, but you do have reservations at some point about running a history command, you can arrange to print the command without running it by adding a :p suffix:

$ !rm:p
rm important-file

In this instance, the command was expanded, but thankfully not actually run.
Substituting strings in history expansions

To get really in-depth, you can also perform substitutions on arbitrary commands from the history with !!:gs/pattern/replacement/. This is getting pretty baroque even for Bash, but it’s possible you may find it useful at some point:

$ !!:gs/txt/mp3/
rm a.mp3 b.mp3 c.mp3

If you only want to replace the first occurrence, you can omit the g:

$ !!:s/txt/mp3/
rm a.mp3 b.txt c.txt

Stripping leading directories or trailing files

If you want to chop a filename off a long argument to work with the directory, you can do this by adding an :h suffix, kind of like a dirname call in Perl:

$ du -sh /home/tom/work/doc.txt
$ cd !$:h
cd /home/tom/work

To do the opposite, like a basename call in Perl, use :t:

$ ls /home/tom/work/doc.txt
$ document=!$:t

Stripping extensions or base names

A bit more esoteric, but still possibly useful; to strip a file’s extension, use :r:

$ vi /home/tom/work/doc.txt
$ stripext=!$:r

To do the opposite, to get only the extension, use :e:

$ vi /home/tom/work/doc.txt
$ extonly=!$:e

Quoting history

If you’re performing substitution not to execute a command or fragment but to use it as a string, it’s likely you’ll want to quote it. For example, if you’ve just found through experiment and trial and error an ideal ffmpeg command line to accomplish some task, you might want to save it for later use by writing it to a script:

$ ffmpeg -f alsa -ac 2 -i hw:0,0 -f x11grab -r 30 -s 1600×900 \
> -i :0.0+1600,0 -acodec pcm_s16le -vcodec libx264 -preset ultrafast \
> -crf 0 -threads 0 “$(date +%Y%m%d%H%M%S)”.mkv

To make sure all the escaping is done correctly, you can write the command into the file with the :q modifier:

$ echo ‘#!/usr/bin/env bash’ >
$ echo !ffmpeg:q >>

In this case, this will prevent Bash from executing the command expansion “$(date … )”, instead writing it literally to the file as desired. If you build a lot of complex commands interactively that you later write to scripts once completed, this feature is really helpful and saves a lot of cutting and pasting.


History security footnote !!

Most likely system security should not be as a foot-note! but the following is a very important detail !!

Never enter passwords on the command line, as part of a command. Some shell commands allow you to do so but note that they will store these passwords into the history file as ascii text, so anyone who has access to your history file can see your passwords !!.

Many commands will prompt you for a password, if they need one to function, the password you enter in this way is never stored in your history file, so if you can always operate in this mode of security !!!

If you absolutely need to give your password as part of a command, then clear your history after you enter the command as follows:

history -c # clear your command history !

Posted in IT skills, Linux, Operating systems, Study guides and exams | Tagged , , , , , , , , , | Leave a comment

Linux Shell command tricks – Command completion

Linux shell Command tricks

Linux shell
Command tricks

The power of the command line in Linux Distributions is still very much at the forefront, many admin task can simply be performed much more efficiently this way.

This faster command entry speed, for admin tasks is true even by using the basic terminal but many of the most up-to date command shells such as (bash, ksh and zsh) provide powerful tools that can be used to speed up shell command entry and processing even more.

The tools available fall into the following areas :

1.. Command and File-Path/File-name completion
2.. Command History
3.. Command line editing using Emacs or Vim

NB: in this post I will detail command completion, areas 2 and 3 above I will given their own posts.

Command and path/file-name completion

Completion Tools assist the user in typing commands at the command line, by looking for and suggesting matching words for incomplete ones. Completion is generally requested by pressing the completion key (often the Tab ↹ key).

Completion works by allowing you to enter only part of the text you need to complete a full command element, after you enter part of the text (Command or filename etc…) you press the TAB key, the shell then try’s to complete the rest of the element for you and adds one following space.

If only one possible command or file-name etc.. exists then the shell will complete this part/element of the command for you.

If more than one possibility exists then the shell will fill in what it can, it will then automatically show you all the possibilities or expect you to press the TAB key again for these options to be shown, depending on the shell you are using.

The concept of command line completion is very powerful and well worth learning, in order to speed-up command entry, it relates to the following areas when a shell command is being constructed:

Command name completion
Path and filename completion
Wildcard completion
Variable completion
Command argument completion

These areas are detailed as below :

Command name completion
is the completion of the name of a command. In most shells, a command can be a program in the command path (usually $PATH), a builtin command, a function or alias.

Path/filename completion is the completion of the path to a file, relative or absolute.

Wildcard completion is a generalization of path completion, where an expression matches any number of files, using any supported syntax for file matching.

Variable completion is the completion of the name of a variable name (environment variable or shell variable). Bash, zsh, and fish have completion for all variable names. PowerShell has completions for environment variable names, shell variable names and – from within user-defined functions – parameter names.

Command argument completion is the completion of a specific command’s arguments. There are two types of arguments, named and positional: Named arguments, often called options, are identified by their name or letter preceding a value, whereas positional arguments consist only of the value. Some shells allow completion of argument names, but few support completing values.

The Tab Key then is the method by which you use the completion shell tool/service to speed up the entry of almost all elements of a command.

Wiki Ref : Command-line completion

Posted in computer fundamentals, IT skills, Linux, Operating systems | Tagged , , , , , , , | Leave a comment

Linux OS and GPIO managment

Linux GPIO control

Linux GPIO control

Please note that this post follows on from : GPIO Part 1 :ARM Development boards and their low-level coding Data-sheets

This post is part 2 of A Look at how development boards such as the Raspberry PI allow a developer to code applications that control external hardware, through the systems GPIO header ports using the built in GPIO cpu interfaces, included on many ARM “SOC” CPU’s.

Different versions of the Linux Operating system are configured to control the GPIO ports, via device interfaces controlled within the system Kernel. The operating system itself can be used via shell scripts to control the status of the GPIO input and output pins.

GPIO enabled versions of Linux for the Raspberry Pi and other boards such as the Radxa rock and Odroid, use a device file structure in the /sys/…. file systems to pass read and write (input and output) signals to the kernels GPIO virtual devices, shell commands can be designed within a shell script.

Different versions of Linux for different development boards, have differences in how they are configured but the effects of the coding outcome are identical !

The two below screen shots are from a Raspberry-Pi 3 and then from an Odroid U2 board.

/sys/class/gpio on a raspberry pi 3

/sys/class/gpio on a raspberry pi 3

/sys/class/gpio folder in an Odroid U2

/sys/class/gpio folder in an Odroid U2

You can clearly see that the folder on the ODROID system contains a lot more GPIO device folders as default, on the Raspberry pi it is not until you enable I/O on a GPIO pin number that the folder for that pin number is created and then deleted again once the pin is disabled.

The following is an example BASH shell script used to control GPIO pin Num 4 as output and Num 7 as Input.

I have added comments to this script so that you can follow the processes it is performing.



# GPIO numbers should be from this list
# 0, 1, 4, 7, 8, 9, 10, 11, 14, 15, 17, 18, 21, 22, 23, 24, 25

# Note that the GPIO numbers that you program here refer to the pins
# of the BCM2835 and *not* the numbers on the pin header.
# So, if you want to activate GPIO7 on the header you should be
# using GPIO4 in this script. Likewise if you want to activate GPIO0
# on the header you should be using GPIO17 here.

# The file /sys/class/gpio/export is used to define which GPIO pins are enabled,
# likewise the file /sys/class/gpio/unexport is used to disable these pins again.
# In order to define the direction a GPIO pin is going to be used for
# (Input or Output) you echo “out” or “in” to a file created in the GPIO pins
# folder named “direction”.
# Set up GPIO 4 and set to output
echo “4” > /sys/class/gpio/export
echo “out” > /sys/class/gpio/gpio4/direction

# Set up GPIO 7 and set to input
echo “7” > /sys/class/gpio/export
echo “in” > /sys/class/gpio/gpio7/direction

# In order to Write output or turn on the GPIO pin you
# echo a “1” to the file /sys/class/gpio/gpio(X)/value
echo “1” > /sys/class/gpio/gpio4/value

# In order to read input or a signal from a GPIO pin you
# cat /sys/class/gpio/gpio(X)/value to the screen or to
# a shell variable to tested later.
cat /sys/class/gpio/gpio7/value

# It is important to clean up the status of the pins
# as you do not want to leave pins active with a positive current !
echo “4” > /sys/class/gpio/unexport
echo “7” > /sys/class/gpio/unexport


NB : As you can see from the GPIO folders listings above the file owner in many installations is ROOT/SU, so in many cases you will have to use the following methods to perform the above operations.

echo “1” |sudo tee /sys/class/gpio/export

sudo sh -c ‘echo “1” > /sys/class/gpio/export’

Both methods work, the other option is to take ownership of the objects within the /sys/class/gpio folder, this however will not work on many systems as the folders are created and removed, with root permissions during the script processing, thus setting permissions before execution is not possible.

As a final note in this post, you should be aware that using Shell scripts at OS level like the one above, is the method selected by programming languages that do not have the ability to address GPIO control themselves. So long as these languages can call external OS shell scripts, then they can still be utilised to control external hardware.


The following posts that relate to GPIO coding will cover the following areas.

I want to construct a full review (that will involve more than one post!) of all available GPIO enabled programming languages starting with Python and followed by languages such as C++ and Java. I have found in the Radxa rock and some Raspberry Pi documentation that included coding examples, only involve – as I said above, opening and closing the related operating system files. To do this is most likely very slow and inefficient and also has the drawback of not producing stand-alone code. While this kind of code is more than ok for testing purposes ! why not work with the final aim of your code being fast and also having the ability to run itself in such away that it can be loaded in any environment with or without needing a particular OS or even one at all !!

Posted in computer fundamentals, Cubietruck, Linux, Odroid, Operating systems, Programming skills, Radxa rock, Raspberry pi, Single board computers, Software skills | Tagged , , , , , , , , , | Leave a comment

Looking at shells, internal and External commands

Linux's Internal and External Shell commands

Linux’s Internal and External Shell commands

This Study area follows on from this Post , Using Linux Shells

Each of the available command shells in Linux has two primary types of commands, Internal or External.


By saying a command is Internal, these commands are fully incorporated with in the coding of the shell itself. Each Shell such as (BASH, DASH, KSH and ZSH) offer very similar commands but some also offer unique commands.

You can see a list of a shells internal commands by using the man pages that relate to the shell, i.e. “man bash” or “man ksh”. The text that relates to the internal command set is located under the heading of “Built-in commands”.

The Shell BASH uses the “help” command to show you details that relate to its internal command set:

Bash Help page "$ help"

Bash Help page “$ help”


These commands are installed within your Linux Installation, externally of a shell’s own coding.

The main reason for installing external shell commands is to add flexibility to a Linux installation and to allow for command compatibility with existing software.

It should also be noted that external commands are also shared between different shells thus removing object redundancy, the ideal is that only commands that reflect on core differences and performance between shells should be internal to the shell.

The removal of object redundancy both saves disk space and the chance of programming errors.

Determining a commands type

You can use many different methods to determine if a command is internal or external to the shells core, starting with the most effective method as follows :

The type command (Internal and External)


$ type pwd
pwd is a shell builtin

the “type” command will return “command(x) is a shell command” if the given command is built into the shell and thus an internal command !

This answer however is not usually enough to help you know the full picture relating to any given command.

It is not unusual that a shell command exist in both internal and external forms, this can be because a (newer, more informative or more compatible) version has been installed into your core system.

To show just how many versions of a single command exist you can add the “-a” option as follows :

$ type -a pwd
pwd is a shell builtin
pwd is /bin/pwd

This use of the type command returns two lines, thus reporting that the command has found two existences of the pwd command.

Other methods of finding a command type (Internal or External) is to use the “which” command or the “whereis” command , these commands will however only confirm if a command is external and if so show its location.

You can also check the reference to “Built-in commands” within the selected shells man pages.

As said above bash also uses the “help” command to list all internal commands and there command line options, if your needed command is not listed here yet exists on the system then it is an external command usually located within your users default path.

Command order of execution and the $PATH environmental variable

When a command exists as both an internal and external command , it is the internal command that takes precedence, if you need to call the external command you need to include its full path when naming it on the command line or in a program or script.


>$ type -a time
time is a shell keyword
time is /usr/bin/time

>$ time , # entered on the command line will call the shell’s internal command

>$ /usr/bin/time # explicitly names time as /usr/bin/time

When a command is only installed as an external command and it is called from the command line or in a program/script, it is the users PATH that is searched to locate the external command. Clearly this then requires that the location of the external command is added into your user $PATH environmental variable, it is this variable that is used during any of your operations to find objects you call for execution or files that your operations require.

you can check if an objects location is in your $PATH as follows

>$ which vim

>$ echo $PATH

from the above you can see that the text editor “vim” exists in /usr/bin/ and that you $PATH env variable does have this folder location added correctly to it.

NB: You can add a directory path to $PATH variable.Run the below commands on terminal to add a directory path to the PATH-Variable,

su root

To add the path permanently to the BASH shell environment, add the following line at the end of ~/.bashrcfile

sudo gedit ~/.bashrc

Add the below line at the end,

export PATH=$PATH:/path/to/the/directory

Posted in Linux, Operating systems | Tagged , , , , , , | Leave a comment

Using Linux Shells, Command entry and Terminal emulators.

Linux Terminal Emulators

Linux Terminal Emulators

Please note that this post follows on from : The Linux Shell

Operating systems such as Linux and Microsoft windows owe their current existence to much earlier versions of themselves with ASCII-code Text based command lines as their only interface with their users.

Linux as an operating system, owes a great deal to Unix, with its user interface operating from physical ASCII code serial-connection terminals. The then following X-windows originated at the Massachusetts Institute of Technology (MIT) in 1984, it provided a basic framework for a GUI environment: drawing and moving windows on the display device and interacting with a mouse and keyboard. At its start X-windows was not seen as vital in order to operate a Unix based system, as such X was viewed as a Utility application and X applications as alternatives only, to text based programs.

In the same fashion but a little later, Microsoft Windows history began with MS-DOS followed by Windows 1, on November 20, 1985. This version of Windows like X-Windows was viewed by most as a utility application only and distributed by Microsoft as such, most users stayed with MS-DOS for a considerable time.

You can see from the two images here, just how close the early versions of both operating systems GUI’s are.


Over the Years Microsoft has done its best to offer users a Windows GUI interface only, trying to move people away from any text based commands. This however has not always gone down well, take windows 8 for example!, many felt it a step to far and Windows 10 has now move back towards at least giving the user a little more control.

For a desktop application user, having a Windows GUI environment only is ok, however for more advanced users of MS-Windows who deal with many thousands of files and vast amounts of data, it is almost impossible to control their systems.

X-Windows 1984

X-Windows 1984

In order to help these power users, Microsoft offers their Power-shell application, which in effect offers its user a more advanced MS-DOS command like experience and allows systems administrators to construct scripts, used to control system settings and file manipulation in an advanced and time saving way.

MS Windows 1 and 2

Version 1 of MS Windows

Back In the world of Linux and to some extent MAC-OS and Android, the command shell has very much stayed at the front of these operating systems. As covered in my posts on “Linux and Unix commands shells” you can see that shells such as KSH and BASH have been around for a long time and are still both actively updated and supported.

Linux shells are ingrained into every area of a Linux installation, they sit at two levels (Systems shells and user shells), operating from file management to user management, file and system security. There is little dispute that this fact alone keeps a Linux based system free of Viruses, unlike MS-Windows.

MS-Windows needs expensive and resource hungry applications as additional products, in order to achieve the same level of security based operations that Linux is doing natively with every single task.

Using a Linux Shell

Screenshot from 2016-05-01 15:21:04

There are three fundamental ways that a user can make use of any one of the many available Linux command shells :

1.. By logging into a system that is configured to offer the user a text based terminal at first point of contact, with or without the ability to then open a Graphical X-Windows based environment. Some distributions of Linux such as Arch-Linux are configured in such away when first installed, it is up to the users to add a GUI environment post installation.

2.. By login into a Linux machine remotely with basic TCP/IP network services such as SSH or FTP you will be presented with a command shell terminal environment.

3.. By executing what is referred to as a Terminal emulator application, “Emulator” because this type of application acts in nature as a pipe between the lower level shell and a graphical user environment and thus emulates a more native command line ASCII terminal interface.

It should be noted that with both of the above methods of interacting with a Linux shell, the shell that you will be presented with as default, is the one defined by the settings that are held within your user account details.

With the first method ( ASCII text based ) of shell interaction you have few choice’s when it comes to how your interface is configured. For command entry, you can configure such things as the type of text editor that you are working with (i.e. VIM or Emacs). Choosing one over the other effects such things as the methods used to recall previous commands and the movement of the cursor with control codes. Digging deep when it comes to this subject is well worth the effort as a full understanding of command entry, such as command completion will help you fly through tasks that otherwise could take a considerable duration.

The terminal emulator form of contact with your chosen Linux shell is a lot more exciting and fulfilling.

Most Linux Distributions come pre-installed with a terminal emulator, these are usually related to the type of Graphical desktop environment, that your user account has defined as a default, (i.e. GNOME or LXDE).

You can also install a different Terminal emulator from a Linux repository, finding these applications is also possible by using a package manager such as Synaptic or Yum or even the Ubuntu Linux software centre.

Example terminal emulators for Linux shells


More examples to look up and review for yourself before installing are( rxvt-unicode, Guake, Gnome Terminal, konsole, Pantheon Terminal, Terminology and Terminix).

My personal favourite Terminal emulator is, Terminator – as it Supports multiple terminal windows and is very user friendly and Highly customizable.

Posted in computer fundamentals, Linux, Operating system installation, Operating systems, Study guides and exams, Windows 10 | Tagged , , , , , , , , | Leave a comment

I/O Addresses and I/O memory

/proc/ioports and /proc/iomem  Linux system files

/proc/ioports and /proc/iomem
Linux system files

Please note that this post follows on from : IRQ’s and Interrupts

I/O Addresses and I/O memory relate to bi-directional Communications between (CPU/Computer to devices ) as opposed to IRQ’s/Interrupt’s which are one way (device to CPU/Computer) communications.

Communication via I/O Addresses and I/O memory also relates to more general data transfers as opposed to Interrupts using IRQ’s which tend to relate to operational signals such as “I have finished Printing your document”.

The CPU writes data or maybe control codes to a devices (I/O port , I/O memory address).

Note that unlike Interrupts, this is not a one way communication process, the CPU can also use a device’s IO port to read status information about the device.

Like interrupts, ports and addresses should not be shared!

The Following is a good example of the Linux system file /proc/ioports

I/O ports in /proc/ioports

0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
02f8-02ff : serial

The first column gives the I/O port address range reserved for the device listed in the second column.

I/O memory, /proc/iomem

System devices also need to have system memory allocated to them, devices such as the system RAM and GPIO ports .

The following is an example of the file /proc/iomem, taken from a Raspberry PI model 3

00000000-36ffffff : System RAM
00008000-007945ef : Kernel code
00804000-009497db : Kernel data
3f006000-3f006fff : dwc_otg
3f007000-3f007eff : /soc/dma@7e007000
3f00b840-3f00b84e : /soc/vchiq
3f00b880-3f00b8bf : /soc/mailbox@7e00b800
3f200000-3f2000b3 : /soc/gpio@7e200000
3f201000-3f201fff : /soc/uart@7e201000
3f201000-3f201fff : uart-pl011
3f202000-3f2020ff : /soc/sdhost@7e202000
3f215040-3f21507f : serial
3f300000-3f3000ff : /soc/mmc@7e300000
3f980000-3f98ffff : dwc_otg

The first column displays the memory used by each of the different types of registered device. The second column lists the details for the allocated memory.

This file tells the Linux Kernel system, where to find and store data that relates to the devices listed with in it.

Note : As with all Linux study, this information relates to a general perspective. You should take into account that Different versions of Linux May or May not do things in the orthodox fashion.

The Raspberry Pi using Rasbian Linux for example, does not have a /proc/ioports file available but does have the file /proc/iomem. Ubuntu Linux on a standard Intel PC has both /proc/ioports and /proc/iomem available to the system services.

You always have to dig deep when it comes to your own installation of Linux!

Posted in computer fundamentals, Linux, Operating systems, Uncategorized | Tagged , , , , , , , | Leave a comment

Device IRQ’s (interrupt requests) a Definition.


Definition of : IRQ (interrupt request)

An IRQ (interrupt request) value is an assigned location in memory where the computer can expect a particular device to interrupt it when the device sends the computer signals about its operation.

Note that communication via Interrupts is a one way process (Device to Computer) !

For example, when a printer has finished printing, it sends an interrupt signal to the computer. The signal momentarily interrupts the computer so that it can decide what processing to do next.

Since multiple signals to the computer on the same interrupt line might not be understood by the computer, a unique value must be specified for each device and its path to the computer.

Prior to Plug-and Play (PnP) devices, users often had to set IRQ values manually (or be aware of them) when adding a new device to a computer.

If you add a device that does not support Pnp, the manufacturer will hopefully provide explicit directions on how to assign IRQ values for it. If you don’t know what IRQ value to specify, you’ll probably save time by checking the manufacturers web site or calling their technical support phone number for the device and asking them.


Linux keeps a map of all allocated IRQ’s in the /proc/interrupts file. You can view this file using an editor or use the following command to output its content to a terminal.

cat /proc/interrupts

as an example I have listed and saved the /proc/interrupts file from different computer systems, these being a (Toshiba L300 laptop, Radxa rock board and Raspberry pi( B+, B2 and B3)). You can see from the below listings that each type of system has very different devices installed and that some systems contain more helpful details in this “interrupts” file than others.

The Raspberry Pi systems for example show the starting memory address for the GPIO interrupts, yet the Radxa rock system only shows you the IRQ numbers for the configured GPIO devices that are using IRQ’s.

The below details then at the very least can help you see that you will have a very different path to take when it comes to writing code to control the same type of hardware on different devices, such as GPIO input and output hardware (LED’s for example !).

IRQ’s for a Toshiba L300

IRQ Num, CPU0, CPU1, details
0: 1608280 84979 IO-APIC-edge timer
1: 5054 109 IO-APIC-edge i8042
8: 0 1 IO-APIC-edge rtc0
9: 37955 82 IO-APIC-fasteoi acpi
12: 1950 68 IO-APIC-edge i8042
16: 0 0 IO-APIC-fasteoi uhci_hcd:usb3, uhci_hcd:usb7
18: 0 0 IO-APIC-fasteoi uhci_hcd:usb8
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb6
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
23: 104886 4581 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5
42: 298749 54 PCI-MSI-edge eth4
43: 97179 17118 PCI-MSI-edge ahci
44: 240576 624194 PCI-MSI-edge i915
45: 27 30 PCI-MSI-edge snd_hda_intel
NMI: 14 20 Non-maskable interrupts
LOC: 705389 1336849 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 14 20 Performance monitoring interrupts
IWI: 32832 32161 IRQ work interrupts
RTR: 0 0 APIC ICR read retries
RES: 381401 345539 Rescheduling interrupts
CAL: 215 829 Function call interrupts
TLB: 240504 200521 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 50 50 Machine check polls
ERR: 0
MIS: 0

IRQ’s for the Radxa Rock development board

IRQ num, CPU0, CPU1, CPU2, CPU3, details
32: 221 0 0 0 GIC rk29-pl330.1
33: 0 0 0 0 GIC rk29-pl330.1
34: 53855 0 0 0 GIC rk29-pl330.2
35: 0 0 0 0 GIC rk29-pl330.2
38: 0 0 0 0 GIC bvalid
41: 0 0 0 0 GIC vepu
42: 0 0 0 0 GIC vdpu
43: 0 0 0 0 GIC rk3066b-camera
46: 60525 0 0 0 GIC rk30-lcdc.1
48: 3565 0 0 0 GIC dwc_otg, dwc_otg_hcd:usb1, dwc_otg_pcd
49: 3970695 0 0 0 GIC dwc_otg, host20_hcd:usb2
51: 1753 0 0 0 GIC eth0
55: 41944 0 0 0 GIC rk29_sdmmc.0
57: 2 0 0 0 GIC emmc
58: 4804 0 0 0 GIC rk30-adc
71: 0 0 0 0 GIC rk29xx_spim
72: 0 0 0 0 GIC rk30_i2c.0
73: 8420 0 0 0 GIC rk30_i2c.1
74: 4176 0 0 0 GIC rk30_i2c.2
75: 121 0 0 0 GIC rk30_i2c.3
76: 21176 0 0 0 GIC rk_timer0
77: 0 6426 0 0 GIC rk_timer1
84: 596 0 0 0 GIC rk30_i2c.4
91: 0 0 4959 0 GIC rk_timer2
92: 0 0 0 6607 GIC rk_timer3
95: 0 0 0 0 GIC rga
112: 0 0 0 0 GIC debug-signal
164: 0 0 0 0 GPIO play
165: 0 0 0 0 GPIO bt_default_wake_host_irq
170: 27 0 0 0 GPIO remotectl
173: 0 0 0 0 GPIO rtc_hym8563
FIQ: fiq_glue
IPI0: 0 0 0 0 Timer broadcast interrupts
IPI1: 4559 4984 4185 7763 Rescheduling interrupts
IPI2: 19 32 32 28 Function call interrupts
IPI3: 17 59 232 98 Single function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 0 0 0 0 CPU backtrace
LOC: 0 0 0 0 Local timer interrupts
Err: 0

IRQ table for the Raspberry Pi B+

IRQ num, CPU0, details
3: 18089 ARMCTRL 3 Edge BCM2708 Timer Tick
16: 0 ARMCTRL 16 Edge bcm2708_fb dma
32: 138475 ARMCTRL 32 Edge dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
49: 0 ARMCTRL 49 Edge 20200000.gpio:bank0
50: 0 ARMCTRL 50 Edge 20200000.gpio:bank1
65: 16 ARMCTRL 65 Edge 2000b880.mailbox
66: 2 ARMCTRL 66 Edge VCHIQ doorbell
75: 1 ARMCTRL 75 Edge
77: 5535 ARMCTRL 77 Edge DMA IRQ
82: 746 ARMCTRL 82 Edge mmc0
83: 5 ARMCTRL 83 Edge uart-pl011
FIQ: usb_fiq
Err: 0

IRQ table for the Raspberry Pi B 2

IRQ num, CPU0, CPU1, CPU2, CPU3, details
16: 0 0 0 0 ARMCTRL 16 Edge bcm2708_fb dma
20: 0 0 0 0 ARMCTRL 20 Edge DMA IRQ
21: 0 0 0 0 ARMCTRL 21 Edge DMA IRQ
32: 106364 0 0 0 ARMCTRL 32 Edge dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
49: 0 0 0 0 ARMCTRL 49 Edge 3f200000.gpio:bank0
50: 0 0 0 0 ARMCTRL 50 Edge 3f200000.gpio:bank1
65: 36 0 0 0 ARMCTRL 65 Edge 3f00b880.mailbox
66: 2274 0 0 0 ARMCTRL 66 Edge VCHIQ doorbell
75: 1 0 0 0 ARMCTRL 75 Edge
77: 5487 0 0 0 ARMCTRL 77 Edge DMA IRQ
79: 0 0 0 0 ARMCTRL 79 Edge 3f804000.i2c
80: 0 0 0 0 ARMCTRL 80 Edge 3f204000.spi
82: 520 0 0 0 ARMCTRL 82 Edge mmc0
96: 0 0 0 0 ARMCTRL 96 Edge arch_timer
97: 3336 3138 2762 2616 ARMCTRL 97 Edge arch_timer
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 10445 12060 18171 14350 Rescheduling interrupts
IPI3: 10 16 16 13 Function call interrupts
IPI4: 32 43 67 202 Single function call interrupts
IPI5: 0 0 0 0 CPU stop interrupts
IPI6: 0 0 0 0 IRQ work interrupts
IPI7: 0 0 0 0 completion interrupts
Err: 0

IRQ table for the Raspberry Pi B 3

IRQ num, CPU0, CPU1, CPU2, CPU3, details
16: 0 0 0 0 ARMCTRL 16 Edge bcm2708_fb dma
20: 0 0 0 0 ARMCTRL 20 Edge DMA IRQ
32: 12410673 0 0 0 ARMCTRL 32 Edge dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
49: 0 0 0 0 ARMCTRL 49 Edge 3f200000.gpio:bank0
50: 0 0 0 0 ARMCTRL 50 Edge 3f200000.gpio:bank1
65: 1494 0 0 0 ARMCTRL 65 Edge 3f00b880.mailbox
66: 2 0 0 0 ARMCTRL 66 Edge VCHIQ doorbell
75: 1 0 0 0 ARMCTRL 75 Edge
77: 21849 0 0 0 ARMCTRL 77 Edge DMA IRQ
82: 14846 0 0 0 ARMCTRL 82 Edge mmc0
83: 4962 0 0 0 ARMCTRL 83 Edge uart-pl011
84: 753993 0 0 0 ARMCTRL 84 Edge mmc1
96: 0 0 0 0 ARMCTRL 96 Edge arch_timer
97: 558639 362236 427497 330519 ARMCTRL 97 Edge arch_timer
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 351505 410401 258035 378912 Rescheduling interrupts
IPI3: 5 10 10 11 Function call interrupts
IPI4: 7 142 88 58 Single function call interrupts
IPI5: 0 0 0 0 CPU stop interrupts
IPI6: 0 0 0 0 IRQ work interrupts
IPI7: 0 0 0 0 completion interrupts
Err: 0

The first column refers to the IRQ number. Each CPU in the system has its own column and its own number of interrupts per IRQ. The next column reports the type of interrupt, and the last column contains the name of the device that is located at that IRQ.

The first two tables are interesting as they show you the difference between the types of devices installed on a more traditional pc and those of a ARM CPU based development board such as the Radxa Rock.

Some of the devices listed are easier to identify than others e.g.

e.g. for the Radxa rock :

43: 0 0 0 0 GIC rk3066b-camera

This very clearly shows that IRQ 43 is allocated as the interupt for the rk3066b-camera module that can be plugged into the Radxa Rock camera port.

Other devices on the Radxa rock, such as :

173: 0 0 0 0 GPIO rtc_hym8563

are a lot less clear as to what they are, two great sources to find out are the Radxa rock peripherals Manual , or just browse the web for this device name, “rtc hym8563” for example.

As a final note for this post!, you may have noticed that on the Raspberry pi systems there is a listing of three lines for GPIO IRQ’s as follows

Raspberry Pi B+

49: 0 ARMCTRL 49 Edge 20200000.gpio:bank0
50: 0 ARMCTRL 50 Edge 20200000.gpio:bank1
65: 16 ARMCTRL 65 Edge 2000b880.mailbox

Raspberry Pi 2

49: 0 0 0 0 ARMCTRL 49 Edge 3f200000.gpio:bank0
50: 0 0 0 0 ARMCTRL 50 Edge 3f200000.gpio:bank1
65: 36 0 0 0 ARMCTRL 65 Edge 3f00b880.mailbox

Raspberry Pi 3

49: 0 0 0 0 ARMCTRL 49 Edge 3f200000.gpio:bank0
50: 0 0 0 0 ARMCTRL 50 Edge 3f200000.gpio:bank1
65: 1494 0 0 0 ARMCTRL 65 Edge 3f00b880.mailbox

from these details you can extract the simple fact that the IRQ physical memory address (given in HEX DECIMAL!)for the GPIO devices of (GPIO-BANK1 and 2, GPIO-mailbox) changed their addresses from models B+ to B2 but did not change form the Raspberry Pi b2 to b3!

NB : A future area for study relating to IRQ’s is to detail exactly how system software uses these IRQ/Interrupts but for this post this is just about the correct amount of information.

More reading on Irq’s and Interrupts

Note : This post is followed in study order by: I/O Ports and I/O memory

Posted in Development board hardware, Linux, Radxa rock, Raspberry pi, Single board computers, Uncategorized | Tagged , , , , , | Leave a comment

Introduction to the new “Study Notes section”

New Study Notes section

New Study Notes section

Introduction of the Study Notes section

I have been feeling the need on my blog to create a general study notes section, so today this is what I am doing. I find that there are general IT related topics that are getting lost in posts that relate to much bigger areas but I need these sub-skills to be easier to locate here as they themselves relate to multiple technical areas.

This new links section on the right hand side of the screen is simply titled “Study notes”, it will contain posts that relate to single study topics.

The reason for this new area of posts is that I feel a need to record notes on smaller technical areas as I perform my own areas of more complete – hardware and software study.

You can locate this new area at the very bottom of the links panel, right of this screen !

Posted in Introduction, Study guides and exams | Tagged , , , , , | Leave a comment

ARM Development boards and their low-level coding Data-sheets

Development Board GPIO

Development Board GPIO


Low level Arm Processor Development

Starting to get to grips with coding on any computer system is not a simple task. At the very start you need to select an appropriate coding language and then choose the best possible learning method and path to follow.

Most likely the most common way is to select the middle ground, one that is not too advance in its low level of closeness to the actual hardware of the computer, using machine code instructions and also one that is not to advanced in the world of object orientated methods.

Machine code programming along with Assembly language programming is not only a very difficult and time consuming way to learn to program, it is also not a requirement of any kind and not needed in order to develop projects on single board computers like the Raspberry pi.

However the process of learning just how your computer system truly works under the hood is great fun and will give you a greater sense of overall control, when you are doing your best to create well written and fully debugged code.

Following on from my last post on single board computer electronics project code development, at the end of the post I said I would move forward by following a path as follows :

1.. Looking at any available GPIO information from the Broadcom BCM2835-ARM-Peripherals manual and Radxa Rock Rockchip RK3188 CPU Datasheet

2.. A Look at how the Raspberry PI operating systems are configured to control the GPIO port, its pins and its operating system interfaces.

3.. Construct a full review in a series of posts, of all available GPIO enabled programming languages starting with Python and followed by languages such as C++ and Java.

Well firstly you can down load these datasheets and technical PDF’s at these links.

Raspberry Pi Broadcom BCM 2835/ Radxa Rock Rockchip RK3188 Datasheets

Broadcom BCM2835 ARM Peripherals


Rockchip RK3188

Firstly You need to understand that these manuals in the form of datasheets, are just like reading the Linux MAN pages, they are coldly technical and contain little in the way of help in actually developing applications that make use of their details.

Always download these manuals or the Datasheet/Manual that relates to your own system and its CPU and Devices but remember they are for reference only.

In order to start to make use of the details contained within, you will need to gain some help with Machine code or Assembly language coding itself and then start to bring in to this preliminary knowledge the technical details that relate to your own system.

Here are two links that will help you make a start, I have followed this path !

1.. ARM assembler in Raspberry Pi, this is a great starting point !!!

2.. Assembly language guides

3.. Amazon Books


This path is a rocky and hard one and you will fall off it into deep water many times !, one of the most noticeable potholes relates to the fact that for systems such as the Rasberry PI, most of the available information only relates to the model B boards and not the newer (B+ 2b and new 3b), many web based locations have not updated since the model B , yet they do not say clearly so !! , before you order a book or read a web page make sure it relates to your own model or check you are willing to learn from older models and then do the needed work to move forward !

e.g Baking Pi – Operating Systems Development , Here they do at least say that their operating system project has not been updated !!

There could be many reasons for this being the case, one possibly being the work and man hours that is needed to port very detailed low-level code from one version of the Raspberry pi to another (or any platform!). In this simple fact lies the basic problem with assembly language, you need to re-work your code for each system and take into account each of the technical changes within CPU versions.

The Answer and trick here is to wait and hold on, in time much more details about a newer system do get released to the general public or finds its way onto forums and blogs, this is a learning process ok and this can also include the developers. The other trick once you do get your much needed details is to make sure you check if they are correct and test them to work, then make and keep some good notes.

It is also this problem that correctly moves coders up the scale in their selection of development methods, they select a development path that makes use of higher level languages such as (C++, Java or Python) as examples. One great reason for doing so is that it is left to the developers of the C++ language for example, to include all the needed details with in the source compiler for the hardware it is being aimed at.

Hardware developers also release C++ libraries or PYTHON modules that can be incorporated into your source code.

To make use of a High level language thus removes you from needing to know all the low-level details, also meaning that very few people are producing the low level code used in higher level language hardware related functions, thus reducing the number of possible errors and bugs in your finished applications. This is good Right !!!

Despite all this though, it is still great fun to learn what your CPU is actually doing and like I already said very enabling if you can get to grips with all the needed details.

For the moment in my posts, I will move along my path as I detailed earlier , I will however return to Assembly language development as I personally enjoy it and feel its a great learning experience !

Posted in computer fundamentals, Development boards, Development Languages, Radxa rock, Raspberry pi, Software | Tagged , , , , , , , , , , , | Leave a comment