Microcontrollers and a lot of advice - PIC , AVR, ARM - Software - Books - Boards

[JoePage]

Hello,

I'm new to the forum but hopefully you guys will give me some great advice.

I have been programming microcontrollers for the past five years, only as a hobby but I do plan to move to this as my career, I am currently a machinist but I don't quite have the means for university yet. I'm 27, so should still be capable of learning :razz:

The current microcontroller I use are the 18F series of PIC microcontroller, I have only ever used assembly and honestly have no idea about C programming or any other for that matter. A lot of my projects have used graphic displays which has required a lot of boring coding. I am now onto a 480 x 600 (I think) touch screen display and my board has two SD cards and an SPI bus. Three of these bit-banged, there's just a huge amount of code for just the simple 18F24k40 that I'm using. So I put the project on hold. I would say I'm pretty good at self-teaching because I learnt coding from the Microchip data sheets. I have read a lot of dats sheets of IC's such as FRAM, SRAM, ADC, DAC and other specialised chips, and been able to implement them into a project.


I am now wanting to get ahead with times and move onto something more capable, also learn software that's up to date / what everyone else is using.


So, from all the advice you guys give me will determine what route I will take. I'm not going to post this question on multiple forums either, so serious advice only please.


I liked the PIC series because they're simple and cheap on the smaller projects. What would you guys recommend I go with, PIC, AVR, ARM, etc... Also what software should I be going with? I would rather lean towards what is most capable, the easiest to interface with displays, USB, Serial, CAN, etc.. I'm willing to invest in development boards, software and books. I like the range of PIC and that I can pick between a $2 chip and a $15 chip, but is this the industry standard?. I see the ARM processor in a lot of powerful applications including phones, I just don't want to be limited to expensive chips (I'm sure there are cheaper ones).

So assume that I'm a total beginner, I have $2500 to invest in this, university is not an option (for another 2 years anyway). I'm willing to listen to all advice, but opinions need to be justified. I'm fairly intelligent, but no Dexter.


Thanks,
I look forward to finding a solution.

 

[wwfeldman]

I suggest you stick with the Microchip PICs

Microchip has C compilers:
https://www.microchip.com/mplab/compilers

from page 498 of PIC18F47J53 FAMILY Data Sheet (DS30009964C)

Section 30.2 MPLAB XC Compilers

"The MPLAB XC Compilers are complete ANSI C
compilers for all of Microchip’s 8, 16, and 32-bit MCU
and DSC devices."

this way, you only have to learn C

I do not know anything about the Canadian education system.
Here in US, there are community colleges - 2 year schools that
offer associates degrees and/or certificates indicated a level of education.
They tend to be significantly less expensive and generally allow
one to sign up for one class a semester. If you can fit an appropriate class
in your schedule, you might get a start without having to wait 2 years.
Work in a community college can be transferred to a 4 year school, depending
on the two schools involved and the classes and etc etc.

 

[KlausST]

Hi,

board has two SD cards and an SPI bus. Three of these bit-banged,

You may use many devices on one SPI bus. Why three busses?
In many years of programming I always avoided bit banging .... because of programming effort as well as processing power

To your main question:
I like the AVRs, made many projects with them.
But if you do some larger projects both AVR and PIC are limited.

Nowadays ARM are cheap with a lot more processing power and additional hardware features.
You may have a look at STM32 for cheap, feature rich and fast ones.
There are configurators, code generators, in circuit debuggers

And yes - step over to "C" language.
Many libraries, better readability, less code, flexible, but fast, too.

Klaus

 

[JoePage]

Ok, thanks,

I would like to stick with Microchip PIC's for now since I do have quite a lot of them imbedded in projects, so I guess I could start by re-writing the code in C. I have done quite a bit of searching in regards to books, there's so many recommendations, but I'm gonna buy C Primer Plus and C++ Primer Plus to get me started. I stand at a machine for 50% of the time, so I can fit in some reading.
I have been doing some searching into the ARM cortex processors and development kits for those, there's a huge range of chips. The ARM processor is supposed to be the most widely used in the industry, so I'm thinking of also investing in this in the future. I'm surprised how many different levels of programming language there can be in a single application.

I unfortunately know very little about the Canadian education system, I moved here four years ago. My employer has no flexibility, so unless I can do night classes or distance learning it's going to be difficult. I'm not entirely sure yet whether I would like to be a programmer as a profession or just keep it as my hobby, I have lots of projects to do, so if it is interesting I will seek education. Otherwise I do have a long-term plan for my education in two years, when I've saved enough and can quit my job.

*I also like to avoid bit-banging since it's slow. It's been a while since I put that project together, but I believe I kept the SPI for the SD card and display. And then bit-banged the other SD card and some flash chips. I also bit-banged an external SPI bus to other microcontrollers since these were running at a different speed. The bit-banged parts were info that was used infrequently. Doing all this in a single document got real messy, so I'm almost going to start again because looking at it now seems silly.

*The STM32 are what I've been looking into, a lot cheaper than what I expected, plus a lot more capable than the PIC. One of the boards I'm looking at has a lot going on, it will be a steep learning curve, but a Linux operating system seems to be the norm for hand-held devices, so I'll eventually get this to learn with. https://www.st.com/resource/en/data_brief/stm32mp157a-ev1.pdf

Thanks to both of you

 

[betwixt]

You will find one of the strengths of C is its portability. Obviously some tasks rely on features present in particular processors but the 'glue' holding all the code together is standard from small PICs right up to supercomputer mainframes.

You will find C++ is not used much with smaller systems, I think the reason is it is geared more towards programming convenience than code efficiency. OOP is great for making different functions appear to have a common interface but behind the scenes that involves much duplication of code, much of it probably not used in the final application. Plain 'C' is more aligned to assembly language, it is more like a structure for binding subroutines together and is for the most part compatible and can be inter-woven with assembly sections. You shouldn't have any problems learning it and it is of course almost entirely supported across all devices and operating systems.

I use Microchip and Espressif devices mostly, programming in assembly language and C on devices from both companies. All my development is done on PCs running Linux with final debugging on real devices of course. I'm completely self-taught, still learning new tricks and at not far off three times your age so don't despair!

Brian.

 

[wwfeldman]

This was the discussion on a slightly different question


https://www.edaboard.com/showthread.php?387068-Learning-psoc-technology

 

[Aussie Susan]

I also suggest that you move to C because it will give you the flexibility to move between devices from different manufacturers. That does NOT mean to say that the code is portable between them (mainly because you are often referring to the hardware register names and they vary between devices within a manufacturers family as well as between manufacturers) but because the principles are the same and it makes coding a lot faster.
I recommend against C++ - you may find there are some C++ capable compilers for the larger (i.e. 32-bit and bigger) devices but you really need to be familiar with the C coding style before you start layering on the extra capabilities (and complexities) of C++.
I use Microchip, Cypress PSoC (5 and 6), and ST Micro devices and I've started playing with the Expressif MCUs as well. Using C allows me to move from one to the other fairly easily (once you understand the relative APIs where necessary). Also a number of manufacturers use the ARM core and add their own modules around that. They typically provide libraries and code generation systems as well but these can be a mixed blessing: ARM devices tend to be a bit complex to initialise and having automatically generated code can help but(especially for the Microchip MCUs) you really only need library code for complex software stacks (IP, USB etc.) and writing directly to a module's registers means you know exactly what is going on. Library code (unless you have the source and/or really good documentation - which is rare IMO) can hide subtle things that are happening that impact on how your code operates and can be very hard to debug.
As to which manufacturer you should go for, I would start with what you know - the 16 bit MCUS from Microchip are really very powerful and a small step up from the 8-bit devices.
Also I suggest that you start with a specific project in mind and select a device that will handle that. A more capable device can do the simple things(flash a LED etc.) as you learn who to use the thing but it can be a bit harder to swap devices mid-stream when you reach the limits of a smaller device.
Susan

 

[JoePage]

Thanks for the input everyone!

I picked up my old project with the OLED touch display, turns out its 800 x 480 and for some reason I chose to bit-bang everything, maybe the circuit board layout was easier.

I started the project in C and found a library for the display, this made things a lot easier. I put some code together for the SPI bit-banging and so far everything is working great. I'll soon be writing some code to initialise the SD card and send an image to the display. Before all of that I'm going to learn some more C, so far a lot of it is making sense, the hardware side especially easy. I think I need a lot more experience on the coding side before I continue with my project, but I feel I have some direction.

I'll probably update at a later stage when I'm at a more advanced level. On a side note, is there a source code for a FAT32 system anyone recommends? I have written one that reads and navigates in asm, and removes all the obsolete directories, but nothing that writes to the FAT. Also is there a particular website anyone recommends for source code?

Thanks,
Joe

 

[danadakk]

Not to throw a wrench into the mix but there is a series of parts, Cypress, PSOC,
all ARM cores that might be of interest.

The distinguishing feature is also onchip are a number of analog components,
like OpAmps, Comparators, Muxes, DACs, Vref +/- .1%, DelSig to 20 bits, SAR
to 12 bits.

And logic from simple gates to complex items like PWM, Counters, Timers, SPI,
UART, USB, LUT, DSP.....

Part has ability to design your own components (a component in PSOC lingo is
an onchip resource). Community has done a number of them, like 74 MSI logic
parts to DDS, dense PWMs....

All these you drag and drop onto schematic, right click and config. All have pre-written
api calls to manipulate in real time. You then wire them up, to each other or pins,
and program the part.

IDE (PSOC Creator) and Compiler free, boards $ 10 and up. I use mostly the $10
boards.

You can do codeless (CPU not used) designs to full blown C designs. Lots of videos,
hundred of projects already done.

Here is an example (not using most of the chips resources)




Regards, Dana.

 

[betwixt]

I think you are hijacking this thread. PSOC is a specific product for developing real estate on silicon, it has nothing to do with general programming or which language is optimal.

Brian.

 

[KlausST]

Hi,

SPI and not bit banging.
For sure you are free to use multiple bitbanging SPI if you like.
I just want to tell you how we do it ... maybe you find it useful, maybe not.
In an application we do: (single hardware SPI)
* SPI full 4x20 display update every 250ms, we split it in 4 transfers, one line each
* SPI sensor communication, once every 10ms
* SPI data communication with EEPROM
* SPI data communication with FLASH
* SPI communication with a PLD, once every 10ms
* SPI bus extender communication 3x316 bits every 10ms
(Besides this, 640 smpls/s x8 channels ADCsampling and filtering, 3 UARTs communication, machine control loop)
We use an STM32F107 with 72MHz. SPI (and most other periferals) with the use of DMA.
All runs continously at the same time, no process is stopped nor slowed down by another process.
For the SPI we have a 74HC138 as address selector, so we can use the dedicated nSS signal.
We controlled all the jobs with a time slice state machine running every 1ms in an ISR.
Main loop including machine control loop is running every 10ms.
Before the usual SPI trasfer we have a very short function that sets the SPI address while - with the use of a lookup table - it sets the SPI speed for the device.
So the funcion for an SPI transfer looks like this: (pseudocode)
SPI_RxTx_DMA (SPIdeviceAddress, pointer_toTxArray, pointer_toRxArray, byteCountToTransfer)
The complete transfer is done by the SPI hardware without processing power.

Now maybe you think with all the jobs above the micocontroller is quite busy.
We did a measurement:
Time_slice_1ms_ISR plus main_loop usually takes less than 50us every 10ms.This is just 0.5% of processing power.
Maximum time we measured (with heavy PC to SPI_EEPROM communication, full 115kBaud) was about 500us / 10ms.
Averaged processing power (including all other asynchronously running ISRs) surely is below 2%.

This project was used to learn the about the (for us new STM32xx) microcontroller family.
We did a lot of optimizing. Code was written in C. We tested the borders. Exessive use of DMA and dataArrays to avoid copying data from one variable to the other.
A lot of effort, we surely will not do with every other project.
But we learned a lot. Amazing processing power, amazing benefit of the hardware features..

Again: I don't want you to do your programming the same style. It was a test. But it showed that if one thinks there is a lack of processing power ... one just has to read the manual and learn how to use the hardware features of a modern microcontroller efficiently.

Klaus

 

[danadakk]

From TS original post -

I am now wanting to get ahead with times and move onto something more capable, also learn software that's up to date / what everyone else is using.

I took this to be both ease of programming and HW capability ?

Not sure what you mean by this -

developing real estate on silicon

Its a part with both standard HW functionality and some fabric, which can be
used as fabric and/or to create custom functionality, is that what you referring to ?

In so far as programming ease, given that he was doing coding from scratch ASM,
PSOC, like most modern processors, their respective IDE tools, include all the low
level asm like f()'s prewritten into C f()'s for use.


Regards, Dana.

 

[c_mitra]

I am currently a machinist but I don't quite have the means for university yet. I'm 27, so should still be capable of learning

Yes, learning is not difficult. Learning C is going to have long term dividends as you are planning to programming as a career. Good thing is that you can learn it on the job. C can be messy but you can certainly find help from various communities.

The current microcontroller I use are the 18F series of PIC microcontroller, I have only ever used assembly and honestly have no idea about C programming or any other for that matter.

The first PC AT BIOS, written by IBM was in assembly. But you can be sure that it is not the best for regular day-to-day programming because you have access to a large number of tools while you program in a high level language (e.g., code optimizations).

But why you cannot learn the language yourself? I started with FORTRAN, then PASCAL and finally C. All on a simple PC with public help. I did take time but I understand the language. And I can always use public help. You need to learn the basics and you can always refer the manual for the more difficult ones.

Once you have developed some confidence with simpler microprocessors, you can move onto more complex ones that offer multitasking and processing. Yes, you will need them sooner rather than later.