Author Topic: where to start? AVR/ARM/PIC .....  (Read 10357 times)

0 Members and 1 Guest are viewing this topic.

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
where to start? AVR/ARM/PIC .....
« on: August 30, 2018, 11:04:28 pm »
Hi!
I'm interested in programming microcontrollers. I used Arduino UNO for a lot of projects, but it is that time to step it up and start programming in C or something else. I have some basic knowledge in C/C++/C#.. but when it comes to microcontrollers I don't know to set pins as output or input      :scared:


 I want to enter in the real stuff of programming (run away from Arduino IDE).

Where to start?

I know there are lots of controllers that do tasks for a specific project and it depend for what I need it, but at this moment it doesn't matter because I want to learn general programming..

Witch controller to use for learning and what is best to learn for today uses?

I have a bunch of atmel (microchip) atmega lying around and also got EFM8 busy bee starter kit (but there is a small amount of examples and it is hard to get started with it for me)..

I have some knowledge of electrical circuits and I'm a student of electrical engineering so all this stuff is MUST KNOW for me and I want to "master it".

Any books/pdf/forum posts to start with all this stuff?

I think that AVR atmega is good option but maybe I'm wrong (for example ARM is maybe betrer way to start learning..idk.)

Thanks!
 

Offline luiHS

  • Frequent Contributor
  • **
  • Posts: 591
  • Country: es
Re: where to start? AVR/ARM/PIC .....
« Reply #1 on: August 31, 2018, 12:24:07 am »

ARM, ARM and ARM, it's the best thing to start and follow. ST STM32, LPC/Kinetis NXP, Atmel SAM S70 or the best currently for me, the RT1020/1050 NXP.

Working with ARM, means mainly, environment of development and C/C ++ compiler totally free, high portability between manufacturers, very cheap evaluation boards, a lot of technical documentation, even some interesting books (although not many).

My suggestion to start with the best is MCUXpresso of NXP as a development environment and the RT1020 / 1050 microcontroller Cortex M7 series from NXP. Another alternative is STM32 from ST, Cortex M4 and M7 with Cubemx integrated into Eclipse as a development environment.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: where to start? AVR/ARM/PIC .....
« Reply #2 on: August 31, 2018, 01:39:36 am »
There's nothing wrong with the Arduino UNO as hardware. Why not stick with that for a while? You can start to wean yourself from the Arduino IDE and use command line gcc and avrdude and so forth. That's no really a big deal. You can use your existing Arduino sketch source code. You can also stick to the Arduino IDE but gradually move away from using things like digitalWrite() and use direct access to the hardware instead. If you simply don't like the editor in the Arduino IDE you can use emacs or whatever with it instead (go to preferences and check "Use external editor").

Sure, eventually you might want to investigate ARM or RISC-V or other boards, but you can do a lot with AVR anyway and certainly learn all the principles with it.
 

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: where to start? AVR/ARM/PIC .....
« Reply #3 on: August 31, 2018, 10:11:25 am »
.
« Last Edit: August 19, 2022, 01:57:03 pm by emece67 »
 

Offline luiHS

  • Frequent Contributor
  • **
  • Posts: 591
  • Country: es
Re: where to start? AVR/ARM/PIC .....
« Reply #4 on: August 31, 2018, 10:18:43 am »
About books, just today I received from Amazon the book "Embedded Systems with ARM Cortex-M microcontrollers in Assembly Language and C", last edition of 2018, a very interesting book. Mix C and assembler, and deals with virtually all subjects, including the DMA. I found it interesting to see something of assembler with ARM micros, always to add something from C, it can improve the performance in some cases.

Attached pictures about my ARM and C books. Mazidi's books are interesting, although he always ignores the DMA in all his books. There are also some Elektor books, simple but interesting for beginners.

Also a good book is "Basic concepts of embedded systems with microcontrollers based on ARM Cortex-M: a practical approach", I bought it some time ago on Amazon. This is at least a bit about DMA with some examples of sources, it is the only one, along with that of Noviello for the STM32, which deals with the DMA in a practical and theoretical way, it seems that most authors do not know what the DMA is, or they are directly afraid of it.
 
The following users thanked this post: FlyingDutch

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #5 on: August 31, 2018, 10:25:39 am »
AVRs together with avr-gcc and avrdude are fine for a lot of projects; if you are going bigger with your projects, if you wanna run big and fast TFTs, use DSPs or implement networking, you are ending up on ARM.

Personally I'm using both - AVRs and ARMs (STM32) depending on the needs; if you stuck with the gcc compiler, you can work on both platforms in similar way.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: where to start? AVR/ARM/PIC .....
« Reply #6 on: August 31, 2018, 02:13:32 pm »
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.
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 
The following users thanked this post: Mr. Scram

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
Re: where to start? AVR/ARM/PIC .....
« Reply #7 on: August 31, 2018, 03:43:09 pm »
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.

are this things similar for coding? If I learn AVR with atmel studio would it be easy to learn ARM? Or I need to learn again from beginning like syntax (define pins with diferent functions..comunications can be setup with simmilar code in C like uart,i2c..)  ..or it is different world?
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #8 on: August 31, 2018, 03:53:03 pm »
It depends, how you want to work. I prefer bare metal, so I work me through the datasheets and write the peripheral functions myself - as plain and powerful as possible.

If you want it the easy way, you can use libraries but be warned - a very bad example for a hardware abstraction library is the one from the STM32 ARM-chips - it's a real pain, and I don't really see what it should make easier

I already ported several functions from AVR to ARM and vice versa; it's no big thing, the general syntax is the same, but sure you have to adopt things like ports and pins; but this is maybe already needed if you want to use a function from an atmega8 on an atmega16
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: where to start? AVR/ARM/PIC .....
« Reply #9 on: August 31, 2018, 04:03:58 pm »
If you have Arduino, you already have all the tools you need to do "professional" programming:

1. Some hardware
2. An editor
3. A compiler
4. A download tool (avrdude)
5. FKA Atmel datasheets

All you need to do is not use any of the Arduino core code or libraries. Really, the only difference between Arduino and "professional" programming is that you don't get all the examples, tutorials, online help, ready made hardware etc.

Also, you can do ARM programming with Arduino tools, Due is quite cheap, but also STM32 etc.

I suppose if you want to be a "total professional" you can:

1. Design and build your own hardware, using only the vendor datasheets
2. Spend weeks installing and configuring some obscure vendor toolset
3. Buy a programming tool
4. Spend weeks writing your own library code,  using only the vendor datasheets
5. Finally get round to writing some application code.
6. Find there is no help on the web, because virtually no one else is using that chip

For extra fun, the vendor datasheets and IDE are under NDA, and you can only access them after registering with a company email, (not google etc).
Bob
"All you said is just a bunch of opinions."
 

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
Re: where to start? AVR/ARM/PIC .....
« Reply #10 on: August 31, 2018, 04:09:41 pm »
It depends, how you want to work. I prefer bare metal, so I work me through the datasheets and write the peripheral functions myself - as plain and powerful as possible.

If you want it the easy way, you can use libraries but be warned - a very bad example for a hardware abstraction library is the one from the STM32 ARM-chips - it's a real pain, and I don't really see what it should make easier

I already ported several functions from AVR to ARM and vice versa; it's no big thing, the general syntax is the same, but sure you have to adopt things like ports and pins; but this is maybe already needed if you want to use a function from an atmega8 on an atmega16

yeah i understand.. I have that problem that i worked with Arduino IDE syntax ..I dont know how work with registers and other stuf and want to learn that..but there is lot of controllers but in C they all program same way or AVR/ARM/PIC/8051 have different style of programming?

What I actually want to ask is: If I spend 6 months on programming AVR can I be able to program ARM or do I need to spend another 6 months to learn basic stuf for ARM?
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #11 on: August 31, 2018, 04:26:49 pm »
If you know how to work with one, you will certainly have a clue, how to work with the other one, BUT there is no way around working you through the datasheets, finding out how the registers are named, what they do, which register bits to set how for a particular function.

You don't have to start from the scratch, but every uC has a different feature set, a different register set aso. and you have to get familiar ever again if you use a different uC
 
The following users thanked this post: NEoX

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: where to start? AVR/ARM/PIC .....
« Reply #12 on: August 31, 2018, 11:55:48 pm »
What I actually want to ask is: If I spend 6 months on programming AVR can I be able to program ARM or do I need to spend another 6 months to learn basic stuf for ARM?

If you're working in C/C++ then there is no difference in the logic of your program between *any* CPU, not only AVR vs ARM, but also x86, RISC-V, MIPS etc etc.

If you move from one ARM vendor to another (e.g. STM vs Atmel vs NXP) then the differences in peripherals and how you program them are essentially no different from moving between AVR and ARM.

If you need six months to learn the first one then you probably need two weeks to learn the second one.
 

Offline PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1477
  • Country: au
Re: where to start? AVR/ARM/PIC .....
« Reply #13 on: September 01, 2018, 03:34:25 am »
I know there are lots of controllers that do tasks for a specific project and it depend for what I need it, but at this moment it doesn't matter because I want to learn general programming..
Witch controller to use for learning and what is best to learn for today uses?
I have a bunch of atmel (microchip) atmega lying around and also got EFM8 busy bee starter kit (but there is a small amount of examples and it is hard to get started with it for me)..
I have some knowledge of electrical circuits and I'm a student of electrical engineering so all this stuff is MUST KNOW for me and I want to "master it".

If you are studying EE, then it will be very useful to know more than one MCU, and more than one single development path.
AVR is a good start, which is what Ardunio uses, but debug support is poor on the old Ardunios.

If you can get hold of one, I understand the new ARDUINO UNO WIFI REV2  has a 'proper' debug channel. 

EFM8 is also good, especially if you need good Analog. Their EFM8LB1 has 14b ADCs
You should be able to load/change/debug the examples, as good training. Their simplicity Studio IDE is common with their EFM32 parts too.

Moving up from those 8 bit ones, the next most useful adder to a CV would be ARM, if you have Silabs & AVR debug under your belt, maybe ST parts, or NXP , or Nuvoton ?
You could jump to M4 parts, or bare-metal rasp-Pi gives very good training to a EE.
 

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
Re: where to start? AVR/ARM/PIC .....
« Reply #14 on: September 01, 2018, 09:40:49 am »
thank you guys! I need to learn how to read datasheet of MCU ..but there is not lot of tutorials on the internet..are books more helpful in that part? I found some tutorials that covers datasheet and other stuff for AVR and ARM ..my biggest problem is starting with MCU (setting up pins, interrupts, watchdog, timers...) because I dont know syntax of that for MCU in C and in datasheet instruction like "set that register bit to high for enable interrupt" dosent tell me (or helps me) how to do it in C because I dont know syntax for that
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #15 on: September 01, 2018, 09:56:38 am »
Imo the datasheets from let's say an Atmega8 is really overseeable; it has a good structure and is well ordered.

If it comes to ARM like for example an STM32F103 we are talking already about a bunch more of pages, and it's already trickier to keep track over a topic, since something like a SPI already covers maybe 50-60 pages, so it means a lot of wrapping pages, better say scrolling up and down; it's a bit annoying.

for STM32 you can get "Mastering STM32", it's quite ok, but for my taste too much focused on the HAL functions; but still: the datasheet is the best and most reliable source of information.
 

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
Re: where to start? AVR/ARM/PIC .....
« Reply #16 on: September 01, 2018, 10:12:18 am »
Better to start with it then..lot of talking will not make me learn that stuff  :-DD ..time to start hard!
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #17 on: September 01, 2018, 10:15:18 am »
Start with the classical Hello World! and Blinky for whatever uC you use; based on that you can slowly extend to code - try and error; there is nothing what speaks against that method.

It's unlikely for the beginner to write pages and pages of code, compile and upload it on the chip - and voilà - everything works. It would be nice, but it's unlikely to happen
 
The following users thanked this post: NEoX

Offline iMo

  • Super Contributor
  • ***
  • Posts: 4675
  • Country: nr
  • It's important to try new things..
Re: where to start? AVR/ARM/PIC .....
« Reply #18 on: September 01, 2018, 11:07:55 am »
Today people start with ..duino like environments (with free, bundled, easy to install "uniform" development tools), where the fast lead-in (or a quick win) is easy to make.

If I were you I would definitely not start with reading the datasheets or messing with HALs..

Such ..duino environments (IDEs) suitable for beginners are:

1. arduino   (avr/arm/esp8266/esp32)
2. teensy  (avr/arm)
3. stm32duino  (arm)
4. chipkit  (pic32mx/mz)
5. sloeber (eclipse based ..duino env, ~hundreds of avr/arm/pic/esp boards supported)
.. etc.

All above environments offer almost identical ..duino "language/syntax/dev_chain/libraries" (C, C++), thus to port your code from any above MCU/board to other above MCU/board is "pretty easy", many times just a plain "copy and paste" with a minor editing a few board specific pin names..

You will not be exposed to a need to mess with any register-level programming or HALs while you can develop quite demanding apps (an rtos based inclusive).

Most important for you will be the availability of many free libraries to play with and a good and responsive community forum with kind people you may ask for a help..   :)
« Last Edit: September 01, 2018, 11:59:51 am by imo »
 

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
Re: where to start? AVR/ARM/PIC .....
« Reply #19 on: September 01, 2018, 12:17:09 pm »
the thing is..I have my summer job in one company that makes vending machines and lot of prototypes ..the machines nees to be fast and clean wirtten code in assembly or C ..they are giving me scholarship until I finish uni (now Im working with electonic in that company but I like coding too). I want to learn lot of things before i start working in that company after I finish uni. So the Arduino ( I use arduino also to work with lot of things..like esp8266, sim800l...) is not best option to spend lot of time with. I need to start learning pure MCU programming in C and all of comunications (i2c,uart,rs232,spi...)
..so I want to be prepared and say at the job "yes, I know how it works and I can do it" (yes those things makes me happy) ..better to start early than when it is late. :popcorn:
« Last Edit: September 01, 2018, 02:07:59 pm by NEoX »
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #20 on: September 01, 2018, 01:40:56 pm »
Then it's a good idea to start working on plain C with a gcc, either for ARM or AVR - aiming on writing your own functions for all the busses the platforms offer
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #21 on: September 01, 2018, 02:56:13 pm »
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.
 

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
Re: where to start? AVR/ARM/PIC .....
« Reply #22 on: September 01, 2018, 03:35:18 pm »
one programmer told me to start with 8 bit MCU then go to bigger processor because I will better understand how to wirte good code and optimization because powerfull MCU can take lot of sh*t and bad written code because it has power to deal with it. So im confused little bit where to start now..something 8 bit or take something "bigger".

Also I would pay for good book no problem but only if book is good written and helpful (book that I can follow from start to finish).
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #23 on: September 01, 2018, 03:59:03 pm »
It's certainly not a bad idea to start with the 8bit uC, but it's no iron rule.
When you code, you should always have an eye on the binaries, especially for uC-code, where flash memory is not unlimited

It thinks for example a good idea to avoid string functions and floats on a Atmega8; they're not needed for every price; the programming convienience known from a real computer should be avoided on uC; that sometimes requires some experimenting how a function can be written fast and compact.

If you have some uC right now at home - use that one; there's no need to buy a selection of chips just to get going; take what you have, like an Atmega8, get the toolchain, get the datasheet, maybe get some peripheral like an LCD and start writing - this is in the end the step you cannot avoid doing: start somewhere, even if it's tricky
 

Offline cstratton

  • Regular Contributor
  • *
  • Posts: 62
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #24 on: September 01, 2018, 04:20:51 pm »
If you're working in C/C++ then there is no difference in the logic of your program between *any* CPU, not only AVR vs ARM, but also x86, RISC-V, MIPS etc etc.

This is actually only true in very simple cases.

A primary example of hardware differences encountered in C has to do with the processor width.

For example, an `int` on most AVR compilers is a different size than it is on most ARM compilers.

Further, even for explicitly sized types such as `int8_t` and `int32_t` behavior differs.   On the 8-bit core, using a wider type than necessary costs extra memory and operations.  While on a 32-bit core, using an 8-bit type where a larger one would work can force an extra step to mask off only the required bits.

On an 8-bit machine, a 16 bit volatile counter exported from an ISR to the main loop needs a locking mechanism to avoid having it change between the two required memory read operations; on a 32-bit machine it does not need that.

And then there are issues with unaligned memory access.

And struct packing

Or endianness, though that happens to match here.

Fortunately once these issues are understood it's possible to target either situation.

Then there are things that get more specifically hardware-involved - anything to do with interrupts or peripherals.

Also differences between true and modified Harvard architectures determine if you can perform transparent access to flash memory (ie, via true pointers) on not.  And if you can write to code memory, if you need to force cache consistency.


 

Offline cstratton

  • Regular Contributor
  • *
  • Posts: 62
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #25 on: September 01, 2018, 04:30:05 pm »
the thing is..I have my summer job in one company that makes vending machines and lot of prototypes ..the machines nees to be fast and clean wirtten code in assembly or C

The obvious thing to do is send them an email and ask what MCU (and toolchain) they use.

Quote
So the Arduino ( I use arduino also to work with lot of things..like esp8266, sim800l...) is not best option to spend lot of time with. I need to start learning pure MCU programming in C and all of comunications (i2c,uart,rs232,spi...)

It's been previously pointed out that using the Arduino hardware does not require using the Arduino software.  You can just treat it like an ATmega328p development board.  Installing the Arduino IDE got you a working copy of avr-gcc and avrdude so if you find them, you have what you need to target the bare processor.

Using the Arduino-style bootloader does not really impose substantial differences in your code (you just have slightly less flash to work with) and means you can instantly switch back and forth between loading bare metal projects and loading Arduino projects - something that can be especially handy if you want to use some Arduino code to cross-check a difficulty in the bare metal realm.  For example you can initialize a peripheral with Arduino and then read out and Serial.print() the values that have ended up in the AVR registers, and decode those by consulting the data sheet.
 
The following users thanked this post: NEoX

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #26 on: September 01, 2018, 08:18:48 pm »
one programmer told me to start with 8 bit MCU then go to bigger processor because I will better understand how to wirte good code and optimization because powerfull MCU can take lot of sh*t and bad written code because it has power to deal with it. So im confused little bit where to start now..something 8 bit or take something "bigger".

Also I would pay for good book no problem but only if book is good written and helpful (book that I can follow from start to finish).

And you spend a lot of time messing around with a uC that you will never want to use.  Nor will any production house.  The ARM chips are dirt cheap and very powerful.  Given the 32 bit architecture (there are some 16 bit instructions), you don't need to get concerned about multibyte arithmetic and similar 'features' of the 8 bit world.

Most ARM chips will have quite a bit of memory and they are fast (for uCs).  As a programmer, your life is simplified by the hardware.  Just write the code and let the compiler worry about the details.

