Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘raspberry pi

Raspberry Pi Gets 8Gig and 64-Bits

leave a comment »


The Raspberry Pi Foundation recently announced the availability of the Raspberry Pi 4 with 8-Gig of RAM along with the start of a beta for a 64-bit version of the Raspberry Pi OS (renamed from Raspbian). This blog post will look into these announcements, where the Raspberry Pi is today and where it might go tomorrow.

I’ve written two books on ARM Assembly Language programming, one for 32-bits and one for 64-bits. All Raspberry Pis have the ARM CPU as their brains. If you are interested in learning Assembly language, the Raspberry Pi is the ideal place to do so. My books are:

32- Versus 64-Bits

Previously the Raspberry Pi Foundation had been singing the virtues of their 32-bit operating system. It uses less memory than a 64-bit operating system and would run on every Raspberry Pi ever made. Further if you really wanted 64-bits then you could run alternative versions of Linux from Ubuntu, Gentoo or Kali. The limitation of 32-bits is that you can only address 4 Gig of memory, so this seems like a problem for an 8-gig device, but 32-bit Raspbian handles this and in fact each process can have up to 4-gig of RAM and hence all the 8gig will get used if needed, just across multiple processes.

The downside to this is that the ARM 64-bit instruction set is faster, the memory addressing is simpler without this extra Linux memory management and modern ARM processors are optimised around 64-bits and only maintain 32-bits for compatibility. There are no new improvements to the 32-bit instruction set and typically it can’t take advantage of newer features and optimizations in the processor.

The Raspberry Pi foundation has released a beta version of the Raspberry Pi OS where the kernel is compiled for 64-bits. Many of the applications are still 32-bits but can run fine in compatibility mode, this is just a band-aid until everything is compiled 64-bit. I’ve been running the 64-bit version of Kali Linux on my Raspberry Pi 4 with 4-gig for a year now and it is excellent. I think the transition to 64-bits is a good one and there will be many benefits down the road.

New Hardware

The new Raspberry Pi 4 model with 8-gig of RAM is similar to the older model. The change was facilitated by the recent availability of a 8-gig RAM chip in a compatible form factor. They made some small adjustments to the power supply circuitry to handle the slightly higher power requirements of this model. Otherwise, everything else is the same. If a 16-gig part becomes available they would be able to offer such a model as well. The current Raspberry Pi memory controller can only handle up to 16-gig, so to go higher, this would need to be upgraded as well.

The new model costs $75 USD with 8-gig of RAM. The 2-gig model is still only $35 USD. This is incredibly inexpensive for a computer, especially given the power of the Pi. Remember this is the price for the core unit, you still need to provide a monitor, cables, power supply, keyboard and mouse.

Raspberry Pi Limitations

For most daily computer usage the Raspberry Pi is fine. But what is the difference between the Raspberry Pi and computers costing thousands of dollars. Here are the main ones:

  1. No fast SSD interface. You can connect an SSD or mechanical harddrive to a Raspberry Pi USB port, but this isn’t as fast as if there was an M.2 or SATA interface. M.2 would be ideal for a Raspberry Pi given its compact size. Adding an M.2 slot shouldn’t greatly increase the price of a Pi.
  2. Poor GPU. On most computers GPUs can be expensive. For $75 or less you get an older less powerful GPU. A better GPU, like ARM’s Mali GPU or some nVidia CUDA cores would be terrific, but will probably double or triple the price of the Pi. Even with the poor GPU, the RetroPi game system is terrific.
  3. Faster memory interface. The Raspberry Pi 4 has DDR4 memory, but it doesn’t compare will to other computers with DDR4. This probably indicates a bottleneck in either the PCI bus or Pi memory controller. I suspect this keeps the price low, but limits CPU performance due to bottlenecks limiting the data flow to and from memory.

If the Raspberry Pi addressed these issues, it would be competitive with most computers costing hundreds of dollars more.


The 8-gig version of the Raspberry Pi is a powerful computer for only $75. Having 8-gig of RAM allows you to run more programs at once, have more browser windows open and generally have more work in progress at one time. Each year the Raspberry Pi hardware gets more powerful. Combine this with the forthcoming 64-bit version of the Raspberry Pi OS and you have a powerful system that is ideal for the DIY hobbyist, for people learning about programming, and even people using it as a general purpose desktop computer.

Written by smist08

June 5, 2020 at 4:36 pm

ARM Processor Modes

leave a comment »


Last time we discussed how ARM Processor interrupts work, and we mentioned that interrupts switch the processor from user mode to an operating system mode, but we never discussed what exactly the ARM Processor modes are. In this article we will discuss the ARM Processor modes, why they exist and when they are used.

The available processor modes vary by ARM model, so we will look at those commonly available. For the exact details on any specific ARM processor you need to check in that processor’s reference manual.

ARM Processor Modes

The purpose of processor modes is to regulate access to memory and hardware resources so that a process initiated by a specific user can’t access the memory of other processes or access hardware they don’t have permission for. The operating system can add quite refined permissions, so users only have access to certain files, read-only access to certain files, or other granular rights. This might all sound like overkill for a Raspberry Pi, but all versions of Linux, including Raspbian support multiple users and multiple processes all logged in and running at once. Further you might set up specific users and groups to grant the exact rights to processes like web servers to help protect you system from malicious hackers or program bugs causing havoc.

Most ARM processors have two security levels for processes. PL0 is for user mode programs and then PL1 is for operating system code. Newer ARM processors used in servers have a third level PL2 for virtualization hypervisors, so they can keep their various hosted operating systems completely separate. There is also an optional ARM build for secure computing, if this is present then there is an even higher PL3 level that is used for a system security monitor.

The following table from the ARM Processor Reference manual. There are quite a few processor modes and we’ll talk about them all, but the two main ones are user mode for regular programs and then system mode for the operating system.

Let’s list all the processor modes and describe what it is used for:

  • User – regular programs that can access the resources they have permission for.
  • FIQ – the processor goes into this mode when handling as fast interrupt. The operating system provides this code and it has access to all operating system resources.
  • IRQ – the processor goes into this mode when handling a regular interrupt. The operating system provides this code and it has access to all operating system resources.
  • Supervisor – when a user mode program makes an SVC Assembly instruction which calls an operating system services, the program switches to this mode, which allows the program to operate at a privileged level for the duration of the code.
  • Monitor – if you have an ARM processor with security extensions then this mode is used to monitor the system.
  • Abort – if a user mode program tries to access memory it isn’t allowed, then this mode is entered to let the operating system intervene and either terminate the program, or send the program a signal.
  • Hyp – this is hypervisor mode that is an optional ARM extension. This allows the virtual hypervisor run at a more secure level than the operating systems it is virtualizing.
  • Undefined – is a user mode program tries to execute an undefined or illegal Assembly instruction then this mode is entered and the operating system can terminate the program or send it a signal.
  • System – this is the mode that the operating system runs at. Processes that the operating system considers part of itself run at this level.

The mode bits in the table, are the bits that are set in the Control Program Status Register (CPSR) are the bits that get set in the lower order bits. This way the operating system can see what mode it’s in and act accordingly when appropriate.

ARM Boot Process

When powered on, the ARM processor starts up by initiating a reset interrupt. This causes the reset interrupt handler code to execute, which will typically be a branch to the code to start the operating system. At this point we are running in IRQ mode. We will change the processor mode to supervisor and initiate the operating system boot process. To change the processor mode we directly manipulate the bits in the CPSR with code like:

MRS   R0, CPSR        @ Move the CPSR to R0
BIC   R0, R0, #0x1F   @ clear the mode bits
ORR   R0, R0, #0x13   @ Set the mode bits to 10011 (SVC mode)
MSR   CPSR, R0        @ Update the CPSR

Note that reading and writing the CPSR like this are privileged instructions and only available to programs running in PL1 or better. Besides updating the processor mode, the operating system uses these to save a program’s state when doing multitasking. Saving the registers is easy, but the CPSR must also be preserved so as not to disrupt the running process.


This was a quick introduction to the ARM Processor modes. You don’t need to know this for application programming, but if you are interested in writing an operating system or if you are interested in how operating system support works for the ARM processor then this is a starting point.

If you are interested in learning more about ARM Assembly Language Programming, please check out my book, the details are available here.

Written by smist08

December 2, 2019 at 12:37 pm

Out-of-Order Instructions

leave a comment »


We think of computer processors executing a set of instructions one at a time in sequential order. As programmers this is exactly what we expect the computer to do and if the computer decided to execute our carefully written code in a different order then this terrifies us. We would expect our program to fail, producing wrong results or crashing. However we see manufacturers claiming their processors execute instructions out-of-order and that this is a feature that improves performance. In this article, we’ll look at what is really going on here and how it can benefit us, without causing too much fear.


ARM defines the Instruction Set Architecture (ISA), which defines the Assembly Language instruction set. ARM provides some reference implementations, but individual manufacturers can take these, customize these or develop their own independent implementation of the ARM instruction set. As a result the internal workings of ARM processors differs from manufacturer to manufacturer. A main point of difference is in performance optimizations. Apple is very aggressive in this regard, which is why the ARM processors in iPads and iPhones beat the competition. This means the level of out-of-order execution differs from manufacturer to manufacturer, further this is much more prevalent in newer ARM chips. As a result, the examples in this article will apply to a selection of ARM chips but not all.

A Couple of Simple Cases

Consider the following small bit of code to multiply two numbers then load another number from memory and add it to the result of the multiplication:

MUL R3, R4, R5 @ R3 = R4 * R5
LDR R6, [R7]   @ Load R6 with the memory pointed to by R7
ADD R3, R6     @ R3 = R3 + R6

The ARM Processor is a RISC processor and its goal is to execute each instruction in 1 clock cycle. However multiplication is an exception and takes several clock cycles longer due to the loop of shifting and adding it has to perform internally. The load instruction doesn’t rely on the result of the multiplication and doesn’t involve the arithmetic unit. Thus it’s fairly simple for the ARM Processor to see this and execute the load while the multiply is still churning away. If the memory location is in cache, chances are the LDR will complete before the MUL and hence we say the instructions executed out-of-order. The ADD instruction then needs the results from both the MUL and LDR instruction, so it needs to wait for both of these to complete before executing it’s addition.

Consider another example of three LDR instructions:

LDR R1, [R4] @ memory in swap file
LDR R2, [R5] @ memory not in cache
LDR R3, [R6] @ memory in cache

Here the memory being loaded by the first instruction, has been swapped out of memory to secondary storage, so loading it is going to be slow. The second memory location is in regular memory. DDR4 memory, like that used in the new Raspberry Pi 4, is pretty fast, but not as fast as the CPU and it is also loading instructions to process, hence this second LDR might take a couple of cycles to execute. It makes a request to the memory controller and its request is queued with everything else going on. The third instruction, assumes the memory is in the CPU cache and hence processed immediately, so this instruction really does take only 1 clock cycle.

The upshot is that these three LDR instructions could well complete in reverse order.

Newer ARM processors can look ahead through the instructions looking for independent instructions to execute, the size of this pool will determine how out-of-order things can get. The important point is that instructions that have dependencies can’t start and that to the programmer, it looks like his code is executing in order and that all this magic is transparent to the correct execution of the program.

Since the CPU is executing all these instructions at once, you might wonder what the value of the program counter register (PC) is? This register has a very precisely defined value, since it is used for PC relative addressing. So the PC can’t be affected by out-of-order execution. 


All newer ARM processors include floating-point coprocessors and NEON vector coprocessors. The instructions that execute on these usually take a few instructions cycles to execute. If the instructions that follow a coprocessor instruction are regular ARM instructions and don’t rely on the results of coprocessor operations, then they can continue to execute in parallel to the coprocessor. This is a handy way to get more code parallelism going, keeping all aspects of the CPU busy. Intermixing coprocessor and regular instructions is another great way to leverage out-of-order instructions to get better performance.

Compilers and Code Generation

This indicates that if a compiler code generator or an Assembly Language program rearranges some of their instructions, they can get more things happening at once in parallel giving the program better performance. ARM Holdings contributes to the GNU Compiler Collection (GCC) to fully utilize the optimization present in their reference implementations. In the ARM specific options for GCC, you can select the ARM processor version that matches your target and get more advanced optimizations. Since Apple creates their own development tools under XCode, they can add optimizations specific to their custom ARM implementations.

As Assembly Language programmers, if we want to get the absolute best performance we might consider re-arranging some of our instructions so that instructions that are independent of each other are in a row and hopefully can be executed in parallel. This can require quite a bit of testing to reverse engineer the exact out-of-order instruction capability of your particular target ARM processor model. As always with performance optimizations, you must test the performance to prove you are improving things, and not just making your code more cryptic.


This all sounds great, but what happens when an interrupt happens? This could be a timer interrupt to say your time-slice is up and another process gets to use the ARM Core, or it could be that more data needs to be read from the Wifi or a USB device.

Here the ARM CPU designer has a choice, they can forget about the work-in-progress and handle the interrupt quickly, or they can wait a couple of cycles to let work-in-progress complete and then handle the interrupt. Either way they have to allow the interrupt handler to save the current context and then restore the context to continue execution. Typically interrupt handlers do this by saving all the CPU and coprocessor registers to the system stack, doing their work and then restoring state.

When you see an ARM processor advertised as designed for real-time or industrial use, this typically means that it handles interrupts quickly with minimal delay. In this case, the work-in-progress is discarded and will be redone after the interrupt is finished. For ARM processors designed for general purpose computing, this usually means that user performance is more important than being super responsive to interrupts and hence they can let some of the work-in-progress complete before servicing the interrupt. For general purpose computing this is ok, since the attached devices like USB, ethernet and such have buffers that can hold enough contents to wait for the CPU to get around to them.

A Step Too Far and Spectre

Hardware designers went even further with branch prediction, where if a conditional branch instruction needs to wait for a condition code to be set, they don’t wait but keep going assuming one branch direction (perhaps based on the result from the last time this code executed) and keep going. The problem here is that at this point, the CPU has to save the current state, incase it needs to go back when it guesses wrong. This CPU state was saved in a CPU cache that was only used for this, but had no security protection, resulting in the Spectre attack that figured out a way to get at this data. This caused data leakage across processes or even across virtual machines. The whole spectre debacle showed that great care has to be taken with these sorts of optimizations.

Heat, the Ultimate Gotcha

Suppose your your ARM processor has four CPU cores and you write a brilliant Assembly language program that deploys to use all four cores and fully exploits out-of-order execution. Your program is now using every bit of the ARM CPU, each core is intermixing regular ARM, floating point and NEON instructions You have intermixed your ARM instructions to get the arithmetic unit operating in parallel to the memory unit. This will be the fastest implementation yet. Then you run your program, it gets off to a great start, but then suddenly slows down to a crawl. What happened?

The enemy of parallel processing on a single chip is heat. Everything the CPU does generates a little heat. The more things you get going at once the more heat will be generated by the CPU. Most ARM based computers like the Raspberry Pi assume you won’t be running the CPU so hard, and only provide heat dissipation for a more standard load. This is why Raspberry Pis usually do so badly playing high-res videos. They can do it, as long as they don’t overheat, which typically doesn’t take long.

This leaves you a real engineering problem. You need to either add more cooling to your target device, or you have to deliberately reduce the CPU usage of your program, where perhaps paradoxically you get more work done using two cores rather than four, because you won’t be throttled due to overheating.


This was a quick overview of out-of-order instructions. Hopefully you don’t find these scary and keep in mind the potential benefits as you write your code. As newer ARM processors come to market, we’ll be seeing larger and larger pools of instructions executed in parallel, where the ability for instructions to execute out-of-order will have even greater benefits.

If you are interested in machine code or Assembly Language programming, be sure to check out my book: “Raspberry Pi Assembly Language Programming” from Apress. It is available on all major booksellers or directly from Apress here.

Written by smist08

November 15, 2019 at 11:11 am

RISC Instruction Encoding

with one comment


Modern microprocessors execute programs from memory that are formatted specifically for the processor and the instructions it is capable of executing. This machine code is generated by tools, either fairly directly from Assembly Language source code or via a compiler that translates a high level language to machine code. There are two popular philosophies on how machine code is structured.  One is Reduced Instruction Set Computers (RISC) exemplified by ARM, RISC-V, PowerPC and MIPs processors, and the other is Complex Instruction Set Computers (CISC) exemplified by Intel and AMD processors. In RISC computers, each instruction is quite small and does a tiny bit of work, in CISC computers the instructions tend to be larger and each one does more work. The advantage of RISC processors is that the circuitry is simpler which means they use less power, this is why nearly all mobile devices use RISC processors. In this article we will be looking at some of the tricks RISC computers use to keep their instructions small and quick.

32-Bit Instructions

Most RISC processors use 32-bit machine code instructions. It doesn’t matter if the processor is 32-bit or 64-bits, this only refers to the size of pointers for memory addressing and the size of the registers, in both cases the instructions stay at 32-bits in length. With all rules there are exceptions, for instance in RISC-V processors most instructions are 32-bit, but there is a facility to allow longer instructions where necessary and in ARM processors, in 32-bit mode, there is the ability to limit instructions to 16-bits in length. Modern processors are very powerful and have a lot of functionality, so how do they encode all the information needed for an instruction into 32-bits? This restriction imposes a lot of discipline on the instruction set designers, but the solutions they have come up with are quite interesting. In comparison, Intel x86 instructions are variable length and often 120 bits in length.

Having all the instructions 32-bits in length makes creating an efficient execution pipeline very efficient, since you can load and start working on a set of instructions in parallel. You don’t need to decode one instruction to learn where the next one starts. You know there is a new instruction every 4-bytes in memory. This uniformity saves a lot of complexity and greatly enhances instruction execution throughput.

Where Do the Bits Go?

What needs to be encoded in a machine language instruction? Here are some of the possible components:

  1. The opcode. This tells the processor what the instruction does, whether its add two numbers, load data from memory or jump to another program location. If the opcode takes 8-bits then there are 256 possible instructions. To really save space some opcodes can be less bits, like perhaps if it start 011 then the other bits can go to the immediate value.
  2. Registers. Microprocessors load data into registers and then process the data in the registers. Often two or three registers need to be specified in an instruction, like the two numbers to add and then where to put the result. If there are 32 registers, then each register field will take 5-bits.
  3. Immediate data. Most processors have a way to encode some data in an instruction. Like “LOAD R1, 5” might mean load the value 5 into register R1. Here 5 is data encoded in the instruction, and called an immediate value. The size of these varies based on the instruction and use cases.
  4. Memory Addresses. Data has to be loaded from memory, or program execution has to jump to a different memory location. Note that in a modern computer memory addresses are either 32-bit or 64-bits. These are both too big to fit in a 32-bit instruction (we need at least an opcode as well). In RISC, how do we specify memory addresses?
  5. Bits for additional parameters. Perhaps there are several addressing modes, or perhaps other options for an instruction that need to be encoded. Often there are a few bits in each instruction for this purpose.


That’s a lot of information to pack into a 32-bit instruction. How do they do it? My introduction to Raspberry Pi Assembly Language shows how this is done for ARM processors in 32-bit mode.

How to Load a Register

Let’s look at how to load a 32-bit register with data. We can’t fit a full 32-bit value inside a 32-bit instruction, so what do we do? You might suggest that we load the value from memory rather than encode the value in the instruction. This is a legitimate thing to do, but it just moves the problem since we now need to load the 32 or 64-bit memory address into memory first.

First we could do it in two steps, perhaps we can fit a 16-bit value in an instruction and then perform two load instructions to load the value. In an ARM processor, there is a MOV instruction that can load a 16-bit immediate value and then a MOVT instructions that loads a 16-immediate value into the top 16-bits of a register. Suppose we want to load 0x12345678 into register R1, then in ARM 32-Bit Assembly we would encode:

MOVT R1, #0x1234
MOV  R1, #0x5678

This works and we do expect that working in RISC is going to take lots of small instructions to perform the work we need to get done. However this is somehow not satisfying, since this is something we do a lot and it seems wasteful to take two instructions. The other thing is that if we are running 64-bit mode and want to load a 64-bit register then this will take 4 instructions.

Another trick is to make use of the Program Counter (PC) register. This register points to the instructions currently being executed. So if we can position the value near this then we could load it by dereferencing the PC (plus a small offset). As long as the offset fits in the amount of room we have for an immediate value then this could work. In the ARM world, the Assembler helps us generate this code. We write something like:

LDR R1, =mydata


mydata: .WORD 0x12345678

Then the Assembler will convert the LDR instruction to something like:

LDR R1, [PC, #20]

Which means load the data pointed to by PC + 20 into R1. Now it only takes one instruction to load the data.  This technique has the advantage that it will remain one instruction to execute when dealing with 64-bit data.


This was a quick discussion of how RISC processors encode each machine code instruction as a 32-bit value. This is one of the key things that keeps RISC processors simple, allowing them to be quick while at the same time simple, and hence more power efficient.

If you are interested in machine code or Assembly Language programming, be sure to check out my book: “Raspberry Pi Assembly Language Programming” from Apress. It is available on all major booksellers or directly from Apress here.

Written by smist08

November 8, 2019 at 11:55 am

Raspberry Pi Assembly Language Programming

leave a comment »



My new book “Raspberry Pi Assembly Language Programming” has just been published by Apress. This is my first book to be published by a real publisher and I’m thrilled to see it appearing on websites of booksellers all over the Internet. In this blog post I’ll talk about how this book came to exist, the process of writing and publishing it and a bit about the book itself.

For anyone interested in this book, here are a few places where it is available:

Most of these sites let you see a preview and the table of contents.

This blog’s dedicated page to my book.

How this Book Came About

I purchased my Raspberry Pi 3+ in late 2017 and had a great deal of fun playing with it. I wrote quite a few blog posts on the Pi, a directory of these is available here. The Raspberry Pi package I purchased included a breadboard and a selection of electronic components. I put together a set of LEDs connected to the Pi’s GPIO ports. I then wrote a series of articles on making these LEDs flash using various programming languages including C, Python, Scratch, Fortran, and Erlang. In early 2018 I was interested in learning more about how the Pi’s ARM processor works and delved into Assembly language programming. This resulted in two blog posts, an introduction and then my flashing LED program ported to ARM Assembly Language.

Earlier this year I was contacted by an Apress Talent Acquisition agent who had seen my blog articles on ARM Assembly Language and wanted to know if I wanted to develop them into a book. I thought about it over the weekend and was intrigued. The material I found when writing the blog articles wasn’t great, and I felt I could do better. I replied to the agent and we had a call to discuss the book. He had me write up a proposal and possible table of contents. I did this, Apress accepted it and sent me a contract to sign.

The Process

Apress provided a Word style sheet and a written style guide. My writing process has been to write in Google Docs and then have my spouse, a professional editor, edit it. The collaboration of Google Docs is just too good to do away with. So I wrote the chapters in Google Docs, got them edited and then transferred them to MS Word and applied the Apress style sheet.

I worked with a coordinating editor at Apress who was very energetic in getting all the pieces done. She found a technical editor who would provide a technical review of each chapter as I wrote it. He was located in the UK, so often I would submit a chapter and see it edited overnight.

Once I had submitted all the chapters then a senior development editor gave the whole book a review. At that point I thought I was done, but then the book was given to Springer’s (Apress’s parent company) production department who did another editing pass. I was surprised that the production department still found quite a few things that needed fixing or improving.

After all that the book appeared fairly quickly. I like the cover, they used my photo of my breadboard with the flashing LEDs. As of today, the book is available at most booksellers, some with stock and some on preorder. I signed the contract in June and did the bulk of the writing in July and August. Overall, I’m pretty happy with the process and how things turned out.

The Book

My philosophy was to introduce complete working programs from Chapter 1 with the traditional “Hello World” program. I only covered topics where you could write the code with the tools included with the Raspberry Pi and run them. I lay the foundations for how to write larger Assembly programs, with how to code the various structured programming constructs, but also include a chapter on how to interoperate with C and Python code.

Raspbian is a 32-bit operating system as older Raspberry Pi’s and the Raspberry Pi Zero can only run 32-bit code. I didn’t want to leave out 64-bit code, as there are 64-bit versions of Linux from other distributions like Ubuntu that are available for the Pi. So I included a chapter on ARM 64-bit Assembly along with guidelines on how to port your 32-bit code to 64-bit. I then included 64-bit versions of several of the programs we had developed along the way.

There is a lot of interest in ARM Assembly Language, especially from hackers, as all phones, tablets and even a few laptops are running ARM processors now. I included a number of hacking related topics like how to reverse engineer code, as security professionals are very interested in this as they work to protect the mobile devices utilized by their organizations.

The ARM Processor is a good example of a RISC processor, so if you are interested in RISC, this book will give a good introduction to the concepts, like how to do everything with instructions that are only 32-bits in length. Once you understand ARM Assembly, picking up the Assembly language of another RISC processor like the Risc-V becomes much easier.

The book also covers how to program the floating point processor included with most ARMs along with the NEON vector processor that is available on newer Raspberry Pis.


If you are interested in learning Assembly Language, please check out my book. The Raspberry Pi provides a great platform to do this. Even if you only program in higher level languages, knowing Assembly Language will help you understand what is going on at a deeper level. How modern processors design their Assembly Language to maximize program performance and minimize memory usage is quite fascinating and I hope you find the topic as interesting as I do.


Written by smist08

November 1, 2019 at 11:22 am

The Race for 64-Bit Raspberry Pi 4 Linux

with 2 comments


When the Raspberry Pi 4 was announced and shipped this past June, it caught everyone by surprise. No one was expecting a new Pi until next year sometime, if we were lucky. The Raspberry Pi 4 has updated faster components, including an updated ARM processor and USB 3.0. Raspbian, the official version version of Linux for the Pi was updated to be based on Debian Buster and shipped before the official Debian Buster actually shipped. However, Raspbian is still 32-bit, where the Raspberry foundation say this is so they only have to support one version of Linux for all Raspberry Pi devices.

Others in the Linux community, have then figured out how to run 64-bit Linux’s on the Raspberry Pi. For instance there are 64-bit versions of Ubuntu Mate, Ubuntu Server and Kali Linux. These work on the Raspberry Pi 3, but due to changes in the Raspberry architecture, didn’t work on the Raspberry Pi 4 when it shipped. We still don’t have official 64-bit releases, but we are reaching the point where the test builds are starting to work quite well.

Why 64-Bit?

To be honest, 64-bit Linux never ran very well on the Raspberry Pi 3. 64-bit Linux and 64-bit programs requires quite a bit more memory than their 32-bit equivalents. Each memory address is now 64-bits instead of 32-bits and there is a tendency to use 64-bit integers rather than 32-bit integers. The ARM processor instructions are 32-bits in both 32-bit and 64-bit mode, so programs tend to be about the same size, though 64-bit doesn’t have use of the 16-bit ARM thumb instructions. The Raspberry Pi 3 is limited to 1Gig of memory, that can just barely run a 64-bit Linux, and tends to run out of memory quickly as you run programs, like web browsers. The Raspberry Pi 4 now supports up to 4Gig of memory and that is sufficient to run 64-bit Linux along with a respectable number of programs. Plus the Raspberry Pi 4 has faster access to the SDCard and USB 3, so you can attach an even faster external drive, so if you do get swapping, it isn’t as painful.

In spite of these limitations, there are reasons to run 64-bit. The main one is that you can get better performance, especially if you actually need to work with 64-bit integers. Further the 64-bit instruction set has been optimised to work better with the execution pipeline, so you don’t get as many stalls when you perform jumps. For instance in 32-bit ARM, there is no function return instructions, so people use regular branches, pop the return address from the stack directly into the program counter or do a number of other tricks. As a result, function returns causes the execution pipeline to be flushed. In 64-bit, the pipeline knows about return instruction and knows where to get the next few instructions.

If 64-Bit Worked on the Pi 3, What’s the Problem?

If we had 64-bit working for the Pi 3, why doesn’t it just work on the Pi 4? There are a few reasons for this. The first obstacle was that Raspberry changed the whole Pi boot process. The Raspberry Pi 3 booted using the GPU. When it started the Pi 3’s GPU runs a program that knows how to read the boot folder on an SDCard and will load this into memory and then start the ARM CPU to run what it loaded into memory. The Raspberry Pi 4 now has a slightly larger EEPROM, this contains ARM code that executes on startup and then loads a further step from the SDCard. The volunteers with the other Linux distributions had to figure out this new process and adapt their code to fit into it. Sadly, the original EEPROM program didn’t provide a good way to do this, so the Linux volunteers have been working with Raspberry to get the support they need in newer versions of the EEPROM software. The most recent version seems to be working reliably finally.

The Raspberry Pi 4 then has all new hardware, so new drivers are required for bluetooth, wifi and everything else. To keep the price down, Raspberry uses older standard components, so there are drivers already written for all these devices. It’s just a matter of including the correct drivers and providing default configurations that work and settings dialogs if anything might need user input. This is all being worked on in parallel, and the consensus is that we are already in a better place than we were for the Pi 3.

It’s All Open Source so Why not Copy from Rasbian?

The Raspbian kernel is open source so anyone can look at that source code, but the EEPROM firmware is not open source. This can be reverse engineered, but that takes time. The Raspberry Pi foundation has been quite helpful in supporting people, but that is no substitute for reading the source code. This again shows the importance of open source BIOS.

Development got off to a slow start, because the Raspberry Pi foundation didn’t give anyone a heads up that this was coming. The developers of Ubuntu Mate had to order their Raspberry Pi 4’s just like everyone else when the announcement happened. This meant no one really got started until into July.

In spite of claiming up and down that they will never produce a 64-bit version of Raspbian, the Raspberry Pi foundation has produced a test Raspbian 64-bit Linux kernel. This then tests out that the Raspberry Pi firmware will support 64-bits and that all the device drivers are available. I couldn’t get this kernel to work, but it is proving very helpful for other developers. It also makes people excited that maybe Raspbian will go 64-bit sooner than later.

How Are We Doing?

The first distribution to get all this going is Gentoo Linux. They have a very smart developer Sakaki who provided the first image that actually worked. This then led to Arch and Majaro Linux releases based on Gentoo. This was a good first step, though these distributions are more for the DIY crowd due to their preference to always installing software from source code.

Next James Chambers put together a guide and images to allow you to install Ubuntu Server 64-bit on the Pi 4. Ubuntu Server is character based, but installing a desktop is no problem. The main limitation of this release is that you need a hardwired Internet connection to start. You can’t start with Wifi as the Wifi software isn’t installed with the base image. If you do have a wired Internet connection, getting it installed and installing the desktop is quite straightforward and works well. Once you have the desktop installed, then you can configure Wifi and ditch the ethernet cable.

The changes required for the Raspberry Pi 4 are being submitted to the standard Linux kernel for version 5.4. When this ships it will have available drivers for the Pi 4 hardware and official support for the Broadcom chips used in the Pi. Version 5.3 of the Linux kernel just shipped and added support for the NVidia Jetson Nano. Hopefully the wait for Linux 5.4 won’t be too long.


I’ve been running the 64-bit version of Ubuntu Linux Server, with the Xubuntu desktop for a few days now and it works really well on my Raspberry Pi 4 with 4Gig of RAM. Performance is great and everything is working. I’ve installed various software, including CubicSDR which works great. This is the first time I’ve been happy with Software Defined Radio running on a Pi.

I look forward to the official releases, and given the state of the current builds, think we are getting quite close.

Written by smist08

September 20, 2019 at 6:38 pm

Raspberry Pi 4 as a Desktop Computer

leave a comment »


The Raspberry Pi Foundation is promoting the Raspberry Pi 4 as a full desktop computer for only $35. I’ve had my Raspberry Pi 4 for about a month now and in this article we’ll discuss if it really is a full desktop computer replacement. This partly depends on what you use your desktop computer for. My answer is that the $35 price is misleading, you need to add quite a few other things to make it work well.

Making the Raspberry Pi 4 into a Decent Desktop

The Raspberry Pi has always been a barebones computer. You’ve always needed to add a case, a keyboard, a mouse, a monitor, a power supply, a video cable and a microSD card. Many people already have these kicking around, so they don’t need to buy them when they get their Pi. For instance, I already had a keyboard and monitor. The Raspberry Pi 4 even supports two monitors.

Beyond the bare bones, you need two more things for a decent desktop, namely:

  1. The 4GB version of the Raspberry Pi 4
  2. A good USB SSD drive

With these, it starts to feel like you are playing with a regular desktop computer. You now have enough RAM to run multiple programs and any good SSD will greatly enhance the performance of thee system, only using the microSD card to boot the Pi.

The Raspberry Pi 3 is a great little computer. Its main limitation is that if you run too many programs or open too many browser tabs, it bogs down and you have a painful process of closing windows (that aren’t responding well), until things pick up again. Now the Raspberry Pi 4 with 4GB of RAM really opens up the number of things you can do at once. Running multiple browser tabs, LibreOffice and a programming IDE are no problem.

The next thing you run into with the Raspberry Pi 4 is the performance of the SD card. Since I needed a video cable and a new case, I ordered a package deal that also included a microSD card containing Raspbian. Sadly, these bundled microSD cards are the cheapest, and hence slowest available. Having Raspbian bundled on a slow card is just a waste. Switching to a Sandisk Extreme 64GB made a huge difference. The speed was much better. When buying a microSD card watch the speed ratings, often the bigger cards (64GB or better) are twice as fast as the smaller cards (32GB or less). With a good microSD card the Raspberry Pi 4 can read and write microSD twice as fast as a Raspberry Pi 3.

I’ve never felt I could truly trust running off a microSD card. I’ve never had one fail, but people report problems all the time. Further, the performance of microSD cards is only a fraction of what you can get from good SSDs. The Raspberry Pi 4 comes with two USB 3 ports which have a theoretical performance ten times that of the microSD port. If you shop around you will find M.2 and SATA SSDs for prices less than those of microSD cards. I purchased a Kingston A1000 M.2 drive which was on sale cheap because the A2000 cards just started shipping. I had to get an M.2 USB caddy to contain it, but combined this was less than $100 and USB caddies are always useful.

Unfortunately, you can’t boot the Raspberry Pi 4 directly off a USB port yet. The Raspberry Pi foundation say this is coming, but not quite here yet. What you can do is have the entire root file system on the USB drive, but the boot partition must be on a microSD card. Setting up the SSD was easier than I thought it would be. I had to partition it, format it, copy everything over to the SSD and then edit /boot/config.txt to say where the root of the main file system is.

With this done, I feel like I’m using a real desktop computer. I’m confident my data is being stored reliably, the performance is great.


The Raspberry Pi 4 uses more power than previous Pis. This means there is more heat to dissipate. The case I received with my Pi 4 didn’t have any ventilation holes and would get quite hot. I solved the problem by removing the top of the case. This let enough heat out that I could run fine for most things. People report that when using a USB SSD that the USB controller chip will overheat and the data throughput will be throttled. I haven’t run into this, but it is something to be aware of.

I installed Tensorflow, Google’s open source AI toolkit. Training a data model with Tensorflow does make my Pi 4 overheat. I suspect Tensorflow is keeping all four CPU cores busy and producing a maximum amount of heat. This might drive me to add a cooling fan. I like the way the Pi runs so quietly, with no fan, it makes no noise. I might try using a small fan blowing down on the Pi to see is that helps.


Is the Raspberry Pi 4 a complete desktop computer for $35? No. But if you get the 4GB model for $55 and then add a USB 3 SSD, then you do have a good workable desktop computer. The CPU power of the Pi has been compared to a typical 2012 desktop computer. But for the cost that is pretty good. I suspect the Wifi/Lan and SSD are quite a bit better than that 2012 computer.

Keep in mind the Raspberry Pi runs Linux, which isn’t for everyone. A typical low cost Windows desktop goes for around $500 these days. You can get a refurbished one for $200-$300. A refurbished desktop can be a good inexpensive option.

I like the Raspberry Pi, partly because you are cleanly out of the WinTel world. No Windows, no Intel. The processor is ARM and the operating system is Raspbian based on Debian Linux. A lot of things you do are DIY, but I enjoy that. With over 25 million Raspberry Pis sold worldwide, there is a lot of community support and you join quite an enthusiastic thriving group.

Written by smist08

August 26, 2019 at 8:17 pm

Raspberry Pi 4 First Impressions

leave a comment »


I’ve received my Raspberry Pi 4B with 4GB or RAM a few weeks ago. I’ve been using it to write my forthcoming book on Raspberry Pi Assembly Language Programming, so I thought I’d give a few of my first impressions. The biggest change for the Raspberry Pi 4 is the support for three memory sizes, 1GB, 2GB and 4GB. This overcomes the biggest complaint against the Raspberry Pi 3, that it bogs down too quickly as you run browser tabs and multiple windows.

Some of the other hardware improvements are:

  • Dual 4K monitor support with dual micro-HDMI ports.
  • Two of the four USB ports are USB-3.
  • The ethernet is now gigabit and the WiFi is faster.
  • A 1.5GHz quad-core 64-bit ARM Cortex-A72 CPU.
  • The SDRAM is now LPDDR4.
  • The GPU is upgraded to Broadcom’s VideoCore VI.
  • Hardware HEVC video support for 4Kp60 video.

On paper, this makes the Raspberry Pi 4 appear far superior to its predecessors, In this article, I’ll discuss what is much better and a few of the drawbacks. This release will squash a lot of the compatible Pi competitors, but I’ll compare it to my NVidia Jetson Nano and mention a few places where these products still surpass the Pi.

Raspbian Buster

At the same time the Raspberry Pi Foundation released the Raspberry Pi 4, they also released the new “Buster” version of Raspbian, the Debian Linux derived operating system tailored specifically to the Raspberry Pi. On the day this was announced, I ordered my Raspberry Pi 4, then went and downloaded the new Buster release, then installed it on my Raspberry Pi 3B.

If you have a Raspberry Pi 4, then you must run the Buster release as older versions of Raspbian don’t have support for the newer hardware. If you are running an older Pi then you can keep running the older version or upgrade as you like.

Is it 64-Bits?

The first rumour that was squashed was that Raspbian would move to 64-bits. This didn’t happen. Raspbian is a 32-bit operating system. The Raspberry Pi Foundation says it will stay this way for the foreseeable future. The first reason is that the Raspberry Pi 1 and Raspberry Pi Zero use a much older ARM processor that doesn’t support 64-bits. The Raspberry Pi Foundation still supports and sells these models and they are quite popular due to their low price. They don’t want to support two operating systems, so they stick to one 32-bit version that will run on every Raspberry Pi ever made. Perhaps other hardware vendors should look at this level of support for older models.

Even though 32-bit implies a 32-bit virtual address space for processes, which limits an individual process to 4GB of memory, the ARM SoC used in the Pi has memory access hardware for 48-bit addresses. This allows the operating system to give each process a different 4GB address space, so if Raspberry Pi models with more than 4GB of memory are released, Raspbian can utilize this memory.

Another problem with going to 64-bits is that all the previous Raspberry Pi models, and one version of the Raspberry Pi 4 only have 1GB of RAM. This isn’t sufficient to run a 64-bit operating system. You can do it, but the operating system takes all the RAM, and once you run a program or two, everything bogs down. This is due to all addresses and most integers becoming 64-bits, and hence twice as large. A definite nice feature of Raspbian is that it can run effectively in only 1GB or memory.

Based on Debian Buster

Raspbian is notorious for lagging behind the mainstream releases of Linux. The benefit of this is that Raspbian has always been very stable and reliable. It works well and avoids the problems that happen at the bleeding edge. The downside is that it can contain security vulnerabilities or bugs that are fixed in the newer versions.

With Buster, Raspbian released its version ahead of Debian releasing the main version. Linus Torvalds himself was involved in moving the Pi up to a newer version of the Linux kernel. His concern is that as other hardware platforms adopt proprietary software like UEFI firmware, with government mandated backdoors, that the benefits of open source are being lost. The Raspberry Pi, including its firmware are all open source and there is a feeling in the open source community that this is the future to fight for.

Some Software Not Ported Yet

As a result of the move to Buster, some software that Raspberry users are accustomed to is missing. The most notable case is Mathematica. A port of this is underway and it is promised to be included in a future upgrade.

I had problems with CubicSDR, a Software Defined Radio (SDR) program. It could detect my SDR USB device, but didn’t run properly, just displaying a blank screen when receiving.

Heat Dissipation

The Raspberry Pi 4 uses more power than previous models. It requires a USB-C power adapter which means you can’t use a power adapter from previous models. I bought my Pi 4 from and got the bundle with a case, power adapter, heat sinks and micro-HDMI cable. I needed the cables. The case is their Raspberry Pi 3 case, with the holes for the cables moved for the slightly different Pi 4 configuration. The case lacked any ventilation holes and the Pi would throttle due to overheating fairly easily. My solution was to run it with the top of the case removed. This seems to provide enough air circulation that I haven’t seen any overheating since.

Some people claim the Raspberry Pi 4 requires a fan for cooling, but that hasn’t been my experience. I think the cases need properly thought out ventilation and that is all that is needed. I think a bigger heatsink like the one included with the NVidia Jetson Nano would be warranted as well. I don’t like fans and consider the quietness of the Pi as one of its biggest features.


All this sounds great, but what are the downsides of the Raspberry Pi 4?

All New Cables

I purchased an NVidia Jetson Nano and to run it, I just unplugged the cables from my Raspberry Pi 3 and plugged them into the Jetson and away it went. Not new cables required.

The Raspberry Pi required a new USB-C power supply and a lot has been made of how you can’t use Apple laptop power supplies, but I think the real issue is you can’t use an older Pi power supply, even if it can provide sufficient power.

To support dual monitors, the Pi went to micro-HDMI ports to fit both connectors. This means you need either new cables or at least micro- to regular-HDMI adapters. The NVidia Jetson supports dual monitors but annoyingly with two different cables, HDMI and a DisplayPort cable. At least the cables are the same for the two video ports.

Otherwise all my USB devices that I was using with the Raspberry Pi 3 seem to work with the Pi 4.

SDCard Bottleneck

They have improved the data transfer speed to and from the microSD card with the Pi 4, but this is still a bottleneck. I would have loved it if they had added a M.2 SSD interface to the board. You can improve on the microSD card speed by using a USB 3 external SSD. The problem is that you can’t boot from this USB 3 drive. You can copy the root filesystem over to the drive and run mostly from the USB and although I haven’t tried it yet, people report this is an improvement.

Raspberry Pi promote the 4 as a desktop computer replacement and it definitely has the processing power. However, I don’t think this really holds up without something better than running off a microSD card. The Raspberry Pi Foundation say they will add boot from USB support in a future firmware update, but it isn’t there yet. Although the speed of USB 3 is better than the microSD interface, it still isn’t nearly as good as you can obtain with M.2 and a good new SSD.

No 64-Bits Yet

The Raspberry Pi Foundation, caught everyone by surprise with their release. This included the people that maintain alternate operating systems for the Raspberry Pi. There is a good Ubuntu Mate 64-bit version that runs on the Raspberry Pi 3. It is slow and you can’t run many programs, but it does work and you can experiment with things like ARM 64-bit Assembly programming.

The person that maintains this had to order his Raspberry Pi 4, like everyone else and hasn’t produced a Pi 4 version yet. It would have been nice if the Raspberry Pi Foundation had seeded some early models to the people that develop alternate operating systems for the Pi.

As of this writing, Raspbian is the only operating system that runs on the Raspberry Pi, but hopefully the others won’t take too long to modify what they need to.

The Raspberry Pi 4 with 4GB is the first Raspberry Pi that has the power to run a true 64-bit operating system, so it would be nice to play with.


The Raspberry Pi 4 is still dirt cheap, $35 for the 1GB model and $55 for the 4Gig model. This upgrade is a bit more expensive since you need a new power adapter, new video cables and a new case as well. I think the extra $20 for the extra memory is well worth it.

Compared to the NVidia Jetson Nano

The Raspberry Pi 4 blows most of the current crop of Pi clones out of the water. One exception is the NVidia Jetson Nano. This single board computer has 4GB of memory and runs full 64-bit Ubuntu Linux and as a consequence feels more powerful than the Pi 4.

The Pi 4 has a more powerful ARM CPU, but the Jetson has 4 USB-C ports and a 128 core CUDA GPU. The CUDA GPU is used by software like CubicSDR for DSP like processing, along with most AI toolkits like Tensorflow.

The NVidia Jetson costs $99, so is nearly twice as expensive as a Pi 4. However if you want to experiment with AI, the 128-core CUDA GPU is an excellent entry level system. 


I got used to the Raspberry Pi 4 fairly quickly and after a couple of weeks thought it was pretty similar to the Raspberry Pi 3. I then needed to do something on my Raspberry 3 and booted it up. After using the Pi 4, going back to the Pi 3, felt like I was working in molasses, everything was so slow. This is a real testament to how good the new Pi is, especially with 4GB of memory.

Yes, there are some teething problems with the new model, as there often is at the bleeding edge. But overall the Raspberry Pi 4 is a solid upgrade, and once you adopt it, you really can’t go back. 


Written by smist08

August 2, 2019 at 7:09 pm

Can NVidia Bake a Better Pi Than Raspberry?

with 4 comments


I love my Raspberry Pi, but I find it’s limited 1Gig of RAM can be quite restricting. It is still pretty amazing what you can do with these $35 computers. I was disappointed when the Raspberry Foundation announced that the Raspberry Pi 4 is still over a year away, so I started to look at Raspberry Pi alternatives. I wanted something with 4Gig of RAM and a faster ARM processor. I was considering purchasing an Odroid N2, when I saw the press release from NVidia’s Developer Conference that they just released their NVidia Jetson Nano Developer Kit. This board has a faster ARM A57 quad core processor, 4 Gig of RAM plus the bonus of a 128 core Maxwell GPU. The claim being that this is an ideal DIY computer for those interested in AI and machine learning (i.e. me). It showed up for sale on, so I bought one and received it via FedEx in 2 days.


If you already have a Raspberry Pi, setup is easy, since you can unplug things from the Pi and plug them into the Nano, namely the power supply, keyboard, monitor and mouse. Like the Pi, the Nano runs from a microSD card, so I reformatted one of my Pi cards to a download of the variant of Ubuntu Linux that NVidia provides for these. Once the operating system was burned to the microSD card, I plugged it into the Nano and away I went.

One difference from the Pi is that the Nano does not have built in Wifi or Bluetooth. Fortunately the room I’m setting this up in has a wired Internet port, so I went into the garage and found a long Internet cable in my box of random cables, plugged it in and was all connected to the Internet. You can plug a USB Wifi dongle in if you need Wifi, or there is an M.2 E slot (which is hard to access) for an M.2 Wifi card. Just be careful of compatibility, since the drivers need to be compiled for ARM64 Linux.

The board doesn’t come with a case, but the box folds into a stand to hold the board. For now that is how I’m running. If they sell enough of these, I’m sure cases will appear, but you will need to ensure there is enough ventilation for the huge heat sink.

Initial Impressions

The Jetson Nano certainly feels faster than the Raspberry Pi. This is all helped by the faster ARM processor, the quadrupled memory, using the GPU cores for graphics acceleration and that the version of Linux is 64 Bit (unlike Raspbian which is 32 Bit). It ran the pre installed Chromium Browser quite well.

As I installed more software, I found that writing large amounts of data to the microSD card can be a real bottleneck, and I would often have to wait for it to catch up. This is more pronounced than on the Pi, probably because other things are quite slow as well. It would be nice if there was an M.2 M interface for an NVMe SSD drive, but there isn’t. I ordered a faster microSD card (over three times faster than what I have) and hope that helps. I can also try putting some things on a USB SSD, but again this isn’t the fastest.

I tried running the TensorFlow MNIST tutorial program. The version of TensorFlow for this is 1.11. If I want to try TensorFlow 2.0, I’ll have to compile it myself for ARM64, which I haven’t attempted yet. Anyway, TensorFlow automatically used the GPU and executed the tutorial orders of magnitude faster than the Pi (a few minutes versus several hours). So I was impressed with that.

This showed up another gotcha. The GPU cores and CPU share the same memory. So when TensorFlow used the GPU, that took a lot of memory away from the CPU. I was running the tutorial in a Jupyter notebook running locally, so that meant I was running a web server, Chromium, Python, and then TensorFlow with bits on the CPU and GPU. This tended to use up all memory and then things would grind to a halt until garbage collection sorted things out. Running from scratch was fine, but running iteratively felt like it kept hitting a wall. I think the lesson here is that to do machine learning training on this board, I really have to use a lighter Python environment than Jupyter.

The documentation mentions a utility to control the processor speeds of the ARM cores and GPU cores, so you can tune the heat produced. I think this is more for if you embed the board inside something, but beware this sucker can run hot if you keep all the various processors busy.

How is it so Cheap?

The NVidia Jetson Nano costs $99 USD. The Odroid is $79 so it is fairly competitive with other boards trying to be super-Pis. However, it is cheaper than pretty much any NVidia graphics card and even their Nano compute board (which has no ports and costs $129 in quantities of 1000).

The obvious cost saving is no Wifi and no bluetooth. Another is the lack of a SATA or M.2 M interface. It does have a camera interface, a serial interface and a Pi like GPIO block.

The Nano has 128 Maxwell GPU cores. Sounds impressive, but remember most graphics cards have 700 to 4000 cores. Further Maxwell is the oldest supported platform (version 5) where as the newest is the version 7 Volta core.

I think NVidia is keeping the cost low, to get the DIY crowd using their technologies, they’ve seen the success of the Raspberry Pi community and want to duplicate it for their various processor boards. I also think they want to be in the ARM board game, so as better ARM processors come out, they might hope to supplant Intel in producing motherboards for desktop and laptop computers.


If the Raspberry Pi 4 team can produce something like this for $35 they will have a real winner. I’m enjoying playing with the board and learning what it can do. So far I’ve been pretty impressed. There are some limitations, but given the $100 price tag, I don’t think you can lose. You can play with parallel processing with the GPU cores, you can interface to robots with the GPIO pins, or play with object recognition via the camera interface.

For an DIY board, there are a lot of projects you can take on.


Playing with Julia 1.0 on the Raspberry Pi

with 2 comments


A couple of weeks ago I saw the press release about the release of version 1.0 of the Julia programming language and thought I’d check it out. I saw it was available for the Raspberry Pi, so I booted up my Pi and installed it. Julia has been in development since 2012, it was created by four MIT professors as an open source project for mathematical computing.

Why Julia?

Most people doing data science and numerical computing use the Python or R languages. Both of these are open source languages with huge followings. All new machine learning projects need to integrate to these to get anywhere. Both are very productive environments, so why do we need a new one? The main complaint about Python and R is that these are interpreted languages and as a result are very slow when compared to compiled languages like C. They both get around this by supporting large libraries of optimized code written in C, C++, Assembler and Fortran to give highly optimized off the shelf algorithms. These work great, but if one of these doesn’t apply and you need to write Python loops to process a large data set then it can get really frustrating. Another frustration with Python is that it doesn’t have a built in array data type and relies on the numpy and pandas libraries. Between these you can do a lot, but there are holes and strange differences between the two systems.

Julia has a powerful builtin array type and most of the array manipulation features of numpy and pandas are built in to the core language. Further Julia was created from scratch around powerful new just in time (JIT) compiler technology to provide both the speed of development of an interpreted language combined with the speed of a compiled language. You don’t get the full speed of C, but it’s close and a lot better than Python.

The Julia language borrows a lot of features from Python and I find programming in it quite similar. There are tuples, sets, dictionaries and comprehensions. Functions can return multiple values. For loops work very similarly to Python with ranges (using the : built into the language rather than the range() function).

Julia can call C functions directly (meaning you can get pointers to objects), and this allows many wrapper objects to have been created for other systems such as TensorFlow. This is why Julia is very precise about the physical representation of data types and the ability to get a pointer to any data.

Julia uses the end keyword to terminate blocks of code, rather than Pythons forced indentation or C’s semicolons. You can use semicolons to have multiple statements on one line, but don’t need them at the end of a line unless you want it to return null.

Julia has native built in support of most numeric data types including complex numbers and rational numbers. It has types for all the common hardware supported ints and floats. Then it also has arbitrary precision types build around GNU’s bignum library.

There are currently 1906 registered Julia packages and you can see the emphasis on scientific computing, along with machine learning and data science.

The creators of Julia always keep performance at the top of mind. As a result the parallelization support is exceptional along with the ability to run Julia code on CUDA NVidia graphics cards and easily setup clusters.

Is Julia Ready for Prime Time?

As of the time of this writing, the core Julia 1.0 language has been released and looks quite good. Many companies have produced impressive working systems with the 0.x versions of Julia. However right now there are a few problems.

  • Although Julia 1.0 has been released, most of the add on packages haven’t been upgraded to this version yet. In the first release you need to add the Pkg package to add other packages to discourage people using them yet. For instance the library with GPIO support for the Pi is still at version 0.6 and if you add it to 1.0 you get a syntax error in the include file.
  • They have released the binaries for all the versions of Julia, but these haven’t made them into the various package management systems yet. So for instance if you do “sudo apt install julia” on a Raspberry Pi, you still get version 0.6.

Hopefully these problems will be sorted out fairly quickly and are just a result of being too close to the bleeding edge.

I was able to get Julia 1.0 going on my Raspberry Pi by downloading the ARM32 files from Julia’s website and then manually copying them over the 0.6 release. Certainly 1.0 works much better than 0.6 (which segmentation faults pretty much every time you have a syntax error). Hopefully they update Raspbian’s apt repository shortly.

Julia for Machine Learning

There is a TensorFlow.jl wrapper to use Google’s TensorFlow. However the Julia group put out a white paper dissing the TensorFlow approach. Essentially TensorFlow is a separate programming language that you use from another programming language like Python. This results in a lot of duplication and forces the programmer to operate in two different paradigms at once. To solve this problem, Julia has the Flux machine learning system built natively in Julia. This is a fairly powerful machine learning system that is really easy to use, reducing the learning curve to getting working models. Hopefully I’ll write a bit more about Flux in a future article.


Julia 1.0 looks really promising. I think in a month or so all the add-on packages should be updated to the 1.0 level and all the binaries should make it out to the various package distribution repositories. In the meantime, it’s a good time to learn Julia and you can accomplish a lot with the core language.

I was planning to publish a version of my LED flashing light program in Julia, but with the PiGPIO package not updated to 1.0 yet, this will have to wait for a future article.


Written by smist08

August 31, 2018 at 7:34 pm