The long wait is over! Maple Native’s beta release is on sale! Hurray!
Specifications
- MCU: STM32F103ZET6, a 32-bit ARM Cortex M3 microprocessor.
- Clock Speed: 72 MHz
- 512 KB Flash, 64 KB SRAM (on-chip), 1 MB SRAM (external)
- 106 GPIOs
- 17 PWM pins, at 16 bit resolution
- 21 ADC pins, at 12-bit resolution
- 3 SPI peripherals
- 2 I2C peripherals
- 12 Channels of direct memory access (DMA), with 2 DMA controllers
- 3 USARTs (serial port), 2 UARTs
- 2 advanced, 4 general-purpose, and 2 basic timers
- Dedicated USB port for programming and communications
- Dimensions: 4″ × 2.1″
Why is this a Beta?
Experience has (finally) taught us that finalizing the design of a new board might take a couple of tries. Thus, rather than trumpeting this design’s utter perfection (from the rooftops or otherwise), we’re going to give ourselves a little wiggle room. That is to say, maybe we’ll move some pins around between now and the final version, like we did on Maple rev 5. Maybe we’ll mess with the silkscreen. Maybe we’ll fix a couple of bugs. Nothing major; just wiggles.
In addition to that, there are still some software issues which we’re working out before we declare this battle station fully operational. In particular, we’re working on making the 1 MB of external SRAM as easy to use as possible. Technical details for the curious after the jump.
As of version 0.0.11, libmaple doesn’t deal very well with dynamic memory allocation. This has never been much of a problem before, since even the Maple RET6 Edition only has 64 KB of SRAM, so static allocation is usually sufficient. With a full megabyte of RAM, however, the story is different. A recent series of commits in libmaple has fixed dynamic memory allocation, but the heap is still on the internal SRAM. That’s not so great; we expect many (most?) users will want the heap in external memory, so they can e.g. allocate large buffers for audio or image processing.
To resolve this issue, we’re putting together some additional linker scripts for the Maple Native, which will transparently put the heap on the SRAM chip. Using these scripts, malloc() and friends will return pointers into external SRAM.
This might not suit everyone’s purposes, for two reasons. First, the external chip is slower. Second, using it grabs a huge number of GPIOs on the triple header at the right hand side of the board. For this reason, the traditional “RAM” and “Flash” builds you’re used to are still available. These keep the heap on internal SRAM, allowing you to use the extra GPIOs for your own purposes.
Stay tuned for more on this and other updates!