Tag Archives: ARM

A GUI and CLI utility for EFM32’s UART bootloader

via Dangerous Prototypes

efm32_loader_winscr

Mario writes:

I’ve been doing mostly sensor-based systems and I think these microcontrollers are the perfect fit. ARM Cortex (they go from M0 to M4, and their series seem to keep growing), an architecture that was specially designed for low-power sensor-based embedded systems, allowing to measure “stuff” while the CPU is stopped, a nice set of peripherals (OPAMP, 12bit DAC and ADC), great support for GCC ARM Embedded (which makes them really ease to use or getting started to) and a factory-programmed UART bootloader.
The bootloader uses XMODEM-CRC protocol and TeraTerm may be used for uploading. However if you want a command-line tool (like “avrdude” for AVR microcontrollers), there’s anything you can use. So, I built one.

Source code is on Github.

Via the forum.

Project details at Mário Ribeiro’s blog.

Tiva C launchpad FFT with real time plotting using pyQtGraph

via Dangerous Prototypes

rect42411

Shane of Wattnotions writes:

The biased signal generator signal is connected to AnalogIn 1 on the Tiva C which is pin PE_2. Signal Gen and Tiva C ground is common. The two 10k resistors from a voltage divider which will halve the 3v input to give a 1.5 v bias…

See code at Wattnotions page.

Check out the video after the break.

tinyK20: New board with micro-SD card

via Dangerous Prototypes

tinyk20-thumb-drive-bottom-side

Erich of MCU on Eclipse has posted an update on his open source tinyK20 project. We wrote about it previously:

Changes from the earlier version (see “tinyK20 Open Source ARM Debug/Universal Board – First Prototypes“):
1.Replaced the K20 crystal with one having a smaller footprint.
2.Added Micro SD card socket on the back (same socket as on the FRDM-K64F or FRDM-K22F).
3.Because SD cards can draw more than the 120 mA the K20 internal 3.3V provided, there is a footprint on the backside of the board to add an extra DC-DC converter.
4.Moved reset button and headers.
5.First version with transparent enclosure.

Raspberry Pi – Where to start?

via Wolf Paulus » Embedded

At its core, the Raspberry Pi uses the Broadcom BCM2835 System-on-a-chip. This single chip contains

  • an ARM1176 CPU (normally clocked at 700MHz)
  • a VideoCore 4 GPU, i.e. a low-power mobile multimedia processor (also used in the Roku-2)
  • 256 MByte SDRAM
  • in addition to the ARM’s MMU, a second coarse-grained Memory Management Unit for mapping ARM physical addresses onto system bus addresses.

The memory needs to be divided into ARM and GPU memory (happens by including one of the supplied start*.elf files into the boot partition). The minimum amount of memory which can be given to the GPU is 32MB. However that will restrict the multimedia performance and 32MB does not provide enough buffering for the GPU to do 1080p30 video decoding.

The second, slightly smaller chip on the Raspberry Pi board, is an LAN9512, an USB 2.0 hub and 10/100 MBit Ethernet controllers. The LAN9512 is a low-cost, power-efficient, small-footprint USB to Ethernet and multi-port USB connectivity solution in a single package, contains a Hi-Speed USB 2.0 hub with two fully-integrated downstream USB 2.0 PHYs, an integrated upstream USB 2.0 PHY, a 10/100 Ethernet MAC/PHY controller, and an EEPROM controller.

Single-Chip, Hi-Speed USB 2.0 Hub and High-Performance 10/100 Ethernet Controllers

Boot Process

Besides the hardware board itself, starting with the boot process seems to be as good an idea as any… When the Raspberry Pi powers up, it’s the GPU that is active, looking for bootcode.bin, loader.bin, start.elf at the root dir of the first partition at the (fat formatted) SDCard. I.e., booting is hardcoded to happen from the SDCard.
The GPU reads and executes bootcode.bin, which then loads loader.bin, which loads start.elf.
Again in the root dir of the first partition it looks for config.txt, contains information like the arm speed (defaults to 700MHz), address from where to load kernel.img, etc.
Now it kernel.img (arm boot binary file) is copied it to memory and the ARM11 is reset that it runs from the address where kernel.img (default kernel_address 0×8000) was loaded.

Memory Split

The memory needs to be divided into ARM and GPU memory and currently, we have three start.elf files to choose from (see below for details).

  • arm128_start.elf: 1:1, 128MBytes for the ARM11 and 128MBytes for the GPU
  • arm192_start.elf: 3:1, 192MBytes for the ARM11 and 64MBytes for the GPU
  • arm224_start.elf: 7:1, 224MBytes for the ARM11 and 32MBytes for the GPU

