Programming microcontrollers *

Introduction

• IAR Embedded Workbench
• Keil Embedded Development Tools for Arm
• TI ARM Code Generation Tools
• GNU Embedded Toolchain

NodeMCU is an interactive firmware, which allows running Lua interpreter on the ESP8266 microcontroller (ESP32 support is in development). Alongside with all the regular hardware interfaces, it has WiFi module and SPIFFS file system.

This article describes the new module for the NodeMCU — sdm. SDM stands for simple driver model and it provides device-driver model abstraction for the system. In the first part of this article we will discuss the model itself and in the second part will be a showcase of dynamically created web user interface using sdm with some commentaries.

Protocol AXI4 was developed for High-bandwidth and low latency applications. It is designed to allow communication between master and slave devices. Master is typically a DMA or CPU and slaves are DRAM controllers, or other specific protocol controllers: UART, SPI, and others. Sometimes one component can implement multiple instances of this protocol. Usually, a prefix is used to differentiate between multiple AXI4 interfaces.

For example, Ethernet MAC can integrate DMA and slave interface used to command MAC. MAC can accept commands on the slave interface that contain data about the location of the next ethernet packet and MAC can start fetching this packet using the separate master interface instance.

This article was motivated by common design mistakes AXI4 designers make when they are designing their Digital IP. (Looking at you Xilinx)

In this article I will talk about my attempt to create flexible, compact and beautiful modular prototyping framework

Hellow my name is Dmitry. Once I bought "Orange PI i96", but unfortunately producer not update it firmvere very long. Last firmwere kernel version is 3.10.62 but kernel current at time this article writing (russian version) is 6.5.1. And so I decide build my own firmware from scratch, and do it from sourse completely.

Last week I was doing a seminar on SystemVerilog, ASIC and FPGA at ADA University in Baku, Azerbaijan. I will replicate the last two sessions of this seminar, on RISC-V CPU simulation and synthesis, at the Verilog Meetups on March 3 and March 10 at Hacker Dojo, Mountain View, California. For this reason I am combining the information about Azerbaijan and California seminars in a single post.

First, let's talk about ADA University.

The team developing a set of portable SystemVerilog examples decided to organize the first event in Silicon Valley on Sunday, January 14 from 2PM till 5PM at Hacker Dojo in Mountain View, CA. If the first event is successful we are going to make it recurrent. You can register for the event on Meetup or LinkedIn.

The current directions of the group:

Ссылка на русскую версию / link to Russian version

Understanding valid/ready protocol is extremely important for every microarchitect.

Valid/ready is one of the main protocols used to organise flow-control inside a logic block as well as on inter-block (SoC) level.

In the last lesson, we explored FIFO buffer using hdlgadgets - human-in-the-loop HDL training tool.

This time we will take two FIFO buffers (which form a pipeline with valid/ready handshakes) and will experiment with it by changing flow-control logic of the pipeline.

We will show that valid/ready is not only a mechanism for transferring data from one FIFO queue to another, but also a method for organizing various kinds of logical functionality between queues.

If you have not worked with valid/ready protocol before, you will be surprised how easy it is to achieve desired functionality of the design by simply writing couple of lines of Verilog code in the handshaking logic block between two FIFOs.

Hi there! A while ago, Positive Technologies published the news that ATMs manufactured by Diebold Nixdorf (previously known as Wincor), or more specifically, the RM3 and CMDv5 cash dispensers, contained a vulnerability which allowed attackers to withdraw cash and upload modified (vulnerable) firmware. And since my former colleague Alexei Stennikov and I were directly involved in finding this vulnerability, I would like to share some details.

On Ali, an interesting toy – an oscilloscope called DSO138 is sold for a very inexpensive price. It has already gained quite a lot of popularity among electronics lovers, but the parameters of this device, alas, allow it to be more or less fully used only for debugging very low-frequency circuits. Actually, it is not positioned as a tool, but rather as a DIY-kit for novice electronics engineers.

This "toy" oscilloscope is assembled on the STM32F103 microcontroller, and with a fairly competent circuit design of the digital part, the presence of a fairly decent 320X240-dot color display, and not the most rotten analog path, everything, alas, is ruined by very weak ADCs on board the 32F103. The claimed band of 200 kHz can be recognized as such only with a very large stretch. Yes, it will show the presence or absence of a signal with such a frequency, but it will not be possible to really look at something beyond this.

At the same time, the 103-series has a slightly more powerful brother - the STM32F303, it is almost completely compatible with the legs, but it is significantly better in terms of the parameters we are interested in, there are 4 ADCs on board with a conversion frequency of 5 MHz (6 MHz with a 10-bit resolution). In this scenario, if you use all 4 ADCs in parallel with a 10-bit resolution, you can get a effective resolution of up to an honest 24 MSPS (millions of samples per second). The microcontroller is also inexpensive; you can easily find it on the same Ali for very reasonable money again. It is clear that the idea to change the microcontroller arose almost immediately after I tried this DSO138.

At the same time, if upgraded the toy can turn out to be a completely full-fledged tool that even professionals, not just novice amateurs, could already use. With these thoughts in mind, I decided to try to do something with a Chinese toy in my free time.

For the last 30 years digital chip design is not a schematic entry anymore: hardware engineers write code just like software engineers.

The difference is that the code software engineer writes becomes a chain of CPU instructions stored in memory, while the code in a hardware description language (HDL) becomes the CPU itself, its transistors and metal connections. And not only a CPU: the same technique is used to design processor-less ("fixed function") blocks in GPU that shuffle triangles and pixels, as well as network router chips that edit packet headers 100 times faster than CPU.

There are ways to experience this workflow without paying a million dollars to a silicon fab. One way is simulation, and another way is to use a matrix of reconfigurable logic cells, a Field Programmable Gate Array (FPGA). You can come on January 14 to Hacker Dojo in Mountain View, California. We have a bunch of computers and FPGA boards, and we will show you how to use them not only to blink LEDs but also to output graphics and recognize music.

This will change your perspective of what the code is.

Ссылка на русскую версию / link to Russian version

FIFO is a key concept in hardware design. Understanding of FIFO is necessary for understanding the valid/ready protocol, which in turn is necessary for organisation of flow-control within a design.

Unfortunately, there are very few books on this topic, and to be fair, microarchitectural concepts are quite difficult to master from books, since understanding of these concepts are coming with practice. In other words it is more about developing hardware intuition.

The idea of the HDL training tool is that it can help develop a hardware intuition, providing the opportunity to explore ready-made scenarios in a step-by-step interactive way. The tool also provides detailed visualization of a simulated scenario.

Since the tool is a front-end for the HDL simulator, the real, synthesized SystemVerilog is executed on the simulator itself, which can be viewed and even modified.

So, the video of exploring FIFO on the training tool is here:

Flipper Zero is an open-source multi-tool for geeks and penetration testers. It so happened that the Flipper Zero project and the PVS-Studio analyzer crossed paths. A philosophical question: should we check the project, if the project developers have already started fixing errors? Let's try to do this.

Since the New Year we had 7 Verilog meetups at HackerDojo. We discussed the modern way of designing digital circuits using hardware description languages, the exercises on FPGA boards and the topic of microarchitecture. For the last two sessions we went over the most basic CPU core that can be used as a baseline for further exercises.

Now, in order to make progress toward the goal of creating new educational materials, it is essential for the regular participants to solve all the homework exercises (see the details in the post below) in parallel with studying the recommended materials.

The next steps are:

1) We are going to do weekly Zoom calls on Sundays, starting March 24, 2024 at 11 am California time (summer time). The link. During this call we are going to discuss the SystemVerilog Homework and the individual projects.

2) Once we develop more materials, we are going to organize a Show-and-Tell session in Hacker Dojo, for a wider audience. During the session several participants from the core team will present demos on various FPGA boards and explain to the curious how FPGA and ASIC work.