[dorkbotpdx-blabber] Cooking with the Maple Bacon, Saturday 25AUG12, 1-5 FreeGeek, $40

[D Delmar Davis]

Suspect Devices Presents: Cooking with Maple Bacon

This saturday we will introduce our new hardware the Maple Bacon in a workshop focusing on programming.

In this workshop we will introduce the Leaflabs Maple platform using our own varient of the maple mini, the "Maple Bacon". This will be a software only (hardware is included, no soldering required) class and it will focus on programming.

• An introduction to the Maple IDE and a comparison of it to the Arduino and Wiring Platforms.
• An introduction to using libmaple from the command line and integrating it into an ide
• Hardware Hello World.
• Software Hello World (serial).
• A more complicated example which will serve the following discussion
• C(++) in an embedded environment
  • Datatypes
  • Structures,arrays,and enums
  • Scope, constants, and macros
  • C++ and Classes
• Hardware interaction
  • Basic IO, Analog to Digital
  • Serial Ports (usb, usart, spi, twi)
  • External Interrupts
  • Timers
  • PWM

What to Bring:

A laptop and a standard usb a-b cable.

RSVP

You can rsvp for this workshop at http://www.suspectdevices.com/blahg/workshops/

[Joel]

For those of you like me who don't closely read subject lines: the
cost of the workshop (which includes the ~$35 Maple Bacon hardware) is
$40.

> _______________________________________________
> dorkbotpdx-blabber mailing list
> dorkbotpd...@dorkbot.org
> http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
_______________________________________________
dorkbotpdx-blabber mailing list
dorkbotpd...@dorkbot.org
http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber

[Aaron Eiche]

Which is, if anyone doesn't know, a pretty amazing deal. I'm excited for this and I hope I can make it.

[Aaron Burt]

On Mon, Aug 20, 2012 at 11:35:04AM -0700, D Delmar Davis wrote:
> Suspect Devices Presents: Cooking with Maple Bacon
> This saturday we will introduce our new hardware the Maple Bacon in a workshop focusing on programming.
> In this workshop we will introduce the Leaflabs Maple platform using our own varient of the maple mini, the "Maple Bacon". This will be a software only (hardware is included, no soldering required) class and it will focus on programming.

Cool! I love ARM.

That said, what's the big reasons someone would want to move from AVR to
(small) ARM? No *nix, but is there networking? Cool video/sound features?
Advanced peripheral connectivity? Something cool we can do with all that
extra CPU power?

Thanks,
Aaron

[Jerry Biehler]

You can blink LEDs soooo much faster.

-Jerry

[Aaron Eiche]

Is the ARM on the Maple Bacon 32bits?

[Joel]

Yep:
http://leaflabs.com/devices/

Dimensions: 2.02 x 0.72 inches
Microprocessor: 32-bit ARM Cortex M3 at 72MHz (STM32F103CBT6)
Memory: 120 KB Flash and 20 KB SRAM
I/O Pins: 34 (of which 12 provide PWM output at 16-bit resolution)
ADCs: 9 (at 12-bit resolution)
Peripherals: 4 timers, 2 I2Cs, 2 SPI ports, 3 USARTs
Other: Sleep, stop, and standby modes; serial wire debug and JTAG interfaces

[D Delmar Davis]

Aaron,

My personal reasons for moving to the arm are in the first part of my osb talk from this year.

http://suspectdevices.com/TheBaco-matic5000-OSB/assets/player/KeynoteDHTMLPlayer.html
(http://www.suspectdevices.com/blahg/arm/bacon/baco-matic-5000-talk-notes/)

.... I am told that at some time in the future there will be audio.....

My reasons for introducing this to dorkbot is to try to bridge the gap between the current group of technically savvy arm users and people who would otherwise be stuck with the Arduino. Also note that I am not alone in moving to arm (see the Arduino DUE)
The arm in the maple is much less expensive and more approachable than either the DUE or the next generation Maple board.

Don

[Aaron Eiche]

Would taking this class give us a headstart/background enough to program one of Scott's nametags?

[Cameron Adamez]

There is a sketch for simple VGA.

I have two projects in the pipeline but they will be slow since I am relatively new to writing C and Assembly (I'm a Ruby programmer by day).
1) I am working on porting the Arduino TVout library. I will post source code once I have a handle on how the timers work.
2) I am working on another board design that will have MIDI and audio out built in. However, to do midi yourself the hardware is very simple -- pick up a perfboard and make a midi circuit, then plug it into the Maple Bacon.

Since this is still an infant compared to the work done for Arduino, it will probably lag behind a bit. But it will get there!

Cameron

On Aug 20, 2012, at 1:19 PM, Aaron Burt wrote:

[D Delmar Davis]

I was considering porting that project.

[D Delmar Davis]

One of the things that I have found when working with the arduino code base is how much cruft has collected.
Porting to a different architecture really highlights how much cleanup there is to be done.

Which is a good thing.

[Scott Dixon]

On Aug 20, 2012, at 2:13 PM, Aaron Eiche wrote:

> Would taking this class give us a headstart/background enough to program one of Scott's nametags?

It would help somewhat but there are also some differences between the boards. The main thing you would learn about which would be similar would be using the programming toolchain (and it sounds like he will be covering some common embedded C programming topics also). But the libraries used are different. Don is using libmaple which has a Wiring/Arduino flavor while I am using a library from microbuilder.eu. Still, learning some C programming and getting a toolchain set upfor any Cortex M3 chip would have some carry over.
-Scott

[Paul Stoffregen]

>
> .... I am told that at some time in the future there will be audio.....
>

Does it have an I2S port (not I2C, but I2S) with DMA?

[D Delmar Davis]

Maple native will probably support i2s but its a big and expensive processor. The Ret6 had i2s hardware but no native library support and the ret6 is not guaranteed to have future libmaple support. Most of the stm32 peripherals have dma support. For cheap with decent i2s you might look at the nuc12x series of chips or as jared boone.

....

[David Turnbull]

The PSoC 5 has a Cortex M3 and does I2S with DMA. I even have code and
circuits for making a 24-bit USB sound card using a PCM3060. My
project uses the $7 48-pin 8051 version of the PSoC, but the code is
the same for the M3.

https://github.com/ham21/peaberry

-david

[Paul Stoffregen]

Wow, I didn't know Cypress had ARM *and* 20 bit analog.... crazy! Too
bad those analog bits aren't at audio bandwidth, but the chips look like
they have a lot of nice stuff.

I've used the Nuvoton parts. In fact, I have one on a board right here,
which you'll probably see in several weeks. Nuvoton's documentation
leaves quite a bit to be desired. Maybe the Chinese version is better?

As I recall, Don, you built some dev boards with Nuvoton parts quite a
long time ago, maybe over a year now? What ever happened with those?

[D Delmar Davis]

As I recall, Don, you built some dev boards with Nuvoton parts quite a long time ago, maybe over a year now?  What ever happened with those?

Been well over 2 years now. 

Not a lot of open source or cross platform support let alone community.(on top of the issues you mentioned. ) 

And as you are clearly pointing out, I am not a super genius capable of scratch building the universe. I was to stupid to understand the stuff that Jared was doing and so I spent several  months in a vm and built a few projects in the windows based commercial compiler but got frustrated and moved on to less difficult tasks.

Good bang for the buck though.

[Philip Odom]

For what it's worth, Nuvoton's Chinese documentation is probably better for more obscure stuff. We've asked Nuvoton a few questions on older devices that required the US guys to have something translated from a Chinese document, but for the NUC1xx series, which is probably what you're talking about, all of the documentation seems to be the same in Chinese as in English.

Also: the Nuvoton peripheral libraries aren't worth much, and a lot of the peripherals don't seem as well thought out or as configurable as those in other vendors' Cortex devices. That said, we've used several parts from them, the pricing can't be beat (for large volumes), and we have mostly been able to get them working the way we want :)

There's a Taiwanese university (Wuhan University of Technology) that's partnered with some IC companies to develop an open-source RTOS for M3/M0 microcontrollers. They support Nuvoton, Atmel, NXP, TI, Holtek, etc. Has anybody checked it out?

http://www.coocox.org/

We're trying it out right now. Seems useful so far.

