I've been a bit quiet on here lately, but I thought it was time for an update.
I could be silent about the difficulties I face, and present the "business is good" smiling face of a salseman, but hey, this is real life, and you have to crack eggs to make the omlette !
Firstly, when I designed the board, I'd intended to run it with MOSFETs for my general purpose power outputs. However, when I looked up the specifications of the MOSFETs I still had a part tube in stock of from some years back, my suspicion was proved right, that their gate drive requirement was too high. For some strange reason, I decided to use darlington transistors, which were pin compatible, but I forgot that the base can sink a lot of current. All went well,until I decided to try ramping the PWM output on a motor that will take around 10 amps, as the ramp speed built up, I overloaded the darlington transistor, and it fed back a nasty spike to my arm microcontroller, and cooked it. :(
At that point, I realised that I hadn't designed in base resistors either, because I didn't need them when driving MOSFETs !
So... I flamed the centre of the chip until I could lift it off.
By this time, my first board was getting a little bit too much action around the fragile 100 pin TQFP package traces, and some were starting to lift off.
My attempt at resoldering a new arm onto the same footprint didn't go particularly well, so I started a new board, while also hunting for my super magnifying goggles, which took a while to surface.
Eventually, I found my goggles, by which time I'd partially assembled a new board.
By the time I'd tidied up my PCB traces and alligned them , improving with each session, I felt like a highly skilled surgeon, only without the Kudos, the nurses to hand me forceps etc, and without any sign on the horizon of even a smidgeon of a surgeon's generous sallary package.
Currently, I have my original board, of which a couple of the stepper motor control traces may or may not work since my last microsurgery, and my new board, which seems to be all good so far.. brand new components, all tested so far, in good working condition.
However, I designed in USB and SD card functionality to my hardware, and it's pretty pointless loading up a coordinate file, or gcode file into flash or the microcontroller to prove my stepper motors work, that's not a deterministic test.
Determinism is the stuff that happens in real life, not on someone's test bench. Determinism, when I read about it many years ago in an excellent book called "The Holographic Paradigm", is basically the theory that if you want to know how something will turn out in real life, the very best simulation requires maximum similarity to the actual situation, an is in fact, tha actual situation itself ! A bit tough for people like weather forecasters, but they do the best they can.
So, I started on merging the USB Virtual com port project with my project.
EEEEK !!!!@$!@# ! ~~~~ incompatible libraries !!!
After a late night edit of some source files to try and achieve a degree of compatibility, when I wasn't at my freshest either, I broke my project.
So, where I'm at now, is I have a working backup prior to the attempted merge, and lots of my own new code which also runs fine when it's got coherent source libraries.
I've decided that the best way to progress now (after going to Jaycar and picking up some more USB printer sockets and SD cards SMD sockets), is to use the USB Mass_Storage sample project, and get that working on my custom hardware, that way, I have the most difficult (to me) part of the whole project running, and then I can take my custom code (which I know), and merge that to the USB Mass Storage project instead.
Until I have the USB code working, I can't test out gcodes sent from my PC,so it's pointless writing the gcode processing routines yet, the way I see it.
Wednesday, July 8, 2009
Monday, June 15, 2009
After some frustration, I have the smallest amount of progress, and thought I'd post it. Others may have similiar issues.
I've been having issues with the bootloader which can be configured to automatically reset the STM32 chip in flash mode, without the need to change the chip from bootload mode to flash mode and then push the reset button. In my case, a lot of the times after my code changes, the chip doesn't boot from the bootloader, and I have to change to flash mode and reset.
I'm pretty sure that the problem is with the C "linker" that was default for my project, so I've been looking off an on over the last several days for the linker script file, which is supposed to tell the C compiler where the different variables, constants, RAM based and Flash based code should be put within the STM32's 4 GB potential address space.
In my project, there is a default link file enabled, and I searched on it a couple of times, trying to find it so I could check the file contents and settings. Alas, it was reported not found by windows file search program.
Today, I did a more exhaustive manual directory search, and found some of the Raisonance sample projects have a normal link file, and some have a .elf.ld link file. This will be due to the different memory usages ofthe different Raisonance code samples.
I kept looking, and found a generic script file that was almost the same as that in the project defaults, only with the second and third letters of the file name transposed.
Just one small, but infuriating little error. I don't know that I would have the patience to develop on a platform like this if I was younger, and had not had the winning experiences I've had with assembler in 8-bit microcontroller platforms, but I don't loose sight of the promise at the end of this project. The C language itself is not bad, it makes a lot of use of symbols in a tightly packed manner, and so you can end up having an extremely dense piece of code fitting into one line, but then you can end up surrounding it with a { on the preceeding line, and a } on the line following to tidy the look of your code. Weird.
So, I now know where the linker configuration file is, and what it's real name is, I can move it to my project directory and fiddle with it. There's a lot of waffle in it...*
I've been having issues with the bootloader which can be configured to automatically reset the STM32 chip in flash mode, without the need to change the chip from bootload mode to flash mode and then push the reset button. In my case, a lot of the times after my code changes, the chip doesn't boot from the bootloader, and I have to change to flash mode and reset.
I'm pretty sure that the problem is with the C "linker" that was default for my project, so I've been looking off an on over the last several days for the linker script file, which is supposed to tell the C compiler where the different variables, constants, RAM based and Flash based code should be put within the STM32's 4 GB potential address space.
In my project, there is a default link file enabled, and I searched on it a couple of times, trying to find it so I could check the file contents and settings. Alas, it was reported not found by windows file search program.
Today, I did a more exhaustive manual directory search, and found some of the Raisonance sample projects have a normal link file, and some have a .elf.ld link file. This will be due to the different memory usages ofthe different Raisonance code samples.
I kept looking, and found a generic script file that was almost the same as that in the project defaults, only with the second and third letters of the file name transposed.
Just one small, but infuriating little error. I don't know that I would have the patience to develop on a platform like this if I was younger, and had not had the winning experiences I've had with assembler in 8-bit microcontroller platforms, but I don't loose sight of the promise at the end of this project. The C language itself is not bad, it makes a lot of use of symbols in a tightly packed manner, and so you can end up having an extremely dense piece of code fitting into one line, but then you can end up surrounding it with a { on the preceeding line, and a } on the line following to tidy the look of your code. Weird.
So, I now know where the linker configuration file is, and what it's real name is, I can move it to my project directory and fiddle with it. There's a lot of waffle in it...*
Tuesday, June 9, 2009
How Graham decided to make better Jet units for his RC boats:
This blog is, at the moment ! dedicated to my motherboard design for a 3D materials processing machine.
I started this as a 2009 new year's project, and by the end of January 2009, I made the decision (having built the 3D stage), that I didn't want to buy a soon to be obsoleted circuit board to control it. Having been previously in business for myself as an electronics and software engineer, to proceed, my next step was to design my own circuit board.
This is what I came up with:
You can see at top right, the axis power electronics for 4 x stepper motor control, with 2 coils each, and 2 connections to each coil !
Down the left side, from top to bottom, are:
The grey looking square in the middle bottom position is the brain, an ARM Cortex M3 16/32 bit processor. It's great great great great great great great "it" was the acorn archimedes ARM, a much aclaimed microcontroller that was superior to the Intel x86 chips of the day, but not marketed as sucessfully. In interesting trivia, one of the main designers of the chip was "gender reassigned" and became female. Since then, ARM has undergone changes, and is now marketed as IP to big Silicon chip manufacturing companies.
STMicroelectronics, a company that seems to specialise in maximising I/O flexibility of it's product offerings, joined in, in utilising the Arm Cortex M3 core for products of it's own fairly early on, and I'm using their STM32F103VBT for my circuitboard.
In addition to the features I listed above, I also implemented these:
2 x position encoder channels (each channel uses two sensors)
2 x dedicated analogue voltage inputs, intended for temperature monitoring.
1 x Piezo with direct drive. You can actually play tunes on the stepper motors, but it's slightly more tricky to do if you don't want the stepper motors to actually move out of position !
5 x Servo control outputs, also configurable for other purposes if enabled as such in the software.
1 x LCD connector, for common 4 wire data mode.
1 x SD Card socket, for stand alone 3D model building operation.
1 x RS232 connection for loading the firmware, and available for debugging, diagnostics, or reporting purposes.
1 x RS485 connection for slave devices, or daisy chaining more of the same.
Anyway, those were the goals !
I designed to use the L298 chip, which is good for 2 amps continous. I decided to do that, because it handles the majority of small stepper motor control applications, and in that way, increases the potential volume traded of standard type circuitboards. That helps on both standardisation, and cost.
Most people use a decoder chip, like the L297 to interface between the brain on the circuitboard (the microcontroller or uC for short), and the power output hardware (the L298), but in my case, I decided to control the L298 directly, which allows for some tricks, I can potentially send wave forms via PWM to the stepper motors for smoother movement, and with sub steps inside what would otherwise be available.
The picture above was just the "artist's impression", generated by KiCad as a 3D view of the known components 3D shapes.
Anyway, I completed the design, and sent the plans to PCBCART in Hong Kong.
A couple of weeks later (I used the no-hurry-schedule ordering option), I got fifteen circuitboards from them:
It took me a couple of weeks to get all the components together to make the first one, and this is what it looked like:
You can see it at the right, perched on the EEEBOX that I bought for it, as a Windos server.
I use Linux otherwise, but it's quite messy getting started with ARM C programming, and so I used a better known environment. The EEEPC is low powered as Intel computers go, it uses an Atom processor, and isn't much good for keeping hands warm on cold winter nights.
Next was software !
I got the stepper motors running after taking some time to learn C (I used to use assembler only, on the embedded microcontroller end), and some battles to get the tool chain doing what I wanted it to. Pulse width modulating the steppers was second, and then applying the PWM to the coils independently in a wave form. I have that now, but at the moment only as a crude 1/2 steps between the 4 full power positions.
Next, (and up to date progress), was the LCD !
I got that working tonight, the picture's a bit dark, but you can see it on the bottom right hand side:
End of the day's post !
I started this as a 2009 new year's project, and by the end of January 2009, I made the decision (having built the 3D stage), that I didn't want to buy a soon to be obsoleted circuit board to control it. Having been previously in business for myself as an electronics and software engineer, to proceed, my next step was to design my own circuit board.
This is what I came up with:
You can see at top right, the axis power electronics for 4 x stepper motor control, with 2 coils each, and 2 connections to each coil !Down the left side, from top to bottom, are:
- PWM transistor outputs 1 to 5
- RS485 expansion
- I2C expansion
- Keypad
The grey looking square in the middle bottom position is the brain, an ARM Cortex M3 16/32 bit processor. It's great great great great great great great "it" was the acorn archimedes ARM, a much aclaimed microcontroller that was superior to the Intel x86 chips of the day, but not marketed as sucessfully. In interesting trivia, one of the main designers of the chip was "gender reassigned" and became female. Since then, ARM has undergone changes, and is now marketed as IP to big Silicon chip manufacturing companies.
STMicroelectronics, a company that seems to specialise in maximising I/O flexibility of it's product offerings, joined in, in utilising the Arm Cortex M3 core for products of it's own fairly early on, and I'm using their STM32F103VBT for my circuitboard.
In addition to the features I listed above, I also implemented these:
2 x position encoder channels (each channel uses two sensors)
2 x dedicated analogue voltage inputs, intended for temperature monitoring.
1 x Piezo with direct drive. You can actually play tunes on the stepper motors, but it's slightly more tricky to do if you don't want the stepper motors to actually move out of position !
5 x Servo control outputs, also configurable for other purposes if enabled as such in the software.
1 x LCD connector, for common 4 wire data mode.
1 x SD Card socket, for stand alone 3D model building operation.
1 x RS232 connection for loading the firmware, and available for debugging, diagnostics, or reporting purposes.
1 x RS485 connection for slave devices, or daisy chaining more of the same.
Anyway, those were the goals !
I designed to use the L298 chip, which is good for 2 amps continous. I decided to do that, because it handles the majority of small stepper motor control applications, and in that way, increases the potential volume traded of standard type circuitboards. That helps on both standardisation, and cost.
Most people use a decoder chip, like the L297 to interface between the brain on the circuitboard (the microcontroller or uC for short), and the power output hardware (the L298), but in my case, I decided to control the L298 directly, which allows for some tricks, I can potentially send wave forms via PWM to the stepper motors for smoother movement, and with sub steps inside what would otherwise be available.
The picture above was just the "artist's impression", generated by KiCad as a 3D view of the known components 3D shapes.
Anyway, I completed the design, and sent the plans to PCBCART in Hong Kong.
A couple of weeks later (I used the no-hurry-schedule ordering option), I got fifteen circuitboards from them:
It took me a couple of weeks to get all the components together to make the first one, and this is what it looked like:
You can see it at the right, perched on the EEEBOX that I bought for it, as a Windos server.
I use Linux otherwise, but it's quite messy getting started with ARM C programming, and so I used a better known environment. The EEEPC is low powered as Intel computers go, it uses an Atom processor, and isn't much good for keeping hands warm on cold winter nights.
Next was software !
I got the stepper motors running after taking some time to learn C (I used to use assembler only, on the embedded microcontroller end), and some battles to get the tool chain doing what I wanted it to. Pulse width modulating the steppers was second, and then applying the PWM to the coils independently in a wave form. I have that now, but at the moment only as a crude 1/2 steps between the 4 full power positions.
Next, (and up to date progress), was the LCD !
I got that working tonight, the picture's a bit dark, but you can see it on the bottom right hand side:
End of the day's post !
Subscribe to:
Posts (Atom)
