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

[cstratton]

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.

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.

[rstofer]

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

[bson]

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.

[ttelectronic]

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.   

[emece67]

.

[JPortici]

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

[NivagSwerdna]

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.

[agehall]

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.

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.

[rstofer]

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.

[cstratton]

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)

[perieanuo]

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

[NEoX]

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.

[NorthGuy]

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.

[perieanuo]

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

[rstofer]

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.

[rstofer]

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.

[andyturk]

[...] 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.

[rstofer]

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.

[legacy]

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.

[JanJansen]

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 ?

[rstofer]

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.

[legacy]

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 


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.

[rstofer]

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.

[NorthGuy]

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.

[rstofer]

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