Don, the Maple stuff looks very nice. I may buy a couple. It's great to see someone offering a low-cost, open STM board.

-Philip

[Paul Stoffregen]

For Nuvoton, I've ended up going to the ARM Ltd documentation.  It's amazing how much of documentation there is, yet how little of it actually describes how to actually use anything.  Everything seems to be just raw documentation for each little module.  No examples, no explanations, just raw facts.

Unlike AVR where there's a pretty simple ISP programming interface, you pretty much have to build a debug system using ARM's very complex protocols, take control of the processor core, and then to program the flash you need to load and execute in RAM your own code (plus the data you want flashed) which does the work using the chip's in-application flash programming interface.

Compared to the convenient hardware interfaces and/or bootloaders that are so common on 8 bit chips, it's a pretty incredible hurdle to building any workable tools.  Of course, many of the ARM chips have nice bootloaders in ROM, but not Nuvoton!

[Zach Archer]

Suppose you wired the Maple's digital outputs to a DAC
(digital-to-analog converter). Would that be fast enough to synthesize
sound at audio rates?

-- Zach
zacharcher.com

On Mon, Aug 20, 2012 at 4:59 PM, Paul Stoffregen <pa...@pjrc.com> wrote:

[David Turnbull]

It's pretty easy to find tools for SWD and JTAG. e.g. OpenOCD and the
1st party tools. All the ARM chips I've looked at have the silicon to
support this, even Nuvoton. Why are you writing custom bootloaders?

-david

On Mon, Aug 20, 2012 at 7:22 PM, Paul Stoffregen <pa...@pjrc.com> wrote:
> For Nuvoton, I've ended up going to the ARM Ltd documentation. It's amazing
> how much of documentation there is, yet how little of it actually describes
> how to actually use anything. Everything seems to be just raw documentation
> for each little module. No examples, no explanations, just raw facts.
>
> Unlike AVR where there's a pretty simple ISP programming interface, you
> pretty much have to build a debug system using ARM's very complex protocols,
> take control of the processor core, and then to program the flash you need
> to load and execute in RAM your own code (plus the data you want flashed)
> which does the work using the chip's in-application flash programming
> interface.
>
> Compared to the convenient hardware interfaces and/or bootloaders that are
> so common on 8 bit chips, it's a pretty incredible hurdle to building any
> workable tools. Of course, many of the ARM chips have nice bootloaders in
> ROM, but not Nuvoton!

[Jim Larson]

In my limited experience (smallish - 256K - STM ARMS and 128K Nuvoton),
I've found OpenOCD works well for the STMs and will talk to the Nuvoton:
reset, start, examine registers, set bits, etc. What OpenOCD won't do
for the Nuvoton is program the flash! For that, you have to write the
programming code as Paul said. (It goes in OpenOCD, but you still have
to write it.) I found the Nuvoton documentation to be woefully
inadequate as a guide to programming the flash and gave up on it. The
STMs worked just fine and OpenOCD was a good environment for developing
them.
-jim

> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2197 / Virus Database: 2437/5212 - Release Date: 08/20/12

[Paul Stoffregen]

The thing I found most difficult about Nuvoton was getting the chip to
reboot without connecting the reset line, using only SWDIO and SWDCLK.
Nuvoton's flash memory controller has a bit that's supposed to initiate
a software reboot. At least in the one chip I've been using, I pretty
much came to the conclusion it simply doesn't work. The system control
block in the M0 core has a AIRCR register that is supposed to provide a
software reset that's vendor neutral for all ARM cores. That also
doesn't work on Nuvoton. I tried writing to them both via the debug
port MEM-AP and by code running from RAM. I'm pretty sure it's an
undocumented silicon bug. I tried the same on another ARM from a
different vendor, and AIRCR works fine. Later I found another bit in
Nuvton's own system control peripheral, in the IPRSTC1 register, which
does actually work. So many hours lost......

[David Turnbull]

Madness! There's thousands of people all over the world doing the same
non-productive work.

-david

[Erik Walthinsen]

On 08/21/2012 10:25 AM, David Turnbull wrote:
> Madness! There's thousands of people all over the world doing the same
> non-productive work.

No kidding...

That's why a major component of our talk at DEFCON involved the idea
that the ARM toolchain on Linux needs to be *seriously* revamped so it
doesn't suck. That includes both the programming tools (OpenOCD is a
nightmare) and the toolchain integration (per-chip headers, linkscripts,
crt.o's, and everything else). Right now it's a total crapshoot whether
the chip you select is going to have any kind of sane (and vaguely
functional) example somewhere out there, otherwise you have to pry
highly non-standard files out of the manuf's crappy IDE and try to
shoehorn them into your own project.

Compiling for ARM should work like AVR:

arm-...-gcc -mmcu=stm32f103rb -o program program.c
<EOM>

If anybody's interested in contributing to such a project, we have
forums at <http://www.dcgdark.net/forums/viewforum.php?f=8> and I'm
hoping to be at the next dorkbot meeting, hopefully Mike will be there too.

[Paul Stoffregen]

On 08/21/2012 10:25 AM, David Turnbull wrote:

> Madness! There's thousands of people all over the world doing the same
> non-productive work.

Not entirely non-productive, since I did eventually find a way to make
it work. ;-)

And no, OpenOCD, Keil, IAR, Segger, etc are not the answer when you want
something to work in a way dramatically different than the established
norm....

[Erik Walthinsen]

On 08/21/2012 10:38 AM, Paul Stoffregen wrote:
> And no, OpenOCD, Keil, IAR, Segger, etc are not the answer when you want
> something to work in a way dramatically different than the established
> norm....

Agreed, since I had to build my own complete toolset to do parallel
Xmega programming with full isolation... I did manage to make it work
with avrdude, though I had to modify it slightly, and it has to feed
through my multiplexer daemon.

I'm curious specifically in what way what you're trying to do conflicts
with the "standard" approaches? Does it boil down to an architectural
flaw in one of the standard tools? Would more factorizable tools help?

[Zach Archer]

If anyone is interested, I answered my own question -- there are many
DAC options available. You can even build your own. This page is a
good starting point:
http://embeddednewbie.blogspot.com/2011/02/review-of-arduino-dac-solutions.html

-- Zach
zacharcher.com

[Paul Stoffregen]

On 08/21/2012 10:47 AM, Erik Walthinsen wrote:
> On 08/21/2012 10:38 AM, Paul Stoffregen wrote:
>> And no, OpenOCD, Keil, IAR, Segger, etc are not the answer when you want
>> something to work in a way dramatically different than the established
>> norm....
>
> Agreed, since I had to build my own complete toolset to do parallel
> Xmega programming with full isolation... I did manage to make it work
> with avrdude, though I had to modify it slightly, and it has to feed
> through my multiplexer daemon.
>
> I'm curious specifically in what way what you're trying to do
> conflicts with the "standard" approaches?

It's really too early to go into details.

> Does it boil down to an architectural flaw in one of the standard
> tools? Would more factorizable tools help?

Basically, no. The existing tools aren't flawed. Well, they aren't
flawed, except for missing support for various hardware, bugs, and
terrible usability (mostly OpenOCD... Keil & IAR are pretty solid).
They're just fundamentally designed and built around well established
paradigms, the standard ways of doing things that are so common that
it's hard to imagine any other approach.

[Cameron Adamez]

The particular STM32 on the Maple Bacon doesn't have onboard DACs, but LeafLabs had a Maple using the RET6 chip (STM32F103RET6 I think) that had onboard DACs. I am in development to expose the pins on that chip and include a MIDI circuit, audio jacks, etc.

Cameron

[Cameron Adamez]

That's how open source works. (Just look at the history of the Wiring board.) Eventually these things will converge or borrow.

Also, LeafLabs has done a stellar job on libmaple so far.
Plus, people are still working on the ARM compiler, as you can see:
https://launchpad.net/gcc-arm-embedded/

Cameron

[Cameron Adamez]

If you want to contribute, you can fork away :)

It's the one called peperbacon.

https://github.com/soycamo/maplebacon

Cameron

[Zach Archer]

Thanks! I'll check these out after I get comfortable with the Maple & IDE.

-- Zach
zacharcher.com