Making the Cortino

I was looking to buy the cortino
http://www.bugblat.com/products/cor.html

but it seems to be out of stock indefinitely. Now I'm thinking of making a few of these boards based on the schematic available. I have a few questions and wanted to check if there are any cortino users here who can answer them

Are there any free / Open sources tool chains for programming the cortino? If so, do you have any tutorials on this?
Is it possible to program the cortino from linux?
Is there a bootloader involved? If so is this open-source / freely available?
I would appreciate if someone can explain more on the bootloader part of this like is it built onto the chip or is it something that has to be loaded like with the arduino. If it has to be loaded, how does one load it? I know too many questions, but i'm very curious to try it out.

Cheers,
Pracas

Did you see the post about the Maple a few days ago? Looks like much the same thing as the Cortino, except for using a version of the MCU with less memory.

Did you see the post about the Maple a few days ago?

Yes, I did. Any users here who can answer the same questions for maple?

I think I can answer some of the questions. I haven't got either a Cortino or Maple (yet), but I have been doing some investigation on Cortex-M3 boards.

A Cortino and a LeafLab Maple both use members of the same ST Micro Cortex-M3 STM32F103 family of chips. There are differences between the number and type of peripherals across members of that family of parts, but both Cortino and Maple have a version with the same STM32F103RB, which is 128K Flash program memory, and 20K RAM, and the same peripherals in a 64-pin package (so lots of I/O).

The same compilation and link tool chain will work for both.
GNUs' gcc for ARM is freely available as Open Source, and you can get it from GNU, or from codesorcery.com who offer commercial support and an IDE.

There are tutorials for installing this toolchain on various systems. Pete Harrison at micromouseonline.com gives links and an explanation of how he did it for Mac OS X, but I'd suggest starting with LeafLabs packaging of their work in their version of the Arduino IDE.

An obstacle is the upload to the bootloader, all the rest of the toolchain should work.

AFAIK, the LeafLabs folks are using a vanilla gcc (but I'll try to report back if I discover otherwise).

'Out of the packet', i.e. 'raw' as it comes from the manufacturer, the STM32F103 does have a boot loader already installed on chip, but it boots from a serial USART. Maybe that is why the Cortino folks appear to use an FTDI USB to serial chip on their board, even though the STM32F103 has on onboard USB. The LeafLab Maple uses the on-board USB support in the STM32F103; AFAIK, that is the major difference between the two boards.

Other versions of the STM32F range, specifically STM32F105's have a USB bootloader on chip 'raw'. That '105 bootloader looks like a USB DFU device. USB DFU is a 'standard' (like HID, Mass storage, CDC serial etc.), specifically designed for updating firmware on devices, and many Operating systems have DFU drivers already. As an example of a device which uses DFU to update is the iPhone. AFAIK, Windows doesn't support DFU properly (I am not a regular Windows user, so I'll leave it at that).

The Maple folks have written a bootloader for the STM32F103 on the Maple. It may be possible to get this working on a Cortino, but I couldn't comment on how easy or difficult that might be. Also, a Cortino is almost $10 more than the equivalent Maple ...

AFAIK, the only way to get the Bootloader into a 'raw' STM32F103 is programming it via JTAG (similar to burning the Arduino bootloader into a 'raw' ATmega, but JTAG is usually much more expensive than an AVR SPI programmer), or via the built in bootloader which uses the serial USART. So you could probably put a Maple bootloader onto a 'raw' STM32F103 that way. Pete Harrisons blogs talk about how he did it, but he used a low-cost JTAG.

HTH
GB-)

gbulmer

Thanks for that info...

I didn't think that the gnu download supported Cortex M3 yet, so you pretty much had to download from codesorcery... Is that no longer true?

I didn't think that the gnu download supported Cortex M3 yet, so you pretty much had to download from codesorcery... Is that no longer true?

Very good point. I'm pretty sure when I looked last year, it wasn't.

I've just checked at GNU GCC 4.5.0, Section 3.17.2 ARM Options and it says:

-mcpu=name
This specifies the name of the target ARM processor. GCC uses this name to determine what kind of instructions it can emit when generating assembly code. Permissible names are: arm2', arm250', arm3', arm6', arm60', arm600', arm610', arm620', arm7', arm7m', arm7d', arm7dm', arm7di', arm7dmi', arm70', arm700', arm700i', arm710', arm710c', arm7100', arm720', arm7500', arm7500fe', arm7tdmi', arm7tdmi-s', arm710t', arm720t', arm740t', strongarm', strongarm110', strongarm1100', strongarm1110', arm8', arm810', arm9', arm9e', arm920', arm920t', arm922t', arm946e-s', arm966e-s', arm968e-s', arm926ej-s', arm940t', arm9tdmi', arm10tdmi', arm1020t', arm1026ej-s', arm10e', arm1020e', arm1022e', arm1136j-s', arm1136jf-s', mpcore', mpcorenovfp', arm1156t2-s', arm1156t2f-s', arm1176jz-s', arm1176jzf-s', cortex-a5', cortex-a8', cortex-a9', cortex-r4', cortex-r4f', **[u]cortex-m3[/u]**', cortex-m1', cortex-m0', xscale', iwmmxt', iwmmxt2', `ep9312'.

So it looks like it is there in the current 4.5.0 release of gcc. A friend has said a lot of ARM stuff has been getting folded into the Linux kernel, so it may be that activity has pushed gcc along too.

I get the impression that the code sorcery version may be more up to date, but maybe that is the power of marketing. Certainly the code sorcery version was the one Pete Harrison at micromouseonline.com used last year.

HTH - GB-)

Now I'm thinking of making a few of these boards based on the schematic available

Be careful, anyone can plop a ARM chip on a board. Making the printed circuit board work is another matter.
The MIT boys took over one year to realize that they needed a 4 layer board (more $$$$ cost) to
reduce the noise and I/O crosstalk. I believe both the Cortino and the FEZ Domino are both 2 layer printed circuit boards (to save money) and they will have many future "unknown" problems with them? I know from 16 years of printed circuit board design that extreme care should be taken when designing a new high speed board.

Andy,

I read your other post on this after i had started this one and dropped the idea. I was thinking of a single-sided arm board then gave it up. you've got 16yrs of exp designing PCBs? bat-man pictures can be deceiving

[edit]bat-man pictures can be deceiving [/edit]

How so, the Batman has many years on many of us.

"The character first appeared in Detective Comics #27 in May 1939."

The MIT boys took over one year to realize that they needed a 4 layer board (more $$$$ cost) to reduce the noise and I/O crosstalk.

This sort of thing is one of the reasons that I never take all those "fast 32bit CPUs with lots of memory are cheaper than 8bit CPUs, so we might as well get rid of 8bit CPUs" comments very seriously.

Okay, picking your brains ...

Assuming it is mainly clock-speed that is the complicating factor, how much faster than 16MHz could one safely run a microcontroller at, using simple double-sided PCB's, and a bit of care routing the PCB? After all, quite a lot of the high-speed stuff is internal to the microcontroller.

For example, an NXP LPC1343, which is a 32-bit ARM Cortex-M3.
It is lower-cost than an ATmega328+FTDI, has USB on-board, has about 36 I/O's, 32K Flash, but 8K RAM, about 13 PWM, 8 ADC inputs, and it's ADC is upto 25x faster than an ATmega328. It also has a built in bootloader that makes it look like a small USB flash drive (USB mass storage device), so upload can be done with the file finder, (or open, write, close).

If I just ran that on 12MHz crystal, internally at, say 24MHz, would it be likely that a stable double sided PCB could be made? Assuming, the peripherals, like SPI, etc are run at, say only a couple of MHz?

I'm interested in learning for a practical reason, not just theoretical

GB-)

I'm interested in learning for a practical reason, not just theoretical

Well I was not a design engineer, but I did read a lot about digital speed increases (and the challenges they brought) over the decades as chips ran faster and faster.

One aspect, I think, is just raw edge transition speed. Even if you are only toggling a I/O pin at 1 mhz it's edge rise and fall times are determined by the fundamental internal chip clock speed, so likely to cause more problems when using a 80hmz chip then a 16mhz chip, no?

Lefty

One aspect, I think, is just raw edge transition speed. Even if you are only toggling a I/O pin at 1 mhz it's edge rise and fall times are determined by the fundamental internal chip clock speed, so likely to cause more problems when using a 80hmz chip then a 16mhz chip, no?

I can understand that as a reasonable position, but how do I derive an answer?

I can't find the spec for rise/fall-time for an ATmega, or the LPC1343, so let me try the STM32F103RB, as on a Maple.

I can find the rise/fall-time for the STM32F103.
I also see (in Table 19 of ST's document 13902) that the I/O pins can be configured for 50MHz, 10MHz, or 2MHz output. I've not found a good description of this yet, but I assume it is a bandwidth limiting mechanism (like some RS485 drivers).

Okay, so let's start by running the Cortex-M3 at 16MHz, using an 8MHz crystal. So it looks no worse than an ATmega328 with a 16MHz crystal.
Further, let's assume that the 10MHz does mean the rise time is bandwidth limited (and I'd be willing to go down to 2MHz if it makes the answer unambiguous).

Also, let's assume that the decoupling follows ST's design guidelines (which are intended for 72MHz operation).

1. Would it be likely that a stable double-sided PCB could be made for a 16MHz STM32F103RB with an 8MHz crystal?

2, What frequency might the internal speed of the Microcontroller go up to, on a well designed, but simple technology, double sided PCB, and remain stable?

Anyone able to offer some guidance what might be feasible, and what would help improve it (other than these articles Douglas Brooks Articles on PCB traces, temperatures, and signal integrity)?

GB-?

GB & Lefty .... :o :-[

Assuming it is mainly clock-speed that is the complicating factor, how much faster than 16MHz could one safely run a microcontroller at, using simple double-sided PCB's, and a bit of care routing the PCB?

I don't think you can make that assumption. "Maple" increased clock speed, increased board density (many more IOs than Arduino) and tried to increase A-D resolution, all at the same time. A tough job. And some chips are famous for being "noisier" than other chips, despite similar clock speeds. Good show on the Maple team actually paying attention to such things; I don't know if other would-be "improvers" take the same care.

And some chips are famous for being "noisier" than other chips, despite similar clock speeds.

Very interesting point. Thanks for the advice.

Might you suggest how I might discover this? My candidates are ST Micro STM32F and NXP LPC13xx or LPC17xx. I've been recommended SM32F by a very capable person, but he is using many-layer boards as his system is digital video (very high speeds).

Good show on the Maple team actually paying attention to such things;

Yes a wonderful example. I am very impressed.

I don't know if other would-be "improvers" take the same care.

I understand that I don't understand all of the difficulties, but I'd like to try to follow them. The Leaflabs Maple is an inspirational piece of work.

For some of the projects we'd like to try (like an onboard interpreter), it gets easier with single address-space, 32-bit machines and a good amount of RAM (64K+), though that won't be the first goal!

GB

Oh goodness, I have 668 posts, the next door neighbour of the beast

I was thinking of a **single-sided arm board **then gave it up.

If you would have made a single sided ARM board it would have been a "first" and would have never worked
to spec.

How so, the Batman has many years on many of us.

What? WestFw was in diapers when I was designing printed circuit boards ;D ;D ;D

WestFw was in diapers when I was designing PCBS

Heh. Not very likely
However, while I have designed some PCBs, I make no claims to being an actual PCB designer, especially when it comes to high-speed boards. Alas, I'm not alone. There are far too many "products" where someone plunked down a circuit, got some autorouter to connect all the signals, shipped the design off for near-automatic fabrication, and assumed it would just work... Sometimes it does! There are things I do with my board designs that I INTEND to help with high-speed behavior, and they seem to be more than other people do, but I don't have the "modify the design and actually measure the results" experience that it would take to actually have much confidence. (like, there seem to be competing opinions about "ground planes" vs "single point GND returns"... Sigh.)