The ESP8266 is a low-cost Wi-Fi chip with full TCP/IP stack and MCU (Micro Controller Unit) capability produced by Shanghai-based Chinese manufacturer, Espressif Systems.
Since 2014, when first came in the attention of the western makers, the documentation became quite available, together with couple of SDKs and firmwares for various programming langauges like Lua, together with the low price, made reasonable easy to develop applications hosted on this tiny chip. Some of this little chip’s features:
- 32-bit RISC CPU: Tensilica Xtensa LX106 running at 80 MHz (can be overclocked)
- 64 KiB of instruction RAM, 96 KiB of data RAM
- External QSPI flash – 512 KiB to 4 MiB (up to 16 MiB is supported)
- IEEE 802.11 b/g/n Wi-Fi
- Integrated TR switch, balun, LNA, power amplifier and matching network
- WEP or WPA/WPA2 authentication, or open networks
- 16 GPIO pins
- SPI, I²C,
- I²S interfaces with DMA (sharing pins with GPIO)
- UART on dedicated pins, plus a transmit-only UART can be enabled on GPIO2
- 1 10-bit ADC
Although developing software to be hosted on it isn’t such a big challenge like it used to be due to the plenty of information available on the internet, debugging the code running on the MCU is a different story. Luckily, at the Attachix blog there is a series of articles about writing software for this MCU, and in the 4th article the owner was nice enough to describe how to set up step-by-step debugging of the code either by command line or even from Eclipse IDE. Please follow this link for the entire article.
In some previous topics (here and here) I wrote about some cheap development boards which can be acquired from EBay or Aliexpress. Since System Workbench for STM32 is freely available for a while now, let’s see how can we use it to generate a project, compile it, upload it to a board and debugging it step by step. We’ll use for this the board I got from EBay, but it works the same with the any STM32 other board I have and also with some self-made ones.
For being able to install firmware on the board and debug it, first we need to have a hardware part which will sit between the computer and the board. There are various models and versions of these jtag debugers and they can be ordered online or found pretty cheap on ebay (clones). Another way to get hold of one of these is to have a development board which comes equiped with JTAG adapters, like the STM32 discovery series of boards. Some of these JTAG debuggers allow even breaking apart the JTAG debugger from the development board itself (LPCXpresso series, the nucleo boards).
Regardless of which JTAG interface is used, it should be one which is known to work with OpenOCD, as we’ll use OpenOCD for debugging. In our case we’ll use the stm32f4 discovery board’s stlink2 side. However, Before using it as a JTAG debugger, we need to disconnect the STLink part from the discovery board, by removing two jumpers. Once that is done, the STLink itself won’t be connected to the discovery board and it’s SWD header can be connected to any other board. Read the rest of this entry →
PS4 and Xbox One have virtual memory and 64 bit address spaces, GPU and CPU are getting closer in the ability to work virtual memory. So our tools are getting better and better and closer to PCs. Most of a games memory goes towards art and level data like bitmap textures and polygon meshes. So artist and designer need to understand how much their data takes up. Giving them call stacks of memory allocations does not help. They want to know how big is a group of building is. Why is this group of building bigger than this one? Maybe this one has some animation data or one of the textures is too big. But there are 10,000s of objects built by 100s of people all around the world.
In case one’s interested in cross-platform development, here is a nice article about various strategies of implementing POSIX condition variables on Win32. Quoting from the article:
The threading API provided by the Microsoft Win32 [Richter] family of operating systems (i.e., Windows NT, Windows ’95, and Windows CE) provides some of the same concurrency constructs defined by the POSIX Pthreads specification [Pthreads]. For instance, they both support mutexes, which serialize access to shared state. However, Win32 lacks full-fledged condition variables, which are a synchronization mechanism used by threads to wait until a condition expression involving shared data attains a particular state.
The lack of condition variables in Win32 makes it harder to implement certain concurrency abstractions, such as thread-safe message queues and thread pools. This article explores various techniques and patterns for implementing POSIX condition variables correctly and/or fairly on Win32. Section 2 explains what condition variables are and shows how to use them. Secion 3 explains alternative strategies for implementing POSIX condition variables using Win32 synchronization primitives. A subsequent article will describe how the Wrapper Facade pattern and various C++ language features can help reduce common mistakes that occur when programming condition variables.