Broadcom states in their BCM2835 documentation that 32MBytes might not be enough memory for the GPU and until you reach the point where 128MByte aren’t quite enough for the ARM, you may want to go with the 1:1 spit.

Minimal Boot Image and Blinky Program

Let’s put this Boot Process assumptions that were made above to the test.

  • Prepare an SDCard card (a 1 GByte Class-2 cards works just fine) by formatting it with the MS-DOS (FAT) file system.
  • Download a Raspberry Pi Distribution (currently wheezy-raspbian vers.2012-07-15), uncompress the zip file and open the resulting image file 2012-07-15-wheezy-raspbian.img, for instance with DiskImageMounter, if you are using Mac OS X.
  • Copy bootcode.bin form the wheezy-raspbian.img to the root directory of the SDCard.
  • Copy loader.bin form the wheezy-raspbian.img to the root directory of the SDCard.
  • Copy arm128_start.elf form the wheezy-raspbian.img to the root directory of the SDCard and rename it to start.elf.
  • Copy config.txt form the wheezy-raspbian.img to the root directory of the SDCard.
  • Add the following two lines to your config.txt:
    kernel blinky.bin
    kernel_address 0×8000
  • Uncompress and copy blinky.bin to the root directory of the SDCard.

Now insert the SDCard into your Raspberry Pi and power it up. If all goes well, you should see the Raspberry Pi’s OK LED blink.
The five files, which total just over 2MBytes are probably the closest and smallest you can get to an Hello_World style program for the Raspberry Pi.

Stay tuned for how to create your own Raspberry Pi Tool Chain and how to make blinky.

Energy-efficient Computing (Open Compute, BeagleBoard, Event-driven XCore)

via OSHUG

At the eighteenth OSHUG meeting we will hear how open source collaboration is being used to transform data centre design, and how open source hardware and software have been used to enable low cost ARM development. It will also be the OSHUG 2nd anniversary, and two years on we are delighted to welcome back XMOS, who will be giving us an introduction to event-driven programming with XCore.

The Open Compute Project

Facebook uses a lot of servers, and those servers use a lot of energy. To minimise the costs associated with those servers and data center facilities, Facebook engineers came up with a fresh design. To build a community around that design it has been open sourced via the Open Compute Project (OCP). OCP is now involved in taking the requirements of many large data center users, and turning them into designs for servers, the racks that hold them, the facilities that power and cool them, and the management interfaces that control them. This presentation will give an overview of what Facebook have built, and how OCP plans to transform data centers elsewhere.

Chris Swan has been an electronics hobbyist and software hacker since primary school. These days he's an IT guy at a large bank, focussed on security and innovation - including mobile, consumerisation and cloud computing. Alongside his day job Chris chairs the infrastructure working group at the Open Data Center Alliance (ODCA), which is partnered with the Open Compute Project (OCP).

BeagleBoard.org Community - Open Hardware, Open Software, Open Platforms

BeagleBoard.org has created a number of products since its conception a few years ago, from the initial 'BeagleBoard' single board computer, through to the enhanced 'BeagleBoard-xM' with more performance and connectivity, and its most recent and expandable platform, the 'BeagleBone'. All of these have set out to achieve a goal of bringing high performance ARM-based processing technology to a wide 'community' of developers and users, in low-cost 'open' platforms, giving access to as much of the system-on-chip features as possible. The recent launch of the 'BeagleBone' was a great testament to this vibrant 'community', key to Beagleboard.org, which enabled a wealth of advanced platform and application software to be immediately available, and a large amount of hardware expertise providing feedback and ready to start building add-ons and clones. This was exactly what was hoped for when the project was initially conceived by a couple of engineers discussing at the coffee machine about how their technology could be made more widely accessible. The community continues to grow each day, with more and more exciting and innovative uses for these low-cost, open platforms revealed on the various mailing lists and chat rooms - from 'football playing robots' to 'media servers', the list, expertise and imagination seems endless!

This presentation hopes to give an overview of the BeagleBoard.org community project and how the products have been created and supported. There have been many exciting moments, many challenges and many lessons learned throughout this project - some of which will hopefully be covered during this presentation and discussion.

Roger Monk is a System Applications Engineer for Texas Instruments, and has spent the last 10+ years working closely with customers to build hi-tech electronic products based around Texas Instruments Embedded Processing technology across a range of application areas. Roger is passionate about open-source technology and the ability for it to help deliver higher quality, more innovative products to market quickly. He has been closely involved with the BeagleBoard.org community project since its conception.

Event-driven Programming with XCore

XMOS designs concurrent, event-driven processor cores. Because of the deterministic nature of the architecture both real-time algorithms and hardware interfaces can be developed as software. The event-driven nature of the processor means that all programs pause until they need to perform a task, making them inherently efficient.

In this talk we will discuss events, concurrency, and how hardware interfaces can be programmed in software. We will then show the design of the slice-kit development system, which enables XCores to be easily attached to peripheral PCB's containing, for example, an Ethernet PHY.

Henk Muller is currently the Principal Technologist at XMOS Ltd. In that role he has been involved in the design and implementation of hardware and software for real time systems. Prior to that, Henk worked in Academia for 20 years in computer architecture, compilers, and ubiquitous computing. He holds a doctorate from the University of Amsterdam.

Note: Please aim to arrive for 18:00 - 18:20 as the event will start at 18:30 prompt.

Sponsored by:

Energy-efficient Computing (Open Compute, BeagleBoard, Event-driven XCore)

via OSHUG

At the eighteenth OSHUG meeting we will hear how open source collaboration is being used to transform data centre design, and how open source hardware and software have been used to enable low cost ARM development. It will also be the OSHUG 2nd anniversary, and two years on we are delighted to welcome back XMOS, who will be giving us an introduction to event-driven programming with XCore.

The Open Compute Project

Facebook uses a lot of servers, and those servers use a lot of energy. To minimise the costs associated with those servers and data center facilities, Facebook engineers came up with a fresh design. To build a community around that design it has been open sourced via the Open Compute Project (OCP). OCP is now involved in taking the requirements of many large data center users, and turning them into designs for servers, the racks that hold them, the facilities that power and cool them, and the management interfaces that control them. This presentation will give an overview of what Facebook have built, and how OCP plans to transform data centers elsewhere.

Chris Swan has been an electronics hobbyist and software hacker since primary school. These days he's an IT guy at a large bank, focussed on security and innovation - including mobile, consumerisation and cloud computing. Alongside his day job Chris chairs the infrastructure working group at the Open Data Center Alliance (ODCA), which is partnered with the Open Compute Project (OCP).

BeagleBoard.org Community - Open Hardware, Open Software, Open Platforms

BeagleBoard.org has created a number of products since its conception a few years ago, from the initial 'BeagleBoard' single board computer, through to the enhanced 'BeagleBoard-xM' with more performance and connectivity, and its most recent and expandable platform, the 'BeagleBone'. All of these have set out to achieve a goal of bringing high performance ARM-based processing technology to a wide 'community' of developers and users, in low-cost 'open' platforms, giving access to as much of the system-on-chip features as possible. The recent launch of the 'BeagleBone' was a great testament to this vibrant 'community', key to Beagleboard.org, which enabled a wealth of advanced platform and application software to be immediately available, and a large amount of hardware expertise providing feedback and ready to start building add-ons and clones. This was exactly what was hoped for when the project was initially conceived by a couple of engineers discussing at the coffee machine about how their technology could be made more widely accessible. The community continues to grow each day, with more and more exciting and innovative uses for these low-cost, open platforms revealed on the various mailing lists and chat rooms - from 'football playing robots' to 'media servers', the list, expertise and imagination seems endless!

This presentation hopes to give an overview of the BeagleBoard.org community project and how the products have been created and supported. There have been many exciting moments, many challenges and many lessons learned throughout this project - some of which will hopefully be covered during this presentation and discussion.

Roger Monk is a System Applications Engineer for Texas Instruments, and has spent the last 10+ years working closely with customers to build hi-tech electronic products based around Texas Instruments Embedded Processing technology across a range of application areas. Roger is passionate about open-source technology and the ability for it to help deliver higher quality, more innovative products to market quickly. He has been closely involved with the BeagleBoard.org community project since its conception.

Event-driven Programming with XCore

XMOS designs concurrent, event-driven processor cores. Because of the deterministic nature of the architecture both real-time algorithms and hardware interfaces can be developed as software. The event-driven nature of the processor means that all programs pause until they need to perform a task, making them inherently efficient.

In this talk we will discuss events, concurrency, and how hardware interfaces can be programmed in software. We will then show the design of the slice-kit development system, which enables XCores to be easily attached to peripheral PCB's containing, for example, an Ethernet PHY.

Henk Muller is currently the Principal Technologist at XMOS Ltd. In that role he has been involved in the design and implementation of hardware and software for real time systems. Prior to that, Henk worked in Academia for 20 years in computer architecture, compilers, and ubiquitous computing. He holds a doctorate from the University of Amsterdam.

Note: Please aim to arrive for 18:00 - 18:20 as the event will start at 18:30 prompt.

Sponsored by: