Installing VS Code

The first step is to get VS Code itself installed if you don’t have it already. You can download the installer for the latest version (1.63.2 at the time of writing) from code.visualstudio.com – it’s a 78 MB download. VS Code has an updater built in so once it’s installed you won’t need to download a new installer to update it. You can use the default options, just making sure that the option to Add to PATH is ticked, as well as the option to Create a desktop icon if you want one.

Installing a compiler (MSYS2)

C is a compiled language, so needs a compiler to convert human-readable C code into machine code that can be run by your PC. A recommended compiler package is MSYS2, downloadable from msys2.org. Scroll down the page slightly to find the installer link under the Installation heading. The latest version as of writing, msys2-x86-64-20211130, is a 98.3 MB download.

Use the default options for the install and leave the option to Run MSYS2 64-bit now ticked on the final page so an MSYS2 terminal window opens when the installer closes. This is because the installer doesn’t actually install everything we need and we’ll need to run a couple of commands to finish the setup. These commands can be found further down the installation page from where we downloaded the installer, but I’m repeating them here so the full set of instructions is in one place.

Firstly, run pacman -Syu. This will upgrade MSYS2’s packages. After a few seconds of synchronising databases and starting the core upgrade, you will be prompted for confirmation to continue. Press y then enter to proceed. After a few seconds of installing the packages, confirm again and the terminal will close.

Open up a new MSYS2 terminal by either going to C:\msys64 and running msys2.exe, or by pressing the Windows key and typing msys2 to run the MSYS2 app. Run pacman -Su (note it’s -Su this time rather than -Syu previously). You’ll need to do another confirmation to proceed and the command will complete after about a minute.

At this point, the compiler itself, GCC (GNU Compiler Collection), isn’t actually installed – this is the final step for MSYS2. Run pacman -S --needed base-devel mingw-w64-x86_64-toolchain. This will install GCC, as well as the debugger (GDB) and various other tools. When prompted to enter a selection, press enter twice to accept the default of all packages, then press y and enter to confirm the 190 MB download and installation of 95 packages. The installation will take around four minutes depending on your internet and PC speed.

We have now fully setup MSYS2. You can check the installation by looking in the C:\msys64\mingw64\bin folder – if the installation was successful there should be quite a few files in this folder, including gcc.exe, the compiler executable. You can also run gcc --version in command prompt to confirm GCC has installed. It’s worth taking a note of the above directory – we’ll be using it later to finish setting up VS Code.

Setting up extensions

At this point, you have everything you need for a very bare bones C/VS Code setup. However, this would require using the terminal to compile and run your code, rather than a run button in VS Code’s graphical user interface (GUI). You also wouldn’t be able to use VS Code’s IntelliSense feature to suggest code elements or to check your code for errors. The following extensions give a much easier user experience, but if you have already installed VS Code on another computer and are logged in with your Microsoft account, they will automatically install on other machines when VS Code first opens.

To install the extensions, open VS Code then either press Ctrl + Shift + X or click the icon on the left that looks like three squares with a fourth next to them. This will open the extensions pane.

In the box at the top, first search for C/C++. The extension just called C/C++ is the one you want, but the C/C++ Themes and Extension Pack extensions are optional extras. Click the blue install button just below the extension name. The C/C++ extension adds IntelliSense and debugging.

Next, search for Code Runner. Installing this will add a run button to the top right of the VS Code window, allowing you to run C files without manually compiling first.

Test the installation

Finally, let’s create and run a simple program to test the installation. On the left hand side of VS Code, at the top of the panel with the extensions icon, click the explorer icon. Right click in the empty space that appears, select New File and call it Hello_world.c. Then copy in the below code:

#include <stdio.h>
int main(){
    printf("Hello, World!");
    return 0;
}

Click the triangular Run button in the top right of VS Code. This will compile the code into an executable file (.exe) then run the executable, printing “Hello, World!” in the output window. If this has worked, you’ve successfully setup C in VS Code. If you have any problems, leave a comment below and I’ll try to help.

For more tutorials and programming experiments, you can subscribe to my newsletter.

Generating random numbers

Looking down the extensive list of peripherals, I came across the True Random Number Generator (TRNG). This seems to be a relatively rare feature for a microcontroller – I haven’t seen any others with one – and it struck me that it should be fairly simple to get going because it shouldn’t need to interface with too many other peripherals or central parts of the chip. Indeed, reading its description revealed it just need a clock source from the Main Clock (MCLK) and an interrupt setting up and I’d be ready to go. This involved setting three registers in total: the first to send the MCLK to the TRNG, the second to enable the TRNG and the third to enable interrupts from the TRNG when a new random number is available.

So how do you actually change register values? While there are a few different variations of the syntax you can use (explained well in this Arduino forum post), I opted for the following:

[PERIPHERAL]->[REGISTER].bit.[BIT]=1

The peripheral part is the name of the particular module within the chip that you’re controlling, so MCLK or TRNG in this case. These names often match the abbreviations used in the datasheet, and are defined by header (.h) files buried deep within the Arduino folder structure. These translate memory addresses and offsets for the particular chip into names we can use to make the code a lot more readable. Putting this all together, the three instructions I needed to use were MCLK->APBCMASK.bit.TRNG_=1, TRNG->CTRLA.bit.ENABLE=1 and TRNG->INTENSET.bit.DATARDY=1.

Note that when using the MCLK module, the bit name (so TRNG in our case) needs to be followed by an underscore (so TRNG_). I’m not exactly sure why this is and it took me a little while of looking through forum posts to work out that it was needed, but the code does compile and run successfully with it.

Working these commands into the wider Arduino program gave the following as the final code:

int rand_num;

void setup() {
  Serial.begin(2000000); // Open serial port with baud of 2Mbps
  while(!Serial);

  MCLK->APBCMASK.bit.TRNG_ = 1; // Enable Main Clock (MCLK) for TRNG

  TRNG->CTRLA.bit.ENABLE = 1; // Enable TRNG
  TRNG->INTENSET.bit.DATARDY = 1; // Enable TRNG interrupt when data ready
  delay(10); // Short delay to allow generation of new random number
}

void loop() {
  rand_num = TRNG->DATA.reg; // Read random number
  if (rand_num==0){ // Data register is zero by default
    Serial.println("TRNG not correctly setup!");
  }
  Serial.println(rand_num, BIN); // Output the number as binary over USB
  delayMicroseconds(200); // wait 200 microseconds to allow PC to catch up
}

Is it truly random?

While the SAMD51’s datasheet states that the TRNG “passes the American NIST Special Publication 800-22 and Diehard Random Tests Suites”, I wanted to confirm its randomness for myself. For this, I wrote a Python program, shown below, to ingest the generated numbers, and parse and plot them. You can see a histogram plot generated from 100,000 samples across 1,000 bins below; the straightness and noisiness of the line demonstrate the numbers’ randomness.

import matplotlib.pyplot as plt
import serial
import numpy as np

arduino = serial.Serial(port='COM3', baudrate=2e6)  # open serial port

number_of_samples = 0
sample_limit = int(1e5)
bins = 1000
sample_set = np.empty([sample_limit + 1], dtype=np.int64)

while number_of_samples <= sample_limit:
    data = str(arduino.readline())  # read in data until a line break character
    sample = int(data[2:len(data) - 5], 2)  # remove leading and line end characters
    sample_set[number_of_samples] = sample
    number_of_samples += 1

plt.figure()
plt.hist(sample_set, bins, histtype='step')
plt.title("Numbers generated by SAMD51 True Random Number Generator, 100,000 samples")
plt.xlabel("Generated number")
plt.xlim([0, 4294967296])
plt.ylabel("Frequency")
plt.show()

If you’d like to stay up to date with my electronics experiments and other projects, don’t forget to subscribe to my newsletter.

You can read my thesis in full by clicking the button below, or you can read all my reports and papers here, including a short paper based on the thesis.

The Wamos Air Boeing 747 took off from the Chinese city at 09:45 local time (01:45 GMT) on Friday, landing at RAF Brize Norton at 13:33. The arrival comes hours after the World Health Organisation declared novel coronavirus a public health emergency of international concern.

Several coaches were used to transport the flight’s passengers upon landing. They will be quarantined at the Arrowe Park Hospital on the Wirral for 14 days.

The UK’s chief medical officer announced on Friday that two cases of coronavirus had now been confirmed in the UK, with the two patients being from the same family.

Nearly 10,000 people have so far been infected in China, with 213 being killed by the disease.

In yesterday’s lesson, I performed the taxied to the runway, performed the takeoff, then once at cruising height learned about trim, power and the use of flaps. I also did most of the approach to landing, with my instructor taking control for the round out once we were about 20 metres or so off the ground.

It was a fantastic lesson to get started and I’m looking forward to my next lesson tomorrow and the rest of my lessons needed to get the 30 hours for my LAPL. I’ll be adding more flying blog posts to the new flying category as I go, so be sure to join me on the journey.

This is something I’ve been looking forward to for about 18 months, since I made the choice to downgrade my MEng at the University of Bath to a BEng and lose a year of the course so I could go do a specialised Master’s elsewhere.

So, join me as I embark on this big adventure. I’ll try to post highlights on my blog, but if you have any questions at any point, wing them my way on Twitter, @weasdown, or by using my contact form.

The conference has two main areas: a set of rooms and auditoria for talks, and a large exhibition hall where companies and organisations setup stands to show off what they do. Talks include a wide range of topics, from space engineering to planetary science, space policy and more. Exhibition stands ranged from small startups like Raptor Aerospace right up to huge multinationals like Lockheed Martin and the European Space Agency.

the UK Space Conference always offers opportunities to discover new companies

I originally planned to attend all three days of the conference, with the first day being dedicated to showcasing my time as a SPINtern at Lockheed Martin and my second day spent volunteering with UKSEDS as one of the conference staff, looking after registration. The third day would then be a free day as a thank you from the organisers for volunteering, but in the end I was too tired to do the final day and had already got everything I wanted out of the conference.

I started day one by putting up my poster about my time at Lockheed Martin. I spent eight weeks at their Harwell office over the summer under the UK Space Agency’s Space Placements In Industry (SPIN) scheme, run by Kathie Bowden. I worked on the design of the Mission Operations Centre for the UK Satellite Launch Programme (UKSLP). This involved determining requirements, liaising with colleagues in the US and partners in the UK, and creating documentation to help both Lockheed staff and satellite operators understand how the MOC will work. It was a really great eight weeks and good fun getting stuck in to some space engineering on a really cutting edge project.

The SPINterns then assembled to each give a two minute presentation on what we had been doing during our eight weeks. Topics ranged from studying Mars’ atmosphere to designing deployable structures for CubeSats, with all of the internships sounding really interesting and valuable for their interns. I was also impressed by the quality of the presentations in front of a group of around 40 interns and visitors.

Later in the day, I presented my poster, with interest mostly coming from the fellow SPINterns but some other visitors also asking me about what I’d been working on. I then spent a few hours exploring the exhibition hall, on the search for interesting companies who could offer me a job after I finish my Master’s at Cranfield University in September 2020. Many of the usual suspects were in attendance, but the UK Space Conference always offers opportunities to discover new companies too. I handed out several business cards and made some useful contacts for my future job search.

A real highlight of day one though was meeting and getting a picture with Tim Peake, the UK’s first European Space Agency astronaut. It was an honour to meet someone who has both taken UK exploration to new heights and inspired a whole generation to take an interest in space.

The first day finished with a plenary, chaired by Prof. Carole Mundell, Chief Scientific Adviser to the Foreign and Commonwealth Office, and with guests Dr. Megan Clark, head of the Australian Space Agency; Johann-Dietrich ‘Jan’ Wörner, Director General of the European Space Agency; Stephen Eisele, Vice President of Business Development at Virgin Orbit; and Wu Yanhua, Vice Administrator of the Chinese National Space Administration. It was really interesting to see such a wide range of organisations represented, and to hear their thoughts on future opportunities and challenges in the space sector.

The first half of day two was spent in the exhibition hall again, visiting companies I hadn’t spoken to the day before. Of particular interest were space debris removal company Astroscale and robotics company MDA, both of which have offices on the Harwell Campus in Oxfordshire. Astroscale’s ELSA-d mission, shown in the video below, will demonstrate spacecraft rendezvous and docking under a variety of conditions as part of their work to provide a space debris de-orbiting service.

In the latter half of the second day, I donned my conference staff T-shirt and volunteered at the registration desk, getting delegates scanned in, pointing them in the direction of talks and exhibition hall, and giving them their complimentary conference bag. It was good to see the conference more from the inside and I was pleased to see that the UKSEDS volunteers and wider staff kept everything running very smoothly.

Overall then, the UK Space Conference was a really valuable opportunity to present my work and to network with a huge range of companies and organisations as part of my job hunt for once I’ve finished my Master’s. Plus I met an amazing astronaut! My only sadness is that the conference is not more affordable for young people – with a student pass being £180 for one day or £360 for all three, I could not have attended if had I not been representing the SPIN programme and volunteering with UKSEDS, and I’m sure this priced out many students from this very useful experience.

You can see that the SAML21 beats the xmega384 in almost every respect, including price. I find it really amazing that you can get an ARM Cortex-M0+ processor for only £4.32 (including VAT). When I discovered Microchip’s range of 32-bit microcontrollers, I was keen to see how they compared to the ATxmega384C3, which sits right at the top end of the AVR lineup. I found, using Microchip’s handy comparison table, that even a relatively low end 32-bit device like the SAML family can go up against the xmega.

The smaller package for the SAM will give me more space on my board for other components and the much lower power consumption will help to give the megaPhone a long battery life. The lower price than that of the xmega is also very welcome to bring down the phone’s overall cost.

Given how complex the code for the megaPhone is likely to become, and given my lack of experience at writing code that doesn’t take much program memory, I wanted to make sure I had plenty of memory in my processor. This is why, when I was choosing the xmega, I went for the 384C3 version with 384kB of Flash program memory. I suspected this to be a bit of an overkill though, so I’m not really worried about reducing this to 256kB in the SAM chip.

Overall then, the ATSAML21G18B is a very worthy replacement for the ATxmega384C3, with better performance and much lower power consumption, in a smaller package and for less than two thirds of the price.

I/O Requirements

The SAML21 family is available in three different package sizes: the L21E series has 32 pins, the G series 48 and the J series 64. So why did I choose the 48-pin G series for this project?

One key aspect of choosing a processor for the megaPhone is making sure it has enough input and output (I/O) pins. To do this, I made a list of all the peripherals it’ll be connecting to, along with how many pins each peripheral needs. These details are shown in the table below.

The SAMD21G18 has 37 pins that can be used for I/O, as shown in the pinout below, so has enough to accommodate the 29 pins needed for the phone’s components.

Development Changes

This change is processor necessitates a change to my work done so far: I need to change the device in my schematic and board layout. This is a relatively small change, particular given that not much had been connected to the xmega, so should only take a day or two.

I’ll also need to familiarise myself with the registers in the new processor, although many of their names are the same as those found in the xmega. I’ll be reacquainting myself with the use of pointers to manipulate registers, with the new processor commonly using 32-bit registers compared to the 8-bit registers found in the old chip.

Breakout Board

So how will this affect my breakout board for the ATxmega384C3? From now on, the breakout board will no longer be on sale, as I will not be using it for development of the megaPhone. However, if you’re particularly interested in buying the parts for a board, send me an email using my contact form and I’ll get back to you regarding cost and getting the parts shipped to you.

I still need something to develop my software on though before I send my PCB to manufacture. The SAMD21 family, which I’ll go into more detail about below, is very similar to the SAML21, so I’ll make use of one of the many breakout boards already available for that range of microcontrollers (such as the mini one from SparkFun). This was another advantage of switching the processor – I can use a known-good board for development so I can be sure that any problems are in my software.

The ATSAML21G18B is very similar to the ATSAMD21G18 used in the SparkFun board and the Arduino Zero, meaning that lots of people will already have developed code for this platform that I can use for debugging if needed. However, I’ll be developing my code in C in Atmel Studio 7.0, avoiding the overhead and extra layer of abstraction produced by using Arduino code.

I did consider using the ATSAMD21G18 for the megaPhone, and this would have made software development very easy by being able to directly transfer it from a development board to the final hardware. However, the SAML21 family adds a power management module, allowing greatly reduced power consumption (for example, using 1.92mA to run a Fibonacci algorithm at 48MHz versus around 4.53mA at 32MHz for the SAMD21) for only a modest increase in price (£4.32 versus £3.12). With long battery life being a primary concern for a mobile device like the megaPhone, I think the extra cost is very justifiable, and I’ll be making good use of the SAML21’s power management capability. The SAML21 is also almost pin compatible with the SAMD21, making porting of code from a SAMD21 breakout board easier.

Naming

One final, but important potential change to the project is its name. The megaPhone is so called because of the xmega processor that was found at its core. Now this has changed to a SAM chip though, I should probably think of a new name. SAMphone’s ok, but I’d love to hear if you have any suggestions for a good name for the project – let me know in the comments below. If there any features you think the phone really needs I’d really love to hear about them in the comments too.

As always, you can find all my posts about the project here on my website and under #megaPhone on Twitter (for now at least and if I decide to stick with the current name). I’m currently working on a requirements document for the phone, which I’ll be releasing on this blog once complete. I have plenty more work to do too though, so see you in the next blog post!

Of course, the bare minimum functionality for a mobile phone is to make phone calls. My aim with this project though is to make a phone with similar functionality to that available in around the year 2000, but with modern components. This means I also need to add SMS messaging, and should consider adding features like a calculator too. Luckily for me, many of these extra little features don’t require any extra hardware: a calculator can be a separate ‘app’, various ringtone options can be stored in the microcontroller’s large memory, and so on.

For the megaPhone then, my hardware just needs to enable calls and texts and some form of user input. In keeping with the design of phone from around 1998 right up to today’s feature phones, the megaPhone will use a candybar form factor. This puts a keypad below a small screen. In the case of the megaPhone, I’ve decided to use a small colour LCD for the screen. The colour display is one of the modern touches that will distinguish the phone from true 2000’s phones. Of course, the use of a keypad rather than a QWERTY keyboard or touchscreen will mean that to send texts, the user will have to use the classic method of multiple button presses to pick the letters in their messages.

Another modern twist in the megaPhone will be the USB Type-C connector for charging. Many phones in the early noughties used barrel connectors for charging, with mini USB being used by some phones like the famous Motorola RAZR V3 later on. I want to make sure though that the user doesn’t have to buy a separate charger, and the reversible nature of Type-C makes it easier to use than mini or micro USB. Using Type-C in the megaPhone will also be good experience for me, so I can use it and its Power Delivery protocol in later projects.

The megaPhone’s body is the area where a high quality design is most important to make the megaPhone the really professional-looking product I hope it to be. I’d love to make the body out of machined aluminium, for its amazing looks and to grow my skills with CNC, but this would require an advanced antenna design to make sure the phone electronics could communicate with the outside world. Instead then, I’ll have to make the body from plastic. This will be 3D printed – for small numbers of units processes like injection moulding are prohibitively expensive, but if there’s sufficient interest in the project I may consider launching a Kickstarter campaign to make injection moulded bodies. 3D printing may be a method mostly associated with the maker community, but that doesn’t mean it can’t produce professional-looking results. I intend to fully utilise the design freedom that 3D printing gives me to design a really attractive and ergonomic body for the megaPhone.

One of the first components I need to choose for the electronics is the module I’ll be using to connect to the phone networks. I have decided to baseline the SIM5320E GSM module for this. This can use 2G and 3G frequencies, meaning I’ll be able to use the megaPhone in the UK, where 2G networks are being phased out. If I find a module that provides more useful functions, I may switch to it down the line, but for now the SIM5320E seems like a good starting point and offers similar functionality to the popular SIM808 module that is often used in hobbyist GSM breakouts.

At the moment then, I’ve chosen which microcontroller and GSM module I’ll be using in the project, and need to choose the rest of the important components like the buck converter that will take the 5V USB input and turn it into 3.3V for the phone electronics. I’ll be updating the blog with my progress as I go, so make sure to keep an eye on my megaPhone page and subscribe to my blog to keep up to date.