Build thread, 100 pin STM Arm Cortex board with driver chips.

I'm expecting to order 15 sample PCBs shortly, on a two week processing cycle.

I've added substantial ground planes, 12 volt plane, 5 volt plane and 3.3 volt plane areas.

I decided to fit an SMD SD-card connector to the PCB (sourced from Jaycar), and to leave my 10 pin header for custom expansion.

I have some local friends who are interested, and I'm thinking that I could use more than one here... the kids too, and I may do some arc erosion, which is possibly slower even than precision plastic extrusion.

I'm excited, I've spent a lot of time on the design, and the cost price per complete unit ought to be a lot less than that of the distributed design boards I've been seeing on here. That means that I can more easily afford multiple machines, and I can decide if I want to populate for 2 axis, 3 axis, 4 axis, how many transistor/mosfet outputs to use, whether to rely on a server PC, or to run off an SD card. I haven't made any expansion I/O boards for it yet, but it can do so much already, that the only thing I'm seriously lacking in, is a PCB to carry opto interuptors per axis. However, those can be soldered with fly leads and hot melt glued into place anyway.


Edited 3 time(s). Last edit at 04/08/2009 06:00AM by grael.

Finally,
I have something I can hold in my hands.
It's about 4/5 the height and width of a sheet of A4. Excellent quality reproduction, and the via holes all look very well aligned. I'll place an order tomorrow for the components I don't have, Hopefully I'll have enough parts by the weekend to start some programming [attachment 1513
GDCNCtopside.jpg]

I have one of the circuit boards populated now, all but for a LCD and the contrast potentiometer.

It took me a few goes to get the STM32 microcontroller working, in getting up to speed with KiCad, I had found out that KiCad copper fills are much easier to remove, than they are in the version of Protel I used to use. So, I had placed a small 3.3 volt fill on the top side, and then, thinking the KiCad fill was like that in Protel, I had tidied up some track that went in and out of the fill.
Later, when I removed the fill to make some alterations, my tracks that I'd "tidied up" lost their connectivity, and made it all the way to China, before coming back exactly to specification. Fortunately, one drill hole, and three back side short jumpers has fixed! that problem.

Soldering the brain in... I'd done a lot of work with AVR chips some years back, and the locating dot is on the top left corner, if you are veiwing with the writing the correct way up. I looked at the STM32 100 pin chip, and there was a dimple, but in a different position relative to the writing. looking more closely, it looked like an ejector pin mark as you see on injection moulded plastic items... I thought I would go be the writing, since I'd been looking at the chip that way up for a couple of months during the design process. However, the MCP1702 3.3 volt regulator was going into self protection mode, and only putting out around .7 of a volt Eventually, I figured out that everything else was perfect on my supply power after my jumper corrections, had to be the chip ! I soldered one in with the dimple by pin one, and it powered up properly

Next BIG TEST, was to try running the STMicroelectronics "Flash Loader Demo" program, as I'd made the decision to use the USART 2 Serial boot loader option, because it uses less external hardware than a JTAG programmer.

By now, I was a bit worried, but I connected up my EEEBOX via a USB to serial convertor, then hooked in a serial extension cable, then wired that to my circuit board. I booted to the STM boot loader program, checked the chip selection, and did a test Flash Erase. Success

Last night I went over all my pin assignments, correcting where I'd made improvements since my initial plans, so next is to start coding...

Set stack pointer,
Pin settings,
Turn on the external crystal,
Set all the pheripheral initialization modes to suit my application,
work out a memory map,

Then some more practical stuff:
routine to show status on my red and green LEDs,
routine to set audible response on the Piezo,
Set up some motion tables to control the stepper motor outputs, with PWM synchronization for intermediate stepping,
Set the ADC to run conversion on keypad, meltTemp, Temp2, the load sense resistors on the stepper motors, and also the axis limit inputs which have alternate analogue in functionality.
Configure PWM to run on the 5 x servo motors and the 4 x Stepper motors
Make some code to monitor the optical encoder inputs.
There are LOTS of PWM channels on the STM32 chips ! part of why I wasn't swayed by those suggesting I develop with a different manufacturer's arm cortex MCU
Program for the SD card socket, the USB and the LCD.

I'm used to assembler, but I think, that it's going to be easier to learn C in this case, as there is so much reuseable code I can use for this application if I do.

C, here i come

Graham,

