Since my GSoC project is on putting new functionality on a USB device, changing the device's firmware means understanding how different levels of code work with each other. On this post I will try to provide some of the knowledge I'm gaining around this, how the systems works.
The device is built around an STM32F103TBU6 micro-controller. This features a 32-bit ARM Cortex-M3 core with 128kB of Flash Memory and 20kB of SRAM. The manufacturer provides a set of libraries and documentation around them for several different ways that someone may utilize the micro-controller, from memory allocation or control of built-in timers, to USB interface with a host. In that way the STM32 libraries provide the first basic sets of abstraction, which includes, for example, definitions of useful memory locations, register allocation routines, etc. as regards the lowest level, and on top of that there are different levels of software abstractions, like structures and routines, which enable a developer to be able to handle effectively the operation of the micro-controller.
In our case, the USB communication routines were the ones that really matter. The U2F protocol was built around the notion that cryptographic tokens would be USB devices - at least at first - and in the future the standard will include other types of communication, such as NFC. The STM32 libraries provide the basic structures for describing a device to a USB host, listing all the interfaces by which the device is recognized at the host and communicating data between them. Of course, since active development of firmware functionalities involve a lot of low level debugging, getting to know how these libraries work is essential for successful debugging.
A lot of my work on GSoC right now involves these libraries. I guess my next blog post will be about the USB standard and how we are extending the firmware. That's all for now! :)
The device is built around an STM32F103TBU6 micro-controller. This features a 32-bit ARM Cortex-M3 core with 128kB of Flash Memory and 20kB of SRAM. The manufacturer provides a set of libraries and documentation around them for several different ways that someone may utilize the micro-controller, from memory allocation or control of built-in timers, to USB interface with a host. In that way the STM32 libraries provide the first basic sets of abstraction, which includes, for example, definitions of useful memory locations, register allocation routines, etc. as regards the lowest level, and on top of that there are different levels of software abstractions, like structures and routines, which enable a developer to be able to handle effectively the operation of the micro-controller.
In our case, the USB communication routines were the ones that really matter. The U2F protocol was built around the notion that cryptographic tokens would be USB devices - at least at first - and in the future the standard will include other types of communication, such as NFC. The STM32 libraries provide the basic structures for describing a device to a USB host, listing all the interfaces by which the device is recognized at the host and communicating data between them. Of course, since active development of firmware functionalities involve a lot of low level debugging, getting to know how these libraries work is essential for successful debugging.
A lot of my work on GSoC right now involves these libraries. I guess my next blog post will be about the USB standard and how we are extending the firmware. That's all for now! :)
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου