chicken before egg before chicken before egg before...

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.