Congrats on your progress with your STM32 Cortex board!
(I agree with you, as chip packages proliferate {and get smaller}, it's harder to be sure about where pin 1 is. Oh, for the good old unambiguous DIP packages....)

I haven't done much yet with my STM32 modules, mostly reading about the CPU, and building a USB -> serial rig for my laptop. Buying one would have been more time efficient, but where's the fun in that....

I think you'll like C, once you get the hang of it. The trick is not pulling out your hair while you're getting the hang of it.

FYI, here are some of the webpages I've been looking at re STM32 and Cortex M3:

A google-cache of a broken link (suggest you grab this before it goes away):
[74.125.47.132]

This is the html version of the file [www.danielecaltabiano.com].
Google automatically generates html versions of documents as we crawl the web.

----

[wiki.fosstronics.com]

all of the fosstronics wiki is good stuff: [wiki.fosstronics.com]


An online/downloadable book on the Cortex M-3:
[rapidlibrary.com]

Errata for the above book: [www.arm.com]

Best Regards,

Larry

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

Hi grael

I can recommend Bruce Eckel's 'Thinking in C' as a reference. [www.bruceeckel.com] Unfortunately it's really aimed at desktop computer programming, but it covers the basics well.

Additionally, you will probably want to use some form of operating system which will make it much easier to keep your different tasks in line. There are quite a few available, and I'm by no means an expert but FreeRTOS [www.freertos.org] may be good for you - it's light and free. Get comfortable with C before you begin playing.

Finally, C++ _might_ be better in the long run - object oriented languages work really well when describing, oh, objects - but it takes longer to get used to and is not available for many microprocessors.

Good luck

jbb

Hi Larry, JBB.
Thanks for the written support and tips !

Not sure if this will show as an in line image or not, but this is the assembled board, mounted via sticky standoffs on the side of my XP EEEBOX, on a PC PSU, on top of 13 more circuitboards. One blank PCB in the background. The USB is connected but dormant so far, the serial is connected to the EEEBOX via a USB to serial convertor (serial boot load), and my EEEBOX is networked via wireless, ready for when I take it down to the garage, eventually, to connect up to the 3-D motion frame.

On the left, you might see a sickly orange crescent, it's an STMcircle ! More gimmick than useful to me, I like to have lots of I/O !

I am working away at understanding C, the big effort at the moment, is going into finding the right working libraries for my project before I start meddling with power up states for the multiple on chip pheripherals. I don't think I'll be actually transferring any code for a week yet, not at the rate I'm currently going at !

Grael,
The best book to learn C from is, hands down, "The C Programming Language" by Brian Kernighan and Dennis Ritchie. Ritchie is the original author and implementer of C and is, therefore, the leading authority. This book is also known as "the white bible," which should give you some idea of how widely respected it is.

"Because the book was co-authored by the original language designer, and because the first edition of the book served for many years as the de facto standard for the language, the book is regarded by many to be the authoritative reference on C."

Honestly, I wouldn't look anywhere else. I tried when I was learning C. It was only when I read K&R that I actually started to get it.

Thanks Brendon,

I've seen many references to that book over the years, but not the book itself yet !

I'm feeling a lot better about the whole development process now anyway,

I have been going through the STM pheripherals, the remap process, the analogue to digital, the MMU, the interrupts, and it's all looking really good. Lots of features to make life easy and improve performance on this STM chip compared to what I've worked with before. Less code to achieve the same things, but better !
Features like arbitary ADC channel conversion order, triggered conversion from multiple source selection, independantly set timing (great for slow to settle high impedance channels following a channel inducing a charge onto the ADC internal circuitry) And pin interrupts configurable on multiple pin sources, any free GPIO as far as I can make out ! up to 12? or 16 inputs. I'll be using that to cut the workload on my encoder input option pins.

I did a lot of pin assignment planning, and it's going to pay off now, as I have the pheripherals all mapped, or remappable to the connected pin functions I chose.

I should be able to muddle through on default configuration settings by following the demos, and substituting my configuration, and then choose something simple to begin with on actual coding.
Graham.

Greetings all,

I agree that K&R is a great book; get the 2nd edition, unless there's an even later one now. I have several C texts, but that's the one that's right where I can get it. I even had my falling-apart copy rebound (rather than buy another) because the old one has all my margin notes and post-its marking places I continually refer to. (e.g. the page describing printf specifier syntax, near the back.)

Some aspects of C are a tad cryptic (e.g. pointers), but it's a great language for embedded systems, especially close-to-the-hardware programming.
However, it'll happily let you shoot yourself in the foot. (I once read a description programming languages in terms of cars and C was described along the lines of, "a souped-up Camero, with no seat belts.")

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

I found some on line C reference material by those authors, I'd actually browsed some of the history a few years beck, but it looks worth studying, thanks guys !
[cm.bell-labs.com]
[cm.bell-labs.com]

Hi Larry,
Pointers are one reason that I believe that people should start with an understanding of assembly language.

Graham,
As Larry points out, pointers are frequently poorly explained. Here's my best shot at it.


A computer program only ever stores a constant directly. That is, constants are frequently tacked on to the end of an instruction. Variables are not. A variable is stored at some location in data memory. So to operate on that variable, the program must first load the variable into a working register. Some processors have only one working register, called an accumulator.

In short, a variable which is stored in memory is always accessed via its address.

A pointer is simply adding one more step to this process. Your program stores an address as normal. However, instead of loading the value you want from the location at the address that your program stores, it finds a second address there. It follows the second address, which is where it finds your variable.

That is all there is to pointers. How and why to use them is more complex than what they are, but people get awfully caught up on what they are, so I hope that helps.

Hi Brendon,
To date, my embedded programming was 98% assembly, so I know pointers, table jumps etc. Generally, I coded them in manually. It's getting to grips with C syntax that I'm working on now, that, and figuring my way through Raisonance's include files. Things like tracking down why GPIOB definitions work in main.c, but GPIOA definitions don't. Getting to know the library functions and C assembly directives well enough to track down why definitions in stm32f10x_map.h don't appear to be turned on where I need them to be, and how to do it. Simple stuff for those of you who've been working on it for some time, but new and frustrating to me.

Pointer syntax will get me, I'm sure. It's a question of what I study first though... some things you can look at a working example and easily tweak, others have less obvious implications that will break a build untill they are properly understood.

I'm running into issues like finding unfamiliar syntax and not knowing if it's compiler specific, C common usage, or variable name with non alphanumeric characters !

Hopefully I will bluster my way through it enough this weekend to make some IO change state on my board.

Weekend almost gone, but I'm making progress.

I got a working program to toggle the state of my status LEDs.
I extended it to control the piezo.

I extended it to control 3 of the 5 darlington transistors, but it wouldn't turn on the last two.

After about 6 hours of research, I found a first, and then second configuration setting to turn the JTAG port off successfully, and thereby allow GPIOB pins 3 and 4 to drive out, then my last transistors powered up >< Complex chip... lots of configuration settings !

I'm still testing out hardware connections via the ARM, next is getting some very simple stepper motor full and half stepping trialed, at this stage, only in a main loop.

I have polyswitch fuses on each winding pair, so it will be interesting to see what current they actually kick in at, theoretically 3 amps, and release at 1.5, but they are a small SMD package, and it will be interesting to see them actually in operation. Should save me some smoked chips and motors down the line... the L298 motor drivers are rated at 2 amps continous, 4 amps peak, but I haven't got them fully heatsinked at this stage.

My own test XYZ machine is relatively heavy, it's going to be a test just to see if it moves yet !

Can't wait to get some motion running !

As my first circuit board appears to have operational hardware, I am now shifting focus on the build process over to the software forum on a new thread in the software forum, where you will also find the full hardware specification:
[forums.reprap.org]

Graham Daniel.

I never got the hang of pointers, although I did avoid them like the plague. One thing I'd recommend with C is to get your head round data types and data structures. They are both awesome and powerful tools!

Massive board there, that must have cost a lot to get fabbed up. On another thought Wouldn't it have been better for you to make seperate boards for each major function? A Stepper board, a Coms board etc? That way if you muck up a Coms trace you don't need to bin an entire board just a sub-board? Just my £0.02.

Looks amazing, keep up with the pretty pictures!

Annirak Wrote:
-------------------------------------------------------
> Hi Larry,
> Pointers are one reason that I believe that people
> should start with an understanding of assembly
> language.
>
> Graham,
> As Larry points out, pointers are frequently
> poorly explained. Here's my best shot at it.
>
>
> A computer program only ever stores a constant
> directly. That is, constants are frequently
> tacked on to the end of an instruction. Variables
> are not. A variable is stored at some location in
> data memory. So to operate on that variable, the
> program must first load the variable into a
> working register. Some processors have only one
> working register, called an accumulator.
>
> In short, a variable which is stored in memory is
> always accessed via its address.
>
> A pointer is simply adding one more step to this
> process. Your program stores an address as
> normal. However, instead of loading the value you
> want from the location at the address that your
> program stores, it finds a second address there.
> It follows the second address, which is where it
> finds your variable.
>
> That is all there is to pointers. How and why to
> use them is more complex than what they are, but
> people get awfully caught up on what they are, so
> I hope that helps.

Almost there, most processors have 2 types of register Value and Address.

The pointer will exist in the address register, this is where it can get complicated and varies between processor.

Some will copy the value into the local registers, others will perform the action directly on ram/cache.

Moving from assembly to C shouldn't be hard, if anything going from RISC Assembly to C should be much easier than the other way around.

Majority of the concepts are very similar.

I would suggest you only use pointers where large amounts of data need to be moved around, such as structures and arrays, this makes it easier for you to initialise everything.

The Fallen:

The high integration keeps costs down, as it reduces interconnections and component counts.



annodomini2:
"structures" have an equivalent in visual basic that I've used before, definitely useful.

I've use the AVRs quite a bit, both AVRs and PICs easily do table jumps too, similiar to a select case statement in VB, or switch case in C.

Now I have some working code, my main challenge is utilising the STM library functions, which I don't consider to be sufficiently well documented.

Graham

Fair enough, good luck battling your way through those library functions.

Greetings all,

annodomini2 Wrote:



> Almost there, most processors have 2 types of
> register Value and Address.


The Cortex architecture doesn't have this (IMHO, unhelpful) separation. Cortex registers can hold either a pointer or a value. So, one can load the contents of a pointer (in a register) into that same register. (This assumes that the contents will fit; if the contents are a double-precision float or a long structure, you'd only get the first chunk.)

I sheepishly admit that I still don't have my Cortex board talking, even at the bootloader level. I seem to have a problem with my serial interface, and will have to put a 'scope on it to see what's misbehaving. Grrr....



-- Larry

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

Larry_Pfeffer Wrote:
-------------------------------------------------------
> Greetings all,
>
> annodomini2 Wrote:
>
>
>
> > Almost there, most processors have 2 types of
> > register Value and Address.
>
>
> The Cortex architecture doesn't have this (IMHO,
> unhelpful) separation. Cortex registers can hold
> either a pointer or a value. So, one can load the
> contents of a pointer (in a register) into that
> same register. (This assumes that the contents
> will fit; if the contents are a double-precision
> float or a long structure, you'd only get the
> first chunk.)
>
> I sheepishly admit that I still don't have my
> Cortex board talking, even at the bootloader
> level. I seem to have a problem with my serial
> interface, and will have to put a 'scope on it to
> see what's misbehaving. Grrr....
>
>
>
> -- Larry

Does the cortex have an FPU? Not really had much exposure to ARM chips

annodomini2 Wrote:



> Does the cortex have an FPU? Not really had much
> exposure to ARM chips


The Cortex M3 (and M0) do not have an FPU. (Not sure about the other variants, like the A-series, as used in the beagle board.) The full ARM architecture (most modern versions, such as the ARM9) define a co-processor interface, and they can use that to communicate with a conceptually-separate FPU co-processor -- if one is attached. I'm not sure how popular implementations with the FPU included really are. My exposure has been mostly on the low end of the ARM spectrum, except for scanning the trade lit.

However, the Cortex implements some things that (I strongly suspect) will yield floating-point that runs rings around the AVR:
Barrel shifter,
Some special instructions (like count leading zeros),
that should make soft (in software) floating point calcs go pretty fast.

One nice thing about the cortex is that it has a *divide* instruction.
Some versions of the ARM arch did not! It got "RISC-ed out" of the design, and one had to do division in software. I guess the silicon has now gotten cheaper and/or the RISC purists lost out to programming pragmatists.
And there was great rejoicing.... ;-)

-- Larry

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

Hi all.

I had a look around a while ago for a micro with an FPU, and they're not easy to find. If you move to bigger ARMs (ARM9, ARM11), you can definately get one but you end up stuck with a BGA (Ball Grid Array) package which is very difficult to deal with. Texas Instruments make some in their C2000 microprocessor range, but you need expensive software, programmer etc.

In this case, I expect that you won't really need floating point: 32 bits yields plenty of resolution.

jbb

Larry,
some simple checks to do:

The dimple IS the mark that looks like an ejector pin, that's pin one, and it's the wrong way around compared to an atmel chip, from the writing.

Check your power consumption on the 3.3 volts to the STM32, if it's more than 20mA or so, with an unprogrammed chip, then you have misconnections (see above)

The gnd and power pins need to all be connected to the right levels *externally*
I'm not sure if the download program need correct status on CTS, I put a CTS pull up on my logic side of the MAX202 just in case.

Other than that, I can empathise with your frustration.

JBB,

agreed, you can do a lot of manipulation in 32 bits, As an integer, that's 0 to 4294967296. I think that gets you just over 17 kilometer's worth at 1 thou accuracy !

