where to start? AVR/ARM/PIC .....

[carl0s]

I used to work with the Atmel ATmega128 and I liked the chip a lot.  I worked under Linux so I was using avr-gcc and some form of serial programming (I have forgotten, it's been more than 15 years).  I thought the datasheet was adequate, avr-libc was well  implemented and bare hardware projects were quite straightforward.

But it was bare hardware, nothing like DigitalWrite existed.  Nor should it.

Today, everything seems to be wrapped up in some form of HAL.  You can blow it off but some of the chips are so complex you almost have to use it.  Then there is CubeMx for the STM32F series and this helps assign pins generates some code for using the various peripherals.  Not bad but not bare hardware either.  The code isn't as grim as Arduino but there is a ton of source code in the library so a lot of details are hidden.

So many choices...

I think I would start with "Mastering STM32" and just work through the book.  It begins with install the GCC toolchain and Eclipse (the IDE) and walks the user through just about everything that can be done with the devices.  It is available as an eBook (which I have) but the FULL copy is available here:

https://leanpub.com/mastering-stm32

Note that excerpts on the web are not the full copy.

I think ARM is the way to go, now and into the future.  Every chip manufacturer has one or more devices based on ARM technology so it's going to be here for awhile.  That's a much different story than the single source devices such as PIC and ATmega.

But the book, follow the yellow brick road and things should work out pretty well.

I agree, Carmine Noviello's Mastering STM32 is a great book. I've barely scratched the surface, but it covers all the right stuff.

Only thing I would say, is that the early-on chapter about installing and configuring your IDE/toolchain (configuring/installing the Eclipse IDE and OpenOCD debugger/programmer) can be mostly skipped, and you should just use Atollic TrueStudio instead, since ST bought that and it's now free for users of STM32 chips.

[Mr. Scram]

Atmel Studio (Windows only) would be a logical next step. Do away with the Arduino (IDE and) library/code and program your existing hardware (Arduino boards etc) bare metal. Learn to read the data sheet of the Atmega chips and learn (more/better) C (not C++ *). C is mainly used in ARM so get comfortable with that.

When you are comfortable with this, then you go to ARM (where the data-sheets are order of magnitude longer). You will need to learn either to program bare metal (you need that 'read long data-sheets' skill here) and/or to learn new tools and libraries (HAL etc). At this point C would be more often used and should not be a problem. Buy simple cheap hardware at first (blue pill) to get your feet wet.

[2c]

*) I am not a fan of C and think (a subset of) C++ is almost always a better choice. But fact is most use C.

I agree. Build upon what you know and expand. Going the Atmel Studio route makes a lot of sense.

[westfw]

if you write in C, you can compile and test parts of your code on PC. This may be easier/faster than testing it in hardware.

This may be helpful for very high level projects but, as yet, I haven't done one of them

Really?  I mean, I write relatively small amounts of microcontroller code, and I consider it to be pretty "deep infrastructure" compared to what a lot of people do, but I have both a command-line parser and menu system that I debugged mostly on the PC side...

[Mr. Scram]

I used to work with the Atmel ATmega128 and I liked the chip a lot.  I worked under Linux so I was using avr-gcc and some form of serial programming (I have forgotten, it's been more than 15 years).  I thought the datasheet was adequate, avr-libc was well  implemented and bare hardware projects were quite straightforward.

But it was bare hardware, nothing like DigitalWrite existed.  Nor should it.

Today, everything seems to be wrapped up in some form of HAL.  You can blow it off but some of the chips are so complex you almost have to use it.  Then there is CubeMx for the STM32F series and this helps assign pins generates some code for using the various peripherals.  Not bad but not bare hardware either.  The code isn't as grim as Arduino but there is a ton of source code in the library so a lot of details are hidden.

So many choices...

I think I would start with "Mastering STM32" and just work through the book.  It begins with install the GCC toolchain and Eclipse (the IDE) and walks the user through just about everything that can be done with the devices.  It is available as an eBook (which I have) but the FULL copy is available here:

https://leanpub.com/mastering-stm32

Note that excerpts on the web are not the full copy.

I think ARM is the way to go, now and into the future.  Every chip manufacturer has one or more devices based on ARM technology so it's going to be here for awhile.  That's a much different story than the single source devices such as PIC and ATmega.

But the book, follow the yellow brick road and things should work out pretty well.

Even Jack Ganssle doesn't think going too low level on ARM is sensible. I have to add he was talking about assembly, but the point is the same. Trust the compiler and prevent life from becoming unbearable.

[rstofer]

if you write in C, you can compile and test parts of your code on PC. This may be easier/faster than testing it in hardware.

This may be helpful for very high level projects but, as yet, I haven't done one of them

Really?  I mean, I write relatively small amounts of microcontroller code, and I consider it to be pretty "deep infrastructure" compared to what a lot of people do, but I have both a command-line parser and menu system that I debugged mostly on the PC side...

I can see where developing a parser would be easier on the PC side.  Even the menu system makes sense if it is particularly complex.

For me, it hasn't come up.  Very few of my embedded projects involve users.  My last big mbed project was just a simple bit of code to take plotter step commands (100 per inch of motion) from FPGA CPU project via SPI, repackage them into HP PCL sentences and send them out over TCP to a LaserJet.  The only complex bits were in gaining access to the two 16kB buffers that are normally dedicated to USB and Ethernet so I could use them for the data buffer/queue and dealing with the NVIC so my SPI could be interrupt driven.  Pretty straightforward stuff.  It's been running nearly 7 years at this point.

[legacy]

repackage them into HP PCL sentences and send them out over TCP to a LaserJet

amazing! what is that engine's purpose? sort of printer? plotter?

[rstofer]

repackage them into HP PCL sentences and send them out over TCP to a LaserJet

amazing! what is that engine's purpose? sort of printer? plotter?

The IBM 1130 (my first computer) had a Calcomp 565 plotter badged as an IBM 1627 plotter.  The plotter accepted 6 bit commands which represented both motion and pen control (Pen Up, Pen Down, X+, X-, Y+, Y-).  Each motion command moved the pen 0.01" in the appropriate direction (vertical, horizontal, 45 degree diagonal).  The plotter library worried about how to interpolate a line segment (and there are a lot of line segments in text strings).

This was pretty heady stuff in '70..'72 when I had unlimited access and got to hang out with aircraft designers, and other engineers while still a lowly undergrad.  Oddly, there was only one other group making extensive use of the two machines and we were the only people using the plotters.  I think the department head was happy to have me use his machines because it helped justify their purchase!

I also had a copy of the IBM Electronic Circuit Analysis Program (ECAP), one of the early circuit analyzers.  What it lacked was output to a plotter.  It could save the results to punch cards (I believe) and, one way or the other, I hooked it to the plotter.  My Bode' plots were pretty realistic.  Homework was a lot more fun.  Oh, and we had log-linear and log-log paper - very cool!

http://ibm1130.org/hw/io/

The goal of my IBM1130 emulation is to run all IBM software unchanged.  That's the driving criteria - unchanged!  There is no way I want to patch a 27 pass Fortran compiler written in assembly language.

The mbed task is pretty simple (in concept):  If the pen is up, the code arithmetically accumulates steps in all directions until the pen is commanded down.  The code then generates a single PCL sentence to move the LaserJet 'pen' to the appropriate position and lowers it.  If the pen is down, the code still accumulates steps as long as they are in the same direction.  When the direction changes or the pen is lifted, the code generates a PCL sentence for the LaserJet 'pen' to draw the line segment and lift the pen (if commanded).  So it takes just 4 sentences to draw a box regardless of size but the real plotter had to deal with 100 steps per inch of the box perimeter.

The LPC1768 mbed has 2 16kB reserved memory blocks.  I used one to enqueue the incoming motion steps from the FPGA via SPI and the other to build and enqueue packets for TCP transmission.  The packets are around 512 bytes (I always complete a sentence even if it runs a bit beyond 512 bytes).

I have attached a scan (.pdf) of a typical plot.  This particular problem was encountered in one of my grandson's early algebra classes and I added a bit of calculus (slope goes to 0, area goes to maximum).

I have also attached the 268 lines of Fortran (PlotArea.txt) that it takes to create the graph.

ETA:  I should point out that variable names were restricted to 5 characters.  Unless otherwise declared, variables that start with the letters I,J,K,L,M,N are integers and those that start with any other letter are real.  This is a variant of Fortran IV.  The system itself was released for sale in 1965, more than 50 years ago.  I started using it in '70 so I'm coming up on 50 years myself.  And I'm still using it from time to time!

The system was available with up to 32k words of 16 bits (our two machines had just 8k, my emulation has 32k).  It had a disk operating system along Fortran, Cobol, RPG, APL and Assembly languages.  I played with RPG but never actually encountered Cobol.  We had the APL keyboard setup on one of the machines but I never used it.  I used Fortran almost exclusively.  We also had the slow processors with 3.6 us core or a cycle time of about 280 kHz.  It seemed quick at the time!

ETA:  I have attached a PDF showing the instruction timing.  Just pay attention to the T=00 column, those are the 'short' instructions.

Remember, the HP35 hadn't been invented and we were all using sliderules!

[legacy]

WOW! what amazing stuff you do, man 
 

[legacy]

I can see where developing a parser would be easier on the PC side.  Even the menu system makes sense if it is particularly complex.

Think about those like me can't access the physical engine for several and different reasons, starting from ... it's classified with a higher level than the door your badge can open (usually military tactical computers, or, even worse, space defense stuff), or the hardware hasn't been yet developed or fixed, or it's ready but it's not in the place you are, and you can't travel to go there, or the behavior of an engine under abnormal conditions (including hypothetical conditions of damages)

In avionics, we have all of these scenarios, and at the end of the week, there are those who remotely check if we have done our job. You can't talk to them face to face, only by internal email, hence everything is written and logged. That's not good for us, it's psychological pressure.

Anyway, we usually go ahead in our tasks by requiring sampling from the engine, including samples from real missions rather than digital measurements from the lab with samples in ideal conditions, or samples from the campus from real aircraft during the takeoff, the mission, and the landing; all logs & samples that we can use under Mathematica, Maple and Matlab when we are developing algorithms and we need to know if they are enough stable on real data sampled from the real hardware.

In brief, we usually spend up to the 80% of our time simulating and compiling on our workstations rather than cross-compiling for the target.


In Formula One Management and MotoGP, there is a similar approach, and you literally have to deal with big, tall, and heavy racks full of pieces of equipment that simulate a motor.

You attach your cables, on the other side .... it might be an acquiring card attached to a laptop with Labview, Visio, rather than the real PowerPC e500 card with its own acquiring subsystem, and actuators and all the gears, running VxWorks with layers of software, drivers, and your algorithm on a segregated area of the ram.


WxWorks is the RTOS used in FOM and MotoGP, and it allows you to download modules, hence you can redefine the driver of a device, or of a built-in application on the fly, without recompiling the whole kernel+Apps image, that implies - to erase the flash - to download the new image - to write it into the flash - you just need to recompile the piece of code you are working on, you download it, the VxWorks handles it in ram.

It helps a lot, the downside is the cost: 20K euro for the license, and other 8K euro for the ICE.

[legacy]

A real example of a project where you don't touch the final hardware until the end

Years ago, I worked on a project to real-time alert on the landslide of a mountain. We wanted to install a network of cheap intelligent sensor-nodes on the wall of the mountain and each sensor-node was equipped with a 3D accelerometer, a DSPIC, a solar panel, a little rechargeable battery, and an antenna.

The real first problem was how to make the engine to survive the difference of temperature since, in summer, during the night the temperature goes low, while during the day the sun makes it very hot.

In Winter and Autumn, it goes even worse. Hence we needed to use special components and high insulation for the frame. This part was solved by guys of materials engineering, and they did a good job!

I was assigned the goal of - developing the algorithm to detect the event and transmit it to the concentrator without consuming too much energy since the battery was so little that couldn't support more than a few data-bursts on the antenna - So, I developed the detect engine that continuously monitors the accelerometer collecting statistical information frame by frame. At this point, I had a serious problem with characterizing them, I needed real samples, but I was not in the condition to go on the slope of the mountain to physically wait for a seismic wave in order to collect real information of it.

(well, my boss didn't authorize me, I was willing to do it  )

So, I ended to reproduce the seismic waves in our lab by attacking a lot of accelerometers, of the same kind of our sensor-nodes, to block of cement mortar, I put it under a hydraulic press, and I kept acquiring my samples while the hydraulic press was doing its job at breaking the block.

This is a sort of simulacra, but it was fine enough to develop the statistical correlation, distinguishing the event of a true seismic wave from the ambient noise, because the battery was so limited that if you transmit a fake-event you are wasting a chance to transmit a real event if it happens.

~ ~ ~ ~

At the end of the story, up to the 90% of the development was done on Matlab, to tune the algorithm into something didn't require advanced operations like the squared root (very slow), or too many multiplications and divisions; but I also developed a compressor (without information loss) to reduce the time of transmission, that was complex, and annoying, but it revealed to be a good idea since it made the compression rate up to 75%, hence it greatly reduced the energy for transmitting the data package.

The real target was not ready when I concluded my job. We tested it several weeks later