[Henrik] is at it again. Another thoroughly detailed radar project has shown up on his blog. This time [Henrik] is making some significant improvements to his previous homemade radar with the addition of Synthetic Aperture Radar (SAR) to his previous Frequency Modulated Continuous Wave (FMCW) system.
[Henrik’s] new design uses an NXP LPC4320 which uniquely combines an ARM Cortex-M4 MCU along with a Cortex-M0 co-processor. The HackRF also uses this micro as it has some specific features that can be taken advantage of here like the Serial GPIO (SGPIO) which can be tediously configured and high-speed USB all for ~$8 in single quantity. The mixed signal design is done in two boards, a 4 layer RF board and 2 layer digital board.
Like the gentleman he is, [Henrik] has included schematics, board files, and his modified source from the HackRF project in his github repo. There is simply too much information in his post to attempt to summarize here, if you need instant gratification check out the pictures after the break.
The write-up on his personal blog is impressive and worth look if you didn’t catch our coverage of his single board Linux computer, or his previous radar design.
Continue reading “An Improvised Synthetic Aperture Radar”
As far back as we can remember, there have always been hacks, exploits, and just curiosity about undocumented CPU instructions. The Z80 had them. Even the HP41C calculator had some undocumented codes. The HCF (Halt and Catch Fire) instruction was apocryphal, but we always heard the old video controller chips could be coaxed into blowing up certain monitors. You don’t hear too much about things like that lately, perhaps because fewer people are working in assembly language.
[Sergi Àlvarez i Capilla] not only works in assembly language, he was writing an ARM assembler when he noticed something funny. Instructions are built in a regular pattern and some of the patterns were missing. What to do? [Sergi] lost no time trying them out.
Continue reading “Raspberry Pi Halt and Catch… Well, Halt”
Most of us don’t realize how spoiled we are with the different development environments available on the internet. If someone wants to start a blank project on a new [ARM/DSP/…] platform, he usually fires up the dedicated Integrated Development Environment (IDE) and starts coding a C/C++ program. However, there are many initialization routines and scripts required with your program before it can run correctly. In his great article, [Andrew] explains to us what these are by starting a blank project without using any IDE.
As you can see in the above picture, [Andrew]’s project is made around an Atmel SAM4E microcontroller. The chosen toolchain is the arm-none-eabi-gcc from GNU Tools for ARM Embedded Processors. The first part of the article starts with a simplified explanation on how/why your code and variables are split into different memory sections (.bss, .data, .rodata, .text), then [Andrew] details how the linker script will put these sections at different physical addresses depending on your microcontroller’s memory layout. He also shows us how to take care of the stack placement, vector table, variable (non)initialization, and C Runtime. For information, the latter is executed when your processor starts, it is in charge of setting up the stack pointer, initializing the RAM, setting up the standard library and calling the main().
A very nice introduction on the very low level routines running on most processors out there.