I did a lot of assembly programming back in the early days (starting in '70) and I was still doing it up through the '80s but I don't want to do it any more than necessary.  If you use something like the PIC16Fxxx with it's banking and paging, you really have to get down in the dirt.  If you use a C compiler and look at the code, you will see an excessive amount of instructions doing nothing more than banking and paging.  It is truly ugly!

The AVR ATmega devices are a step up in that the architecture is more regular and clean.  They are fun to program even though they are only 8 bit processors.  If you want, you can program the Arduino and just use the bootloader for program loading.  There's no reason why this won't work.

But, in the end, you're going to wind up with ARM so you might as well start there.  If you feel the need to work downhill, do it later.  Get used to reading datasheets and writing code to match.  It's quite a learning curve.

The newer Cortex chips don't require assembly code for startup.  Everything can be written C.  This is not the case for the ARM7TDMI chips like the LPC2106 and LPC2148.  With those you need to get your hands a little dirty - not too bad because you can find a lot of sample code but you still have to do it
 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #27 on: September 01, 2018, 09:32:44 pm »
Go ARM with gcc/g++, it's absolutely the easiest to learn things like effective use of inline assembler, compiler register usage and code optimizations, linking techniques, startup.S assembly, debug information, calling conventions, etc.
 

Offline ttelectronic

  • Contributor
  • Posts: 43
  • Country: ca
Re: where to start? AVR/ARM/PIC .....
« Reply #28 on: September 01, 2018, 11:18:25 pm »
Hi NEoX,

I think it is awesome that you are willing to take the next step and learn programming. I would recommend digging into one of the big C programming books. It's one thing understanding it to tweak it, but a whole different world know what is going on or ways to accomplish what you would like to do. It really helps to have a good understanding. As far as AVR, ARM, PIC etc. You do have to really dig into the datasheets to determine how to do things, and that doesn't just apply to microcontrollers, you will also have to find info in data sheets on setting bits to accomplish what you want.

Smaller datasheets does make it easier to sort through what you would like to do with a device. I honestly prefer Notepad++ then just make a batch file to compile and upload the code. Seems the simplest and fastest way to work.   :-+
 

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: where to start? AVR/ARM/PIC .....
« Reply #29 on: September 02, 2018, 09:30:32 am »
.
« Last Edit: August 19, 2022, 02:00:32 pm by emece67 »
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: where to start? AVR/ARM/PIC .....
« Reply #30 on: September 02, 2018, 10:26:42 am »
And you spend a lot of time messing around with a uC that you will never want to use.  Nor will any production house.  The ARM chips are dirt cheap and very powerful.  Given the 32 bit architecture (there are some 16 bit instructions), you don't need to get concerned about multibyte arithmetic and similar 'features' of the 8 bit world.

Not true, otherwise microchip alone wouldn't sell millions of PICs them every year (not counting AVR) and new and improved parts come out every few months
- altough i don't know how they compare to the sale figures of ARM chips -
 
The multibyte arithmetic and yada yada yada cans still be issues in the 32 bit world.
Say, you have 16bit timers only that you have to cascade, or you have to perform 64 or 128 bit integer math.
Yeah, the compiler will happily do the work for you and so it will on 16bit cores and 8 bit cores.

You want cheap, robust, higher voltage parts? there are few candidates in the 16 and 32 bit world that meet all three.
I guess i could redesign most if not all of the board we have in production to use 32 bit microcontrollers, but i would have to add the cost of the parts themselves and the added chips, passives and space for the 5V <-> w/e analog and digital translation

to the OP, in my line of work i have always had the core do a little of integer math, a lot of decision making and fast interrupt response. All can be achieved also in 8 bit cores, i use 16bit cores when i have more complex boards which require more "tasks" to be performed, so every task need little power, but there many tasks.
I won't comment on networking and those kinds of jobs because i rarely have to deal with those things, and in those cases 32bit is my preferred choice :)

To me usually the CPU is secondary to the peripherals, they do most of the work and the cpu moves bytes around, sets flags et cetera.
To understand the peripherals and how to use them in the non-obvious way for us youngsterns (really opens your mind) i really loved the books by Lucio di Jasio, like "Learning to Fly the PIC 24"
his books are for PIC only, i'm afraid but the concepts will apply for every machine
 

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2495
  • Country: gb
Re: where to start? AVR/ARM/PIC .....
« Reply #31 on: September 02, 2018, 12:39:12 pm »
I want to enter in the real stuff of programming (run away from Arduino IDE).
Arduino is an eco-system.. it has the Arduino hardware (e.g. Uno), an IDE and a method of getting the code into the hardware (typically a bootloader pre-programmed into the Uno).
You are looking to step-up but in doing so you need to consider the whole eco-system.  If you stick with AVR then you can get AVR Studio but you really also need a proper programmer... Atmel ICE, AVR dragon etc.
Or you could take the ARM route... get a STM Dev board e.g. STM Discovery which I believe has the ISP onboard.
« Last Edit: September 02, 2018, 01:19:22 pm by NivagSwerdna »
 

Offline agehall

  • Frequent Contributor
  • **
  • Posts: 381
  • Country: se
Re: where to start? AVR/ARM/PIC .....
« Reply #32 on: September 02, 2018, 01:04:24 pm »
the thing is..I have my summer job in one company that makes vending machines and lot of prototypes ..the machines nees to be fast and clean wirtten code in assembly or C ..they are giving me scholarship until I finish uni (now Im working with electonic in that company but I like coding too). I want to learn lot of things before i start working in that company after I finish uni. So the Arduino ( I use arduino also to work with lot of things..like esp8266, sim800l...) is not best option to spend lot of time with. I need to start learning pure MCU programming in C and all of comunications (i2c,uart,rs232,spi...)
..so I want to be prepared and say at the job "yes, I know how it works and I can do it" (yes those things makes me happy) ..better to start early than when it is late. :popcorn:

You need to understand that there really isn't anything wrong with Arduino hardware. It's cheap, easy to use and very available. Ditch the horrible IDE and use something better. Then start reading datasheets for the MCU on your board and off you go. If you think you need something else to learn, I'd say you are very wrong.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #33 on: September 02, 2018, 02:32:42 pm »
You need to understand that there really isn't anything wrong with Arduino hardware. It's cheap, easy to use and very available. Ditch the horrible IDE and use something better. Then start reading datasheets for the MCU on your board and off you go. If you think you need something else to learn, I'd say you are very wrong.

Just add the Visual Micro Arduino plug-in to Microsoft Visual Studio Community Edition and you have a very nice IDE.  You still need to install the original Arduino IDE to get the toolchain.

https://www.visualmicro.com/

You can program the Arduino hardware at any level you want.
 
The following users thanked this post: agehall

Offline cstratton

  • Regular Contributor
  • *
  • Posts: 62
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #34 on: September 02, 2018, 09:56:49 pm »
Just add the Visual Micro Arduino plug-in to Microsoft Visual Studio Community Edition and you have a very nice IDE.  You still need to install the original Arduino IDE to get the toolchain.

If one really wants to suffer Visual Studio and its platform lock in while targeting the AVR, Atmel Studio is based thereon, and has integration with the more professional style Atmel Software Framework libraries for all of their MCU families.

(Fortunately those are also available as a stand alone download archive for those who need to do their MCU work on the same sane platform as the rest of a company's software projects)
 

Offline perieanuo

  • Frequent Contributor
  • **
  • Posts: 838
  • Country: fr
Re: where to start? AVR/ARM/PIC .....
« Reply #35 on: September 04, 2018, 03:22:56 pm »
Install sloeber ide it's eclipse ide setup for arduino &co boards.test with an arduino sketch if it works (print something on an lcd, like a temperature, I just tested for example if I can pwm a ventilator reading the temp from a npn transistor as temp sensor, you need 1 resistor,1 transistor,1 lcd).This is part of one of my projects (wanted to have a temp sensor that can be attached with a screw to a heatsink...).that's just an example, you can do what you want but start simple.
Then get away from arduino libs and stuff and try to rewrite from scratch the code C to do the same task using bare coding, without arduino libs.If you finish this simple task, the rest of the way will be a walk in the park.
Once you figure for example 328p hard coding, moving to others uC is not hard.
And you'll have your 2 feet already in eclipse, a good IDE with flavors for C Cpp and lot of other languages.
For start Atmel studio do the same job but imho it's not best for future developments.I remember I tested it besides codeblocks and eclipse, eclipse wins.
And don't give up!


Envoyé de mon iPad en utilisant Tapatalk
 

Offline NEoXTopic starter

  • Contributor
  • Posts: 29
  • Country: hr
Re: where to start? AVR/ARM/PIC .....
« Reply #36 on: September 08, 2018, 12:03:01 pm »
Install sloeber ide it's eclipse ide setup for arduino &co boards.test with an arduino sketch if it works (print something on an lcd, like a temperature, I just tested for example if I can pwm a ventilator reading the temp from a npn transistor as temp sensor, you need 1 resistor,1 transistor,1 lcd).This is part of one of my projects (wanted to have a temp sensor that can be attached with a screw to a heatsink...).that's just an example, you can do what you want but start simple.
Then get away from arduino libs and stuff and try to rewrite from scratch the code C to do the same task using bare coding, without arduino libs.If you finish this simple task, the rest of the way will be a walk in the park.
Once you figure for example 328p hard coding, moving to others uC is not hard.
And you'll have your 2 feet already in eclipse, a good IDE with flavors for C Cpp and lot of other languages.
For start Atmel studio do the same job but imho it's not best for future developments.I remember I tested it besides codeblocks and eclipse, eclipse wins.
And don't give up!


Envoyé de mon iPad en utilisant Tapatalk

Thanks. I was looking to try eclipse for future ARM programming but why not to start with it for AVR too.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: where to start? AVR/ARM/PIC .....
« Reply #37 on: September 08, 2018, 01:52:39 pm »
Most ARM chips will have quite a bit of memory and they are fast (for uCs).  As a programmer, your life is simplified by the hardware.  Just write the code and let the compiler worry about the details.

It may work for you because you have programmed for 40 years on different architectures, used assembler, even built lots of CPUs by yourself in FPGA. So, you don't "just write", your life is simplified by experience.

If someone produces x10 bloat when he "just writes", more hardware may not be able to compensate for the loss. More importantly, if someone solves all the problems by using more hardware, they will never get the experience you have. Rather, they will turn into hardware addicts who always chase more powerful hardware to compensate for their ever growing bloat.
 

Offline perieanuo

  • Frequent Contributor
  • **
  • Posts: 838
  • Country: fr
Re: where to start? AVR/ARM/PIC .....
« Reply #38 on: September 08, 2018, 02:51:34 pm »


It may work for you because you have programmed for 40 years on different architectures, used assembler, even built lots of CPUs by yourself in FPGA. So, you don't "just write", your life is simplified by experience.

If someone produces x10 bloat when he "just writes", more hardware may not be able to compensate for the loss. More importantly, if someone solves all the problems by using more hardware, they will never get the experience you have. Rather, they will turn into hardware addicts who always chase more powerful hardware to compensate for their ever growing bloat.
It depends, we sometimes have clients who want to develop a product.my exex boss choosed always (contrair to my advice) the exact device in terms of memory space,speed,ports number,you get the idea.after 1 year,the client wanted something more,add 2-3 sensors,new rutine,another pid loop and so on.if you don't have security margin,you're f...ed.remaster entire pcb,the code maybe start from scratch to another platform and all.
Keeping secure zones for hw and sw is just good practice, you don't get 'short'.and for begin to play, that's exact the idea.you smoked a port,you have a spare.it always happens sooner ol later to the best of us like to the others.
Just as second advice, if you start with avr and you like challenge,use eclipse cdt and setup the ide yourself for avr,I forgot to tell you to buy also some stk500 clone or something like this,after build you write quickly your target, no fuzzing with another sw.I used an utk500 chinese thing for avr, works flawlessly with arduino,atmel studio 7,eclipse,sloeber and all other avrdude sw


Envoyé de mon iPad en utilisant Tapatalk
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #39 on: September 08, 2018, 03:14:50 pm »
Most ARM chips will have quite a bit of memory and they are fast (for uCs).  As a programmer, your life is simplified by the hardware.  Just write the code and let the compiler worry about the details.

It may work for you because you have programmed for 40 years on different architectures, used assembler, even built lots of CPUs by yourself in FPGA. So, you don't "just write", your life is simplified by experience.

If someone produces x10 bloat when he "just writes", more hardware may not be able to compensate for the loss. More importantly, if someone solves all the problems by using more hardware, they will never get the experience you have. Rather, they will turn into hardware addicts who always chase more powerful hardware to compensate for their ever growing bloat.

I agree with everything you said ...

It is worth knowing how to write assembly code but it is seldom necessary.  I view it as knowing how to use a sliderule.  It was the only game in town when I was in undergrad.  I certainly don't want to do it today.  I generally won't even use a calculator when things get tough.  No, I use Matlab or wxMaxima.  We have better tools!  They are amazing!

There is no reason not to study avr-libc and how to use it on the Arduino platform without the Arduino libraries.  After all, the Arduino libraries are built on top of avr-libc.  There is plenty of documentation as well as forums and tutorials.  avr-libc provides the startup code for setting up the CPU and all the interrupt vectors before calling main().  That bit will is written in assembly language.

http://cvs.savannah.gnu.org/viewvc/*checkout*/avr-libc/avr-libc/crt1/gcrt1.S

You can see all of the interrupt vectors.  Note that they all point to __bad_interrupt.  That little vector macro is pretty clever in so few lines of code.  Like most library code, there are a lot of #ifdef blocks that accomodate various processors.  It is often a real PITA to figure out what is happening for YOUR chip.  Just hope they did it right or rewrite it yourself.

Even for the simple chips, the startup code is fairly involved.  For the casual user, I would recommend leaving it alone and working at the next level up - C code.

I haven't looked at it in several years but I recall avr-libc documentation as excellent.

 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #40 on: September 08, 2018, 03:19:54 pm »
Install sloeber ide it's eclipse ide setup for arduino &co boards.test with an arduino sketch if it works (print something on an lcd, like a temperature, I just tested for example if I can pwm a ventilator reading the temp from a npn transistor as temp sensor, you need 1 resistor,1 transistor,1 lcd).This is part of one of my projects (wanted to have a temp sensor that can be attached with a screw to a heatsink...).that's just an example, you can do what you want but start simple.
Then get away from arduino libs and stuff and try to rewrite from scratch the code C to do the same task using bare coding, without arduino libs.If you finish this simple task, the rest of the way will be a walk in the park.
Once you figure for example 328p hard coding, moving to others uC is not hard.
And you'll have your 2 feet already in eclipse, a good IDE with flavors for C Cpp and lot of other languages.
For start Atmel studio do the same job but imho it's not best for future developments.I remember I tested it besides codeblocks and eclipse, eclipse wins.
And don't give up!


Envoyé de mon iPad en utilisant Tapatalk

Thanks. I was looking to try eclipse for future ARM programming but why not to start with it for AVR too.

I use eclipse for a lot of things.  As an IDE and project manager, it does the job quite well.  It seems strange to see PC Fortran projects right along with AVR and ARM C projects but that's the way it works out.  At some point, you simply must move your projects into separate workspaces.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #41 on: September 08, 2018, 08:09:08 pm »
[...] It is worth knowing how to write assembly code but it is seldom necessary.  I view it as knowing how to use a sliderule.
It's not all that common to actually write assembly code these days, but knowing how to single-step a program in a debugger is still very useful in the uC world. Sometimes you have to step through libraries that you don't have source for, but still somehow understand what's going on. Or (on ARM) your program is looping in the HardFault_Handler and you have to to dig your way out.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #42 on: September 08, 2018, 08:36:10 pm »
It might be wise to actually write a hard fault handler that would unwind the stack and put the stack pointer in a known location within the handler.  But, I concede, this is assembly language coding.  Maybe the fault handler can put the SP in the proper place to call a C function that really unwinds the stack with a nice printf() display.

I don't tend to single step, I had enough of that with the 8080/Z80 chips, it's a colossal time sink.  I prefer to litter my code with conditional printf() (or equivalent) statements.

 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #43 on: September 08, 2018, 11:01:46 pm »
with conditional printf() (or equivalent) statements.

puts, putc, or defined type_out are better
the printf is a dead elephant about the stack usage

(I can show you a tiny implementation I did ... tiny and essential on the paper when you look at the source, but it still huge about the stack it eats at runtime)

p.s.
breakpoints + watchpoints + eventpoints is the best way to debug, if your hw supports it.
 
The following users thanked this post: JPortici

Offline JanJansen

  • Frequent Contributor
  • **
  • Posts: 380
  • Country: nl
Re: where to start? AVR/ARM/PIC .....
« Reply #44 on: September 09, 2018, 02:10:24 pm »
ARM chips are not really in DIP package.
You solder SMD ?, else you stuck to PIC.

I also ordered a nucleo board with STM7H chip.
what are you planning to make ?
« Last Edit: September 09, 2018, 02:12:35 pm by JanJansen »
aliexpress parachute
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #45 on: September 09, 2018, 03:01:58 pm »
with conditional printf() (or equivalent) statements.

puts, putc, or defined type_out are better
the printf is a dead elephant about the stack usage


Which is why I stated "or equivalent".  Actually, I hardly ever use printf() itself because it includes the strings library functions and those almost always use the heap and I don't want a heap in my projects.

I watch for a missing declaration of _sbrk or, worse, I find that _sbrk is defined.  _sbrk is the function that actually allocates memory for malloc() and calloc() - the heap allocation functions.

What I actually do is copy all the string functions from "The C Programming Language", Kernighan and Ritchie.   None of these functions use a heap and the code is something I typed so I know what is in it.  I also add some hex format output code so I can print bytes, shorts and ints in 0xFF, 0xFFFF, 0xFFFFFFFF format.  Yes, puts() and putch() are included.

The very first thing I do with a new project is to get the UART working.  Then I add the functions for output and only then do I actually start work on my project.

ETA:  All of the above for embedded programming.  For PC programming I obviously use printf().  I have no problem with a heap on a PC.
« Last Edit: September 09, 2018, 03:39:52 pm by rstofer »
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #46 on: September 09, 2018, 03:48:58 pm »
The very first thing I do with a new project is to get the UART working.  Then I add the functions for output and only then do I actually start work on my project.

why don't you use an hw-debugger? do you mean your CPU/MPU/DSP/whatever doesn't support it?
if not hw-supported, why don't you implement a software db-stub instead?
it only takes interrupt and a couple of tricks to inject traps into the code-area

hence, the next question is: is your code located into a ROM, can't you copy and execute it into RAM, hence you can't mimic a breakpoints/wathpoints/eventpoints by letting your debugger to stuff trap instructions?

if the answer is, yes, I can have the code running into the RAM, then the gdb-stub or solution like the NOICE's db stub, is the recommended way to debug  :popcorn:


NOICE is a commercial toolset, still available for the purchase; it comes with the source for a set of CPU targets { z80, hc11, 6809, old-ARM, ... } and the program on the host side (Windows). It's very professional and useful. It costs money, but it is worth with all the penny you pay.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #47 on: September 09, 2018, 04:42:06 pm »
I don't really like debuggers.  They remind me of the early days of the 8080 and single-stepping with CP/M's Dynamic Debugging Tool (DDT) through assembly code.  True, the newer tools are much better because you step through code at the source level and with breakpoints they are quite useful.  I just don't use them very much.

In the early days it wasn't easy to get hardware debuggers that actually worked.  An exception was the terrific Rowley CrossConnect I used with the ARM7TDMI chips.  It worked really well!  Sometimes these dongles were pretty expensive.

OpenOCD didn't always play well and gdb seemed like a nightmare so I didn't mess with it much.  Now, with some of the STM boards, debuggers work very well.

There are platforms, like the LPC1768 mbed, where I don't think hardware debuggers are going to work.  The online toolchain doesn't have a debugger and I'm not sure how to hook one up to the hardware even if I used a local toolchain.  Attempts to use CMSIS-DAP don't seem to be successful.

https://os.mbed.com/platforms/mbed-LPC1768/

All in, I'm more productive doing things with print functions.  And that mbed device is one of my preferred 'stamp' like boards.  I plug the gadget into a daughter card with a MagJack and I'm up and networking as fast as I write the mainline and call the lwIP stack.  Not as simple as a Raspberry PI but the peripherals are a lot easier to deal with when Linux isn't involved.  And Sockets are Sockets...

I really don't want to spend my time debugging the debugger.  Simple console output works pretty well.  I can always implement a getch() function to hold the CPU while I read the output.

Once we get into RTOS, all bets are off.

If I don't put bugs into my code, I won't have to hunt them down.  I use C and avoid C++ at every opportunity.

 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: where to start? AVR/ARM/PIC .....
« Reply #48 on: September 10, 2018, 03:36:20 pm »
I don't really like debuggers.

I typically use lots of simple methods - LEDs, signals on external pins which I capture externally, UART, other things. These are usually enough to figure out what's going on.

However, I also use debuggers when I feel appropriate. Of course, when debugger halts you lose all the timing - the outside world moves on, so you often cannot really continue. But you can inspect variables, you can do some single-stepping to see the flow. This may be very useful.

Also, 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.

 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #49 on: September 10, 2018, 04:44:59 pm »
Also, 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.  Maybe something for robotics or computer vision.  My limited experience has been in manipulating the peripherals and this doesn't translate well to the PC.  It doesn't translate to the Raspberry PI either due to limitations of Linux interacting with peripherals.

I do use the debugger in Visual Studio for PC programs but more for seeing what kind of code was emitted rather than actually checking variables although that works very well.  Just drag and drop a label or address on the explorer and up pops the data.  Very nice!

I think most of us use the same process of writing what I call 'defensive' code.  Code that is known to work, has been used in the past and isn't too clever.  I really hate 'clever' code - the kind of thing that I have to work through with a scratch pad to convince myself that it might work.

In some ways, I am not at all happy with factory HAL code that slings structs around.  I fully understand why they do it but it isn't the way I would be writing the code.  I generally write a function that initializes the device and I include that in the file with the code that uses the device.  All in one package - initialization and utilization.

I'll use #define to create the various bit shifts and masks as well as the peripheral addresses (if I don't get them somewhere else) but I don't think I'm going to put all the options in a struct.  It simply doesn't appeal to me.

It's pretty clear I am behind the times.  It happens when you get old...


 

Offline carl0s

  • Supporter
  • ****
  • Posts: 276
  • Country: gb
Re: where to start? AVR/ARM/PIC .....
« Reply #50 on: September 10, 2018, 08:15:51 pm »
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.
« Last Edit: September 10, 2018, 08:19:44 pm by carl0s »
--
Carl
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: where to start? AVR/ARM/PIC .....
« Reply #51 on: September 10, 2018, 11:35:13 pm »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #52 on: September 10, 2018, 11:42:40 pm »
Quote
Quote
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...
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: where to start? AVR/ARM/PIC .....
« Reply #53 on: September 10, 2018, 11:59:48 pm »
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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #54 on: September 11, 2018, 12:43:33 am »
Quote
Quote
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.

 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #55 on: September 11, 2018, 10:42:03 am »
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?
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: where to start? AVR/ARM/PIC .....
« Reply #56 on: September 11, 2018, 03:40:00 pm »
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!


« Last Edit: September 11, 2018, 05:25:33 pm by rstofer »
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #57 on: September 12, 2018, 09:23:32 am »
WOW! what amazing stuff you do, man  :D
 
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #58 on: September 12, 2018, 09:53:43 am »
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.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: where to start? AVR/ARM/PIC .....
« Reply #59 on: September 12, 2018, 10:33:11 am »
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  :rant: :rant: :rant: )

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  :D
 
The following users thanked this post: Siwastaja


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf