High company expectations. What processors and languages did you teach yourself?

Hi Dig,

I can sympathise.  When I began to learn programming, microprocessors were just a dream.  I learned to program a PDP-11 computer, in assembly of course.  What I learned during the process was that each computer is basically the same, they just change the names of the various instructions to protect the guilty.

After that, I went on to program the TI-9900, the first 16-bit mircroprocessor.  From there, I spent time doing 8080, 8085, Z80, and a fair number of unique proprietary processors and DSP's.  In most cases, I had very primitive software development support and even less debugging capability.

The key to surviving all of the different processors is to learn one very well, then compare the next one to the one you know best.  In most cases, you will be able to quickly translate assembly instructions across devices.  If you are using C or another higher level language, then you need to assess what the compilers do to your code.  Some times that means you will need to dig into the assembly code.

In all cases, the boss wanted their code yesterday and I always faced a steep learning curve.  One method I learned to do was keep a tool box of code to do basic things like read and write certain ports and devices, sort of like the Arduino tutorials.  That way I could put together a box diagram flow of what tasks I needed to do and then just recode my standard code to fit the new processor.  If I had time, I would spend some time looking at optimizing the code, but in general, I spent the time getting the initial functions implemented.  Once you have a working unit, you may or may not get a chance to go back and clean up the code, but if it works and meets specifications, then you have done your job, albeit ineligantly.

In my experience, every new job entails a rapid period of research to learn the new tools/components that you will be working with.  The best way to parse the job is to look at your requirements and define what you need each component to do.  In many cases, that greatly reduces how much you need to learn about the component and in some cases, you can contact the supplier and get an application note on how to implement your task using their component.  If you get really lucky, they even give you some demo software that you can reverse engineer.

Given the pace of new device development, I do not see this problem getting better anytime soon.  Quite frankly, I have seen it accellerate over the years, but the tools you get have greatly improved since my early days.  I would have done anything to get something like the Code Composer that comes with the $4.50 USD MSP430 USB board.  Such a bountiful free compiler was just not possible then.

So I suggest that you get organized and keep focused.  Each new job will be an adventure.  Keep your sense of humour and patience.

Hope this helps.

DAB

Hi Dig,

I can sympathise.  When I began to learn programming, microprocessors were just a dream.  I learned to program a PDP-11 computer, in assembly of course.  What I learned during the process was that each computer is basically the same, they just change the names of the various instructions to protect the guilty.

After that, I went on to program the TI-9900, the first 16-bit mircroprocessor.  From there, I spent time doing 8080, 8085, Z80, and a fair number of unique proprietary processors and DSP's.  In most cases, I had very primitive software development support and even less debugging capability.

The key to surviving all of the different processors is to learn one very well, then compare the next one to the one you know best.  In most cases, you will be able to quickly translate assembly instructions across devices.  If you are using C or another higher level language, then you need to assess what the compilers do to your code.  Some times that means you will need to dig into the assembly code.

In all cases, the boss wanted their code yesterday and I always faced a steep learning curve.  One method I learned to do was keep a tool box of code to do basic things like read and write certain ports and devices, sort of like the Arduino tutorials.  That way I could put together a box diagram flow of what tasks I needed to do and then just recode my standard code to fit the new processor.  If I had time, I would spend some time looking at optimizing the code, but in general, I spent the time getting the initial functions implemented.  Once you have a working unit, you may or may not get a chance to go back and clean up the code, but if it works and meets specifications, then you have done your job, albeit ineligantly.

In my experience, every new job entails a rapid period of research to learn the new tools/components that you will be working with.  The best way to parse the job is to look at your requirements and define what you need each component to do.  In many cases, that greatly reduces how much you need to learn about the component and in some cases, you can contact the supplier and get an application note on how to implement your task using their component.  If you get really lucky, they even give you some demo software that you can reverse engineer.

Given the pace of new device development, I do not see this problem getting better anytime soon.  Quite frankly, I have seen it accellerate over the years, but the tools you get have greatly improved since my early days.  I would have done anything to get something like the Code Composer that comes with the $4.50 USD MSP430 USB board.  Such a bountiful free compiler was just not possible then.

So I suggest that you get organized and keep focused.  Each new job will be an adventure.  Keep your sense of humour and patience.

Hope this helps.

DAB