On the subject of later ARM chips, have you looked at building something around the BeagleBoard. It is in many ways the ARM equivalent of the Arduino in that it is Open Source. It also runs an operating system (linux by default) for which many development environments already exist and are readily available.

David

Larry_Pfeffer Wrote:
-------------------------------------------------------
> annodomini2 Wrote:
>
>
>
> > Does the cortex have an FPU? Not really had
> much
> > exposure to ARM chips
>
>
> The Cortex M3 (and M0) do not have an FPU. (Not
> sure about the other variants, like the A-series,
> as used in the beagle board.) The full ARM
> architecture (most modern versions, such as the
> ARM9) define a co-processor interface, and they
> can use that to communicate with a
> conceptually-separate FPU co-processor -- if one
> is attached. I'm not sure how popular
> implementations with the FPU included really are.
> My exposure has been mostly on the low end of the
> ARM spectrum, except for scanning the trade lit.
>
> However, the Cortex implements some things that (I
> strongly suspect) will yield floating-point that
> runs rings around the AVR:
> Barrel shifter,
> Some special instructions (like count leading
> zeros),
> that should make soft (in software) floating point
> calcs go pretty fast.
>
> One nice thing about the cortex is that it has a
> *divide* instruction.
> Some versions of the ARM arch did not! It got
> "RISC-ed out" of the design, and one had to do
> division in software. I guess the silicon has now
> gotten cheaper and/or the RISC purists lost out to
> programming pragmatists.
> And there was great rejoicing.... ;-)
>
> -- Larry

Was just curious, Floating point IMHO is for OS work or people who don't know how to write software.

But if the processor registers cannot handle the values there's no logical point to having FPU.

divide operation is always useful as typically you end up fighting the compiler optimiser for best run time.

I've looked at the beagle board,
It could actually do quite well as a low cost, low power server, but intel have stepped up their game with the atom processor, which is big for the embedded market, on higher spec functionality.

The beagle board is ARM based, and a fast one at that, but what concerns me, is the life cycle of the chip. I could see it being used in at least one big application, but it's got a lot of functionality on that chip which seems unique, plusses on one hand, but messy to replicate on the other.

Chips like the Z80 and the 68HC11 have been around for decades, but most chips are superceeded within 6 months of release, if not less, these days.

If the beagle board gains wide acceptance, then it may be a stayer too... next generation, less silicon, same functionality, faster, less price. could work...

grael Wrote:
-------------------------------------------------------

> The beagle board is ARM based, and a fast one at
> that, but what concerns me, is the life cycle of
> the chip. I could see it being used in at least
> one big application, but it's got a lot of
> functionality on that chip which seems unique,
> plusses on one hand, but messy to replicate on the
> other.
>


ARM chips are used in many embedded devices, including Cel/Mobile phones, you will probably have a few in your home or workplace.

They are well established, reliable and cheap. exactly what you want for a project like this.

Thanks for approving my choice of generic chip type for my own board design ! ><

grael Wrote:
-------------------------------------------------------
> I've looked at the beagle board,
> It could actually do quite well as a low cost, low
> power server, but intel have stepped up their game
> with the atom processor, which is big for the
> embedded market, on higher spec functionality.
>
> The beagle board is ARM based, and a fast one at
> that, but what concerns me, is the life cycle of
> the chip. I could see it being used in at least
> one big application, but it's got a lot of
> functionality on that chip which seems unique,
> plusses on one hand, but messy to replicate on the
> other.
>

The beagle is just a low cost dev board for the OMAP 3430 chip, which is in loads of things (Nokia tablets, openpandora). By the time you get up to that kind of power though you might as well run Linux on there and run all the RepRap stuff as applications. By doing this you don't have to worry about changing cores, you just build your app, and it should always work.

It would be nice having a RepRap that you can dump gcode files onto from the network, then control it from ssh. There is also an SGX graphics core and a DSP in the OMAP chip, but they probably wouldn't need to be used.
> Chips like the Z80 and the 68HC11 have been around
> for decades, but most chips are superceeded within
> 6 months of release, if not less, these days.
>
> If the beagle board gains wide acceptance, then it
> may be a stayer too... next generation, less
> silicon, same functionality, faster, less price.
> could work...

hey guys,

well am new to this thread and basically i want ho have some information regarding ARM 9 boards. If anyone who has used any ARM 9 board then please suggest some good board with minimum 2 USB ports and a serial port. Also I am planning to interface USB and DB 9 sO can anyone help me with that too as this is for the first time am working on USB peripheral. So please help me and mail me if you have any information.

I really appreciate it.

tak care...!!!

Cheers...