Connexion
Les failles de sécurité d'un logiciel DNS largement utilisé pourraient permettre aux attaquants d'envoyer les utilisateurs vers des sites web malveillants ou de détourner à distance leurs appareils.
L'article DNSpooq expose des millions d’appareils à l’empoisonnement de cache DNS a d'abord été publié sur WeLiveSecurity
In the extra special Raspberry Pi Pico launch issue of HackSpace magazine, editor Ben Everard shows you how to get extra levels of brightness out of your LEDs with our new board.
WS2812B LEDs, commonly known as NeoPixels, are cheap and widely available LEDs. They have red, green, and blue LEDs in a single package with a microcontroller that lets you control a whole string of them using just one pin on your microcontroller.
However, they do have a couple of disadvantages:
1) The protocol needed to control them is timing-dependent and often has to be bit-banged.
2) Each colour has 8 bits, so has 255 levels of brightness. However, these aren’t gamma-corrected, so the low levels of brightness have large steps between them. For small projects, we often find ourselves only using the lower levels of brightness, so often only have 10 or 20 usable levels of brightness.
We’re going to look at how two features of Pico help solve these problems. Firstly, Programmable I/O (PIO) lets us implement the control protocol on a state machine rather than the main processing cores. This means that we don’t have to dedicate any processor time to sending the data out. Secondly, having two cores means we can use one of the processing cores to dither the NeoPixels. This means shift them rapidly between different brightness levels to make pseudo-levels of brightness.
For example, if we wanted a brightness level halfway between levels 3 and 4, we’d flick the brightness back and forth between 3 and 4. If we can do this fast enough, our eyes blur this into a single brightness level and we don’t see the flicker. By varying the amount of time at levels 3 and 4, we can make many virtual levels of brightness. While one core is doing this, we still have a processing core completely free to manipulate the data we want to display.
First, we’ll need a PIO program to communicate with the WS2812B LEDs. The Pico development team have provided an example PIO program to work with – you can see the full details here, but we’ll cover the essentials here. The PIO code is:
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 
.program ws2812
.side_set 1
.define public T1 2
.define public T2 5
.define public T3 3
bitloop:
out x, 1. side 0 [T3 - 1]
jmp !x do_zero side 1 [T1 - 1]
do_one:
jmp bitloop side 1 [T2 - 1]
do_zero:
nop side 0 [T2 - 1]We looked at the PIO syntax in the main cover feature, but it’s basically an assembly language for the PIO state machine. The WS2812B protocol uses pulses at a rate of 800kHz, but the length of the pulse determines if a 1 or a 0 is being sent. This code uses jumps to move through the loop to set the timings depending on whether the bit (stored in the register x) is 0 or 1. The T1, T2, and T3 variables hold the timings, so are used to calculate the delays (with 1 taken off as the instruction itself takes one clock cycle). There’s also a section in the pio file that links the PIO code and the C code:
% c-sdk {
#include "hardware/clocks.h"
static inline void ws2812_program_init(PIO pio,
uint sm, uint offset, uint pin, float freq, bool
rgbw) {
pio_gpio_select(pio, pin);
pio_sm_set_consecutive_pindirs(pio, sm, pin, 1,
true);
pio_sm_config c = ws2812_program_get_default_
config(offset);
sm_config_set_sideset_pins(&c, pin);
sm_config_set_out_shift(&c, false, true, rgbw ?
32 : 24);
sm_config_set_fifo_join(&c, PIO_FIFO_JOIN_TX);
int cycles_per_bit = ws2812_T1 + ws2812_T2 +
ws2812_T3;
float div = clock_get_hz(clk_sys) / (freq *
cycles_per_bit);
sm_config_set_clkdiv(&c, div);
pio_sm_init(pio, sm, offset, &c);
pio_sm_set_enable(pio, sm, true);
}
%}Most of this is setting the various PIO options – the full range is detailed in the Raspberry Pi Pico C/C++ SDK document.
sm_config_set_out_shift(&c, false, true, rgbw ? 32
: 24);This line sets up the output shift register which holds each 32 bits of data before it’s moved bit by bit into the PIO state machine. The parameters are the config (that we’re setting up and will use to initialise the state machine); a Boolean value for shifting right or left (false being left); and a Boolean value for autopull which we have set to true. This means that whenever the output shift register falls below a certain threshold (set in the next parameter), the PIO will automatically pull in the next 32 bits of data.
The final parameter is set using the expression rgbw ? 32 : 24. This means that if the variable rgbw is true, the value 32 is passed, otherwise 24 is passed. The rbgw variable is passed into this function when we create the PIO program from our C program and is used to specify whether we’re using an LED strip with four LEDs in each (using one red, one green, one blue, and one white) or three (red, green, and blue).
The PIO hardware works on 32-bit words, so each chunk of data we write with the values we want to send to the LEDs has to be 32 bits long. However, if we’re using RGB LED strips, we actually want to work in 24-bit lengths. By setting autopull to 24, we still pull in 32 bits each time, but once 24 bits have been read, another 32 bits are pulled in which overwrite the remaining 8 bits.
sm_config_set_fifo_join(&c, PIO_FIFO_JOIN_TX);Each state machine has two four-word FIFOs attached to it. These can be used for one going in and one coming out. However, as we only have data going into our state machine, we can join them together to form a single eight-word FIFO using the above line. This gives us a small buffer of time to write data to in order to avoid the state machine running out of data and execution stalling. The following three lines are used to set the speed the state machine runs at:
int cycles_per_bit = ws2812_T1 + ws2812_T2 +
ws2812_T3;
float div = clock_get_hz(clk_sys) / (freq *
cycles_per_bit);
sm_config_clkdiv(&c, div);The WS2812B protocol demands that data is sent out at a rate of 800kHz. However, each bit of data requires a number of state machine cycles. In this case, they’re defined in the variables T1, T2, and T3. If you look back at the original PIO program, you’ll see that these are used in the delays (always with 1 taken off the value because the initial instruction takes one cycle before the delay kicks in). Every loop of the PIO program will take T1 + T2 + T3 cycles. We use these values to calculate the speed we want the state machine to run at, and from there we can work out the divider we need to slow the system clock down to the right speed for the state machine. The final two lines just initialise and enable the state machine.
That’s the code that’s running on the state machine, so let’s now look at the code that’s running on our main processor cores. The full code is on github. Let’s first look at the code running on the second core (we’ll look at how to start this code running shortly), as this controls the light levels of the LEDs.
int bit_depth=12;
const int PIN_TX = 0;
uint pixels[STRING_LEN];
uint errors[STRING_LEN];
static inline void put_pixel(uint32_t pixel_grb) {
pio_sm_put_blocking(pio0, 0, pixel_grb << 8u);
}
static inline uint32_t urgb_u32(uint8_t r, uint8_t
g, uint8_t b) {
return
((uint32_t) (r) << 8) |
((uint32_t) (g) << 16) |
(uint32_t) (b);
}
void ws2812b_core() {
int valuer, valueg, valueb;
int shift = bit_depth-8;
while (1){
for(int i=0; i<STRING_LEN; i++) {
valueb=(pixelsb[i] + errorsb[i]) >> shift;
valuer=(pixelsr[i] + errorsr[i]) >> shift;
valueg=(pixelsg[i] + errorsg[i]) >> shift;
put_pixel(urgb_u32(valuer, valueg, valueb));
errorsb[i] = (pixelsb[i] + errorsb[i]) -
(valueb << shift);
errorsr[i] = (pixelsr[i] + errorsr[i]) -
(valuer << shift);
errorsg[i] = (pixelsg[i] + errorsg[i]) -
(valueg << shift);
}
sleep_us(400);
}
}We start by defining a virtual bit depth. This is how many bits per pixel you can use. Our code will then attempt to create the necessary additional brightness levels. It will run as fast as it can drive the LED strip, but if you try to do too many brightness levels, you’ll start to notice flickering.
We found twelve to be about the best with strings up to around 100 LEDs, but you can experiment with others. Our code works with two arrays – pixels which holds the values that we want to display, and errors which holds the error in what we’ve displayed so far (there are three of each for the different colour channels).
To explain that latter point, let’s take a look at the algorithm for determining how to light the LED. We borrowed this from the source code of Fadecandy by Micah Scott, but it’s a well-used algorithm for calculating error rates. We have an outer while loop that just keeps pushing out data to the LEDs as fast as possible. We don’t care about precise timings and just want as much speed as possible. We then go through each pixel.
The corresponding item in the errors array holds the cumulative amount our LED has been underlit so far compared to what we want it to be. Initially, this will be zero, but with each loop (if there’s a difference between what we want to light the LED and what we can light the LED) this error value will increase. These two numbers (the closest light level and the error) added together give the brightness at the pseudo-level, so we need to bit-shift this by the difference between our virtual level and the 8-bit brightness levels that are available.
This gives us the value for this pixel which we write out. We then need to calculate the new error level. Let’s take a look at what this means in practice. Suppose we want a brightness level halfway between 1 and 2 in the 8-bit levels. To simplify things, we’ll use nine virtual bits. 1 and 2 in 8-bit is 2 and 4 in 9 bits (adding an extra 0 to the end multiplies everything by a power of 2), so halfway between these two is a 9-bit value of 3 (or 11 in binary, which we’ll use from now on).
In the first iteration of our loop, pixels is 11, errors is 0, and shift is 1.
value = 11 >> 1 = 1
errors = 11 – 10 = 1So this time, the brightness level of 1 is written out. The second iteration, we have:
value = 100 >> 1 = 10
errors = 100 – 100 = 0So this time, the brightness level of 10 (in binary, or 2 in base 10) is written out. This time, the errors go back to 0, so we’re in the same position as at the start of the first loop. In this case, the LED will flick between the two brightness levels each loop so you’ll have a brightness half way between the two.
Using this simple algorithm, we can experiment with different virtual bit-depths. The algorithm will always handle the calculations for us, but we just have to see what creates the most pleasing visual effect for the eye. The larger the virtual bit depth, the more potential iterations you have to go through before the error accumulates enough to create a correction, so the more likely you are to see flicker. The biggest blocker to increasing the virtual bit depth is the sleep_us(400). This is needed to reset the LED strip.
Essentially, we throw out bits at 800kHz, and each block of 24 bits is sent, in turn, to the next LED. However, once there’s a long enough pause, everything resets and it goes back to the first LED. How big that pause is can vary. The truth is that a huge proportion of WS2812B LEDs are clones rather than official parts – and even for official parts, the length of the pause needed to reset has changed over the years.
400 microseconds is conservative and should work, but you may be able to get away with less (possibly even as low as 50 microseconds for some LEDs). The urgb_u32 method simply amalgamates the red, blue, and green values into a single 32-bit string (well, a 24-bit string that’s held inside a 32-bit string), and put_pixel sends this to the state machine. The bit shift there is to make sure the data is in the right place so the state machine reads the correct 24 bits from the output shift register.
We’ve now dealt with all the mechanics of the code. The only bit left is to stitch it all together.
int main() {
PIO pio = pio0;
int sm = 0;
uint offset = pio_add_program(pio, &ws2812_
program);
ws2812_program_init(pio, sm, offset, PIN_TX,
1000000, false);
multicore_launch_core1(ws2812b_core);
while (1) {
for (int i = 0; i < 30; ++i) {
pixels[i] = i;
for (int j=0;j<30;++j){
pixels[0] = j;
if(j%8 == 0) { pixels[1] = j; }
sleep_ms(50);
}
for (int j=30;j>0;--j){
pixels[0] = j;
if(j%8 == 0) { pixels[1] = j; }
sleep_ms(50);
}
}
}
}The method ws2812_program_init calls the method created in the PIO program to set everything up. To launch the algorithm creating the virtual bit-depth, we just have to use multicore_launch_core1 to set a function running on the other core. Once that’s done, whatever we put in the pixels array will be reflected as accurately as possible in the WS2812B LEDs. In this case, we simply fade it in and out, but you could do any animation you like.
Would you like a free Raspberry Pi Pico? Subscribe to HackSpace magazine via your preferred option here, and you’ll receive your new microcontroller in the mail before the next issue arrives.
The post NeoPixel dithering with Pico appeared first on Raspberry Pi.
Homebrew is an essential package manager for developers, sysadmins, and power users on macOS. Homebrew allows us to install the latest and updated version of popular applications, packages, and developer tools. Homebrew is the painless way to install required packages on your Mac. For instance, we can install PostgreSQL, Python, PHP, Bash, Nginx, Apache, and much more using brew command. This page explains how to install and use Homebrew on the macOS system to get missing packages. Homebrew installs the apps you need that Apple didn't include in their base operating system or app store.
The post How to install Homebrew on macOS to use the brew package manager appeared first on nixCraft.
I have two columns (fields) in my text file. I am trying to insert '|
FOO This is a description
BAR Another description for bar
TEXT Another description for TEXT
So I ran awk '{ print $1 "|"; $1=""; print}' input > output but print command is adding a new line:
FOO|
This is a description
BAR|
Another description for bar
TEXT|
Another description for TEXT
Is there any way to tell awk not to print a newline and create the file? Here is what I want so that I can create final HTML table based upon '|'
FOO|This is a description
BAR|Another description for bar
TEXT|Another description for TEXT
The post How to force awk not to print a newline appeared first on nixCraft.
Une autre de nos séries occasionnelles démystifiant les chevaux de Troie bancaires latino-américains.
L'article Vadokrist – Un loup dans la bergerie a d'abord été publié sur WeLiveSecurity
Last year, the Raspberry Foundation also released a brand new version of the Raspberry PI PC (personal computer), and it is directly built into a small-sized keyboard. Now there is more good news for hackers and hardware developers. They just announced their first microcontroller-based product named Raspberry Pi Pico. This small device is priced at only US $4. Unbelievable price. Let us find out about Raspberry Pi Pico hardware specs and software support.
The post Raspberry Pi Pico released and available at $4 only appeared first on nixCraft.
Today, we’re launching our first microcontroller-class product: Raspberry Pi Pico. Priced at just $4, it is built on RP2040, a brand-new chip developed right here at Raspberry Pi. Whether you’re looking for a standalone board for deep-embedded development or a companion to your Raspberry Pi computer, or you’re taking your first steps with a microcontroller, this is the board for you.
You can buy your Raspberry Pi Pico today online from one of our Approved Resellers. Or head to your local newsagent, where every copy of this month’s HackSpace magazine comes with a free Pico, as well as plenty of guides and tutorials to help you get started with it. If coronavirus restrictions mean that you can’t get to your newsagent right now, you can grab a subscription and get Pico delivered to your door.
Many of our favourite projects, from cucumber sorters to high altitude balloons, connect Raspberry Pi to the physical world: software running on the Raspberry Pi reads sensors, performs computations, talks to the network, and drives actuators. This ability to bridge the worlds of software and hardware has contributed to the enduring popularity of Raspberry Pi computers, with over 37 million units sold to date.
But there are limits: even in its lowest power mode a Raspberry Pi Zero will consume on the order of 100 milliwatts; Raspberry Pi on its own does not support analogue input; and while it is possible to run “bare metal” software on a Raspberry Pi, software running under a general-purpose operating system like Linux is not well suited to low-latency control of individual I/O pins.
Many hobbyist and industrial applications pair a Raspberry Pi with a microcontroller. The Raspberry Pi takes care of heavyweight computation, network access, and storage, while the microcontroller handles analogue input and low-latency I/O and, sometimes, provides a very low-power standby mode.
Until now, we’ve not been able to figure out a way to make a compelling microcontroller-class product of our own. To make the product we really wanted to make, first we had to learn to make our own chips.
It seems like every fruit company is making its own silicon these days, and we’re no exception. RP2040 builds on the lessons we’ve learned from using other microcontrollers in our products, from the Sense HAT to Raspberry Pi 400. It’s the result of many years of hard work by our in-house chip team.
We had three principal design goals for RP2040: high performance, particularly for integer workloads; flexible I/O, to allow us to talk to almost any external device; and of course, low cost, to eliminate barriers to entry. We ended up with an incredibly powerful little chip, cramming all this into a 7 × 7 mm QFN-56 package containing just two square millimetres of 40 nm silicon. RP2040 has:
And this isn’t just a powerful chip: it’s designed to help you bring every last drop of that power to bear. With six independent banks of RAM, and a fully connected switch at the heart of its bus fabric, you can easily arrange for the cores and DMA engines to run in parallel without contention.
For power users, we provide a complete C SDK, a GCC-based toolchain, and Visual Studio Code integration.
As Cortex-M0+ lacks a floating-point unit, we have commissioned optimised floating-point functions from Mark Owen, author of the popular Qfplib libraries; these are substantially faster than their GCC library equivalents, and are licensed for use on any RP2040-based product.
With two fast cores and and a large amount of on-chip RAM, RP2040 is a great platform for machine learning applications. You can find Pete Warden’s port of Google’s TensorFlow Lite framework here. Look out for more machine learning content over the coming months.
For beginners, and other users who prefer high-level languages, we’ve worked with Damien George, creator of MicroPython, to build a polished port for RP2040; it exposes all of the chip’s hardware features, including our innovative PIO subsystem. And our friend Aivar Annamaa has added RP2040 MicroPython support to the popular Thonny IDE.
Raspberry Pi Pico is designed as our low-cost breakout board for RP2040. It pairs RP2040 with 2MB of Flash memory, and a power supply chip supporting input voltages from 1.8-5.5V. This allows you to power your Pico from a wide variety of sources, including two or three AA cells in series, or a single lithium-ion cell.
Pico provides a single push button, which can be used to enter USB mass-storage mode at boot time and also as a general input, and a single LED. It exposes 26 of the 30 GPIO pins on RP2040, including three of the four analogue inputs, to 0.1”-pitch pads; you can solder headers to these pads or take advantage of their castellated edges to solder Pico directly to a carrier board. Volume customers will be able to buy pre-reeled Pico units: in fact we already supply Pico to our Approved Resellers in this format.
The Pico PCB layout was co-designed with the RP2040 silicon and package, and we’re really pleased with how it turned out: a two-layer PCB with a solid ground plane and a GPIO breakout that “just works”.
Whether Raspberry Pi Pico is your first microcontroller or your fifty-first, we can’t wait to see what you do with it.
Our ambition with RP2040 wasn’t just to produce the best chip, but to support that chip with the best documentation. Alasdair Allan, who joined us a year ago, has overseen a colossal effort on the part of the whole engineering team to document every aspect of the design, with simple, easy-to-understand examples to help you get the most out of your Raspberry Pi Pico.
You can find complete documentation for Raspberry Pi Pico, and for RP2040, its SDK and toolchain, here.
To help you get the most of your Pico, why not grab a copy of Get Started with MicroPython on Raspberry Pi Pico by Gareth Halfacree and our very own Ben Everard. It’s ideal for beginners who are new (or new-ish) to making with microcontrollers.
Our colleagues at the Raspberry Pi Foundation have also produced an educational project to help you get started with Raspberry Pi Pico. You can find it here.
Over the last couple of months, we’ve been working with our friends at Adafruit, Arduino, Pimoroni, and Sparkfun to create accessories for Raspberry Pi Pico, and a variety of other boards built on the RP2040 silicon platform. Here are just a few of the products that are available to buy or pre-order today.
RP2040 joins the hundreds of boards in the Feather ecosystem with the fully featured Feather RP 2040 board. The 2″ × 0.9″ dev board has USB C, Lipoly battery charging, 4MB of QSPI flash memory, a STEMMA QT I2C connector, and an optional SWD debug port. With plenty of GPIO for use with any FeatherWing, and hundreds of Qwiic/QT/Grove sensors that can plug and play, it’s the fast way to get started.
Need a petite dev board for RP2040? The Itsy Bitsy RP 2040 is positively tiny, but it still has lots of GPIO, 4MB of QSPI flash, boot and reset buttons, a built-in RGB NeoPixel, and even a 5V output logic pin, so it’s perfect for NeoPixel projects!
Arduino joins the RP2040 family with one of its most popular formats: the Arduino Nano. The Arduino Nano RP2040 Connect combines the power of RP2040 with high-quality MEMS sensors (a 9-axis IMU and microphone), a highly efficient power section, a powerful WiFi/Bluetooth module, and the ECC608 crypto chip, enabling anybody to create secure IoT applications with this new microcontroller. The Arduino Nano RP2040 Connect will be available for pre-order in the next few weeks.
PicoSystem is a tiny and delightful handheld game-making experience based on RP2040. It comes with a simple and fast software library, plus examples to make your mini-gaming dreams happen. Or just plug it into USB and drop the best creations from the Raspberry Pi-verse straight onto the flash drive.
Pico Explorer offers an embedded electronics environment for educators, engineers, and software people who want to learn hardware with less of the “hard” bit. It offers easy expansion and breakout along with a whole bunch of useful bits.
The Thing Plus – RP2040 is a low-cost, high-performance board with flexible digital interfaces featuring Raspberry Pi’s RP2040 microcontroller. Within the Feather-compatible Thing Plus form factor with 18 GPIO pins, the board offers an SD card slot, 16MB (128Mbit) flash memory, a JST single-cell battery connector (with a charging circuit and fuel gauge sensor), an addressable WS2812 RGB LED, JTAG PTH pins, mounting holes, and a Qwiic connector to add devices from SparkFun’s quick-connect I2C ecosystem.
The MicroMod RP2040 Processor Board is part of SparkFun’s MicroMod modular interface system. The MicroMod M.2 connector makes it easy to connect your RP2040 Processor Board with the MicroMod carrier board that gives you the inputs and outputs you need for your project.
The Pro Micro RP2040 harnesses the capability of RP2040 on a compact development board with the USB functionality that is the hallmark of all SparkFun’s Pro Micro boards. It has a WS2812B addressable LED, boot button, reset button, Qwiic connector, USB-C, and castellated pads.
It’s fair to say we’ve taken the long road to creating Raspberry Pi Pico. Chip development is a complicated business, drawing on the talents of many different people. Here’s an incomplete list of those who have contributed to the RP2040 and Raspberry Pi Pico projects:
Dave Akerman, Sam Alder, Alasdair Allan, Aivar Annamaa, Jonathan Bell, Mike Buffham, Dom Cobley, Steve Cook, Phil Daniell, Russell Davis, Phil Elwell, Ben Everard, Andras Ferencz, Nick Francis, Liam Fraser, Damien George, Richard Gordon, F Trevor Gowen, Gareth Halfacree, David Henly, Kevin Hill, Nick Hollinghurst, Gordon Hollingworth, James Hughes, Tammy Julyan, Jason Julyan, Phil King, Stijn Kuipers, Lestin Liu, Simon Long, Roy Longbottom, Ian Macaulay, Terry Mackown, Simon Martin, Jon Matthews, Nellie McKesson, Rod Oldfield, Mark Owen, Mike Parker, David Plowman, Dominic Plunkett, Graham Sanderson, Andrew Scheller, Serge Schneider, Nathan Seidle, Vinaya Puthur Sekar, Mark Sherlock, Martin Sperl, Mike Stimson, Ha Thach, Roger Thornton, Jonathan Welch, Simon West, Jack Willis, Luke Wren, David Wright.
We’d also like to thank our friends at Sony Pencoed and Sony Inazawa, Microtest, and IMEC for their help in bringing these projects to fruition.
Buy your Raspberry Pi Pico from one of our Approved Resellers today, and let us know what you think!
We hope to make RP2040 broadly available in the second quarter of 2021.
The post Meet Raspberry Silicon: Raspberry Pi Pico now on sale at $4 appeared first on Raspberry Pi.
As you know, Red Hat recently announced that CentOS Linux 8, as a rebuild of RHEL 8, will end in 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux. The news met with a strong reaction from the open-source community and CentOS users. Today, Red Hat released a new option where RHEL developer subscriptions can now be used in production environments. The developers and team can have up to 16 systems. In other words, it is a no-cost RHEL that small groups and developers can use to build packages and in production environments.
The post Red Hat introduces new no-cost RHEL option appeared first on nixCraft.
In this blog post, I’ll discuss the first research seminar in our six-part series about diversity and inclusion. Let’s start by defining our terms. Diversity is any dimension that can be used to differentiate groups and people from one another. This might be, for example, age, gender, socio-economic status, disability, ethnicity, religion, nationality, or sexuality. The aim of inclusion is to embrace all people irrespective of difference.
It’s vital that we are inclusive in computing education, because we need to ensure that everyone can access and learn the empowering and enabling technical skills they need to support all aspects of their lives.
Between January and June of this year, we’re partnering with the Royal Academy of Engineering to host speakers from the UK and USA for a series of six research seminars focused on diversity and inclusion in computing education.
We kicked off the series with a seminar from Dr Peter Kemp and Dr Billy Wong focused on computing education in England’s schools post-14. Peter is a Lecturer in Computing Education at King’s College London, where he leads on initial teacher education in computing. His research areas are digital creativity and digital equity. Billy is an Associate Professor at the Institute of Education, University of Reading. His areas of research are educational identities and inequalities, especially in the context of higher education and STEM education.
Peter began the seminar with a comprehensive look at the history of curriculum change in Computing in England. This was very useful given our very international audience for these seminars, and I will summarise it below. (If you’d like more detail, you can look over the slides from the seminar. Note that these changes refer to England only, as education in the UK is devolved, and England, Northern Ireland, Scotland, and Wales each has a different education system.)
In 2014, England switched from mandatory ICT (Information and Communication Technology) to mandatory Computing (encompassing information technology, computer science, and digital literacy). This shift was complemented by a change in the qualifications for students aged 14–16 and 16–18, where the primary qualifications are GCSEs and A levels respectively:
One of the issues is that in the English education system, there is a narrowing of the curriculum at age 14: students have to choose between Computer Science and other subjects such as Geography, History, Religious Studies, Drama, Music, etc. This means that those students that choose not to take a GCSE Computer Science (CS) may find that their digital education is thereby curtailed from then onwards. Peter’s and Billy’s view is that having a more specialist subject offer for age 14+ (Computer Science as opposed to ICT) means that fewer students take it, and they showed evidence of this from qualifications data. The number of students taking CS at GCSE has risen considerably since its introduction, but it’s not yet at the level of GCSE ICT uptake.
Only 64% of schools in England offer GCSE Computer Science, meaning that just 81% of students have the opportunity to take the subject (some schools also add selection criteria). A higher percentage (90%) of selective grammar schools offer GCSE CS than do comprehensive schools (80%) or independent schools (39%). Peter suggested that this was making Computer Science a “little more elitist” as a subject.
Peter analysed data from England’s National Pupil Database (NPD) to thoroughly investigate the uptake of Computer Science post-14 with respect to the diversity of entrants.
He found that the gender gap for GCSE CS uptake is greater than it was for GCSE ICT. Now girls make up 22% of the cohort for GCSE CS (2020 data), whereas for the ICT qualification (2017 data), 43% of students were female.
Peter’s analysis showed that there is also a lower representation of black students and of students from socio-economically disadvantaged backgrounds in the cohort for GCSE CS. In contrast, students with Chinese ancestry are proportionally more highly represented in the cohort.
Another part of Peter’s analysis related gender data to the Income Deprivation Affecting Children Index (IDACI), which is used as an indicator of the level of poverty in England’s local authority districts. In the graphs below, a higher IDACI decile means more deprivation in an area. Relating gender data of GCSE CS uptake against the IDACI shows that:
Peter covered much more data in the seminar, so do watch the video recording (below) if you want to learn more.
Peter’s analysis shows a lack of equity (i.e. equality of outcome in the form of proportional representation) in uptake of GCSE CS after age 14. It is also important to recognise, however, that England does mandate — not simply provide or offer — Computing for all pupils at both primary and secondary levels; making a subject mandatory is the only way to ensure that we do give access to all pupils.
Billy presented some of the potential reasons for why some groups of young people are not fully represented in GCSE Computer Science:
More research is needed to understand the subject choices young people make and their reasons for choosing as they do.
We also need to look at how the way we teach Computing to students aged 11 to 14 (and younger) affects whether they choose CS as a post-14 subject. Our next seminar revolves around equity-focused teaching practices, such as culturally relevant pedagogy or culturally responsive teaching, and how educators can use them in their CS learning environments.
Meanwhile, our own research project at the Raspberry Pi Foundation, Gender Balance in Computing, investigates particular approaches in school and non-formal learning and how they can impact on gender balance in Computer Science. For an overview of recent research around barriers to gender balance in school computing, look back on the research seminar by Katharine Childs from our team.
Peter and Billy themselves have recently been successful in obtaining funding for a research project to explore female computing performance and subject choice in English schools, a project they will be starting soon!
If you missed the seminar, watch recording here. You can also find Peter and Billy’s presentation slides on our seminars page.
In our next research seminar on Tuesday 2 February at 17:00–18:30 BST / 12:00–13:30 EDT / 9:00–10:30 PDT / 18:00–19:30 CEST, we’ll welcome Prof Tia Madkins (University of Texas at Austin), Dr Nicol R. Howard (University of Redlands), and Shomari Jones (Bellevue School District), who are going to talk to us about culturally responsive pedagogy and equity-focused teaching in K-12 Computer Science. To join this free online seminar, simply sign up with your name and email address.
Once you’ve signed up, we’ll email you the seminar meeting link and instructions for joining. If you attended Peter’s and Billy’s seminar, the link remains the same.
The post Computing education and underrepresentation: the data from England appeared first on Raspberry Pi.
