AVR vrs PIC (I don't care)

[large_ghostman]

After reading these posts I looked at the Arduino IDE briefly (never done that before) and it looks kind of cute to me. It does create a layer of hardware abstraction. It is really easy to start blinking LEDs or outputting "Hello World" on LCDs (don't have Arduino to actualy try, but easy to do the software). However, when you're programming multitasking controller it may not be the best thing.

It reminds me of Visual Basic, which lets you create some simple programs really quick, but won't let you do anything complex. But hey, people wrote commercial programs on VB.

I would agree that software development for MCUs will undergo certain Arduinization in the near future and we may even see "managed" solutions alike C#. As it will allow hundreds of people to start doing MCUs, the needs of sparse programmers doing it the "old" way will get depressed. To cover all the inefficiencies, the more and more complex and powerful MCUs will be developed and become standard. Software will get buggier and buggier. At the end, MCUs will get extinct because new devices will be capable of running Linux, which will be a real break-through on the programming simplification route.

The "advanced instructions" in PICs don't add much and don't really improve anything (I may be sllightly wrong here, I judge by PIC24E comapred yo PIC24F). I think it's more of a marketing stuff - new PICs designed for C - why would anyone buy other processors which are not designed for C?

Taken from the datasheet

Extended Instruction Set:
The PIC18F2682/
2685/4682/4685 family introduces an optional
extension to the PIC18 instruction set, which adds
8 new instructions and an Indexed Addressing
mode. This extension, enabled as a device con-
figuration option, has been specifically designed
to optimize re-entrant application code originally
developed in high-level languages, such as C.


Does it only seem nuts to me, that you then bring out a new compiler and IDE that cant use, these extra instructions which were designed to be used with there C compiler!!! The worse bit is, you have to disable the extended instruction set in the config settings or your code dosnt compile correctly, also on the forum there is talk about the usb stack, that has to be altered because it used some of the extra instructions, and now it cant.
I would like to use pics again, but for now anything new I wont to do will be 8051 or ARM, I find ARM far easier to get to grips with.

 

[Mickster]

Oh and read the passage again, it clearly states.


The flexibility gained from using the PIC microcontroller played a pivotal role in enabling the successful manufacture of over 40 million systems that have been delivered to provide optimal protection for vehicle occupants.

played a pivotal role.

To me that says pics arnt actualy in the system they just played a part in getting it together, and yes the keyloq thing is in keyfob's and radio's. A nice little earner for them.

You are dissecting the latter, without addressing the former, with regard to the whole paragraph.

A PIC microcontroller is the “microcontroller of choice” for one of the leading airbag crash sensor modules in the marketplace. Our sales and application engineering team worked with the system designers to take the reprogrammable memory technology of a standard product and integrated it into a creative solution to address complex needs. The flexibility gained from using the PIC microcontroller played a pivotal role in enabling the successful manufacture of over 40 million systems that have been delivered to provide optimal protection for vehicle occupants.

"A PIC microcontroller is the “microcontroller of choice” for one of the leading airbag crash sensor modules in the marketplace."
The particular manufacturer IS using a PIC.

"Our sales and application engineering team worked with the system designers to take the reprogrammable memory technology of a standard product and integrated it into a creative solution to address complex needs."
The engineering team took a standard (PIC) product and evolved it to perform further requirements, as dictated by the market. That is how new products are created - The customer wants X, they work with the customer to produce X and the results trickle down. Newer PICs are produced, with improved features and additional peripherals.

Then we get to the latter part:
The flexibility gained from using the PIC microcontroller played a pivotal role in enabling the successful manufacture of over 40 million systems that have been delivered to provide optimal protection for vehicle occupants.

If Microchip weren't flexible in their approach to accommodating the customer's requirements, by adapting their product to suit the need, another manufacturer would have been. The result was in Microchip's favour and they got 40+ million device sales as a result, plus an exercise in product development in an important market area.

My opinion doesn't mean very much to any manufacturer as a whole, since I am not buying in production quantities, and any manufacturer targeting the hobby side of the business is not going to grow very quickly.

Sorry for not addressing the other parts of your posts, but I wanted to clear things up with respect to the point at hand. PICs are in use, in systems which you haven't come across yet, in large volumes.

Regards LG.

 

[be80be]

The Arduino is a big name put on a bunch of stuff but its not just a chip. Like say you pick a UNO it has the Atmaga 328 the ide can use any

Arduino language is based on C/C++. It links against AVR Libc and allows the use of any of its functions; see its user manual for details.

That opens the chip up to you. I like the one I have cause it made a cheap USB programmer for Atmaga chips

 

[Ian Rogers]

LG!! don't let it get to you... Pic's have their place as does ARM... I use MPLAB and XC8 AND!!!! C18

I rarely have an issue.... Don't be too quick to dismiss the humble pic.. For £14 you can but a chipkit sporting a pic32.. Why don't you try!!! I put on the PK3 header and now use it as a dev board... All the Ardunio shields plug in so I don't have to develop anything..

I find the pic32 a decent chip.. certainly gives ARM a run for its money... I'm not dismissing the silicon chips boards.. They are very good..

But for a lone developer that hasn't got much ready cash to start up!!! Microchip has it covered..

 

[large_ghostman]

Ian, nothing is getting to me, Mick is really interesting in what he say's. He reads it and interprets it one way, I read it and I see a whole other meaning. The only people who know for sure is microchip.
Yes millions and millions of pics everywhere. But I think the paragraph we are talking about is marketing trickery. I think Mick reads it the way clever marketing people want it read, I process things in a different way, I am wired different, If they were targeting the info at me, Then it would HAVE to say, This chip is being used in 40 million whatevers, by (insert car maker), anything else to me says they are bending facts.
Mick could be spot on. Makes no difference, it isnt written in a way I would except as truefull. But I appreciate Mick's attempt at making me see it the way he reads it. It helps me understand what the differences are between how you (normal people) and me, take information and process it.
Pics are great, That isnt my gripe.
Arm without doubt will become the big boy, pics will still have a place. Maybe I will find a IDE FOR pics that I like again, and I will use them once more.
As for shields etc, My opinion isnt valid, I have never used them. So everything I could say would be based on what others think, So thats hardly fair of me to comment.
The only thing that struck me about this thread was the whole pic v arduino.

To me its like being on a holiday site where the argument is always say, greece is a better holiday than spain. And no one ever mentions any other destination.
That is what actually interests me, why is the comparison always between those chips and not others? Genuinely intrigued by that.
And again Thanks mickster for taking the time to show me your take or what they have written. No I dont agree with you at all on what it means. But that isnt important, the chance to be able to challenge and respond is what matters, that is how I learn to understand how I process things.

 

[3v0]

Arduino does not incorporate new technology . Everything it has existed to some extent in the past. Just maybe not one a single system.

Thinking about it a single board forth system from the 80s offered much of the same features.

About the only new thing here is the notion of sketches, or are they. I need to look at one some day.

LG did you watch the EEV Blog thread. Although I had not seen it when I started the thread Dave sums it up well. Use what you darn well please, it should not make a difference to anyone but you. uC's are much like nuts and bolts. As long as they do the job who cares who made them.

The 'not caring' is not exclusive to AVR and Microchip. There two were mentioned in the title because it is the most frequent debate.

 

[misterT]

About the only new thing here is the notion of sketches, or are they.

No, it is just a library written with standard C++.. with some coding trickery to make the main program look simpler to the user. All sketches are compiled with a free 3rd party compiler (AVR-GCC).

 

[3v0]

No, it is just a library written with standard C++.. with some coding trickery to make the main program look simpler to the user. All sketches are compiled with a free 3rd party compiler (AVR-GCC).

I was thinking it was something like that but did not want to stick my foot into it.

You statement "look simpler to use" is a good one. The tools that do this can get people going a bit faster but to get up to speed is still the same amount of work. IMHO

 

[misterT]

You statement "look simpler to use" is a good one. The tools that do this can get people going a bit faster but to get up to speed is still the same amount of work. IMHO

Yeah, maybe we have to admit that it is good marketing. But very annoying, because so many hobbyists are now confused what a microcontroller really is.

- They use the free avr-gcc compiler.. the same one that comes with the excellent (free) Atmel Studio IDE
- They hide the "scary looking" void main(void) { } -function from the user
- They call C-programming a "sketch"
- They write extensive library to hide most of the hardware dependent code

 

[micropad]

- They write extensive library to hide most of the hardware dependent code

Writing extra library,does it effect to the memory consumption of target device

 

[misterT]

Writing extra library,does it effect to the memory consumption of target device

Interesting question. The compiler and linker should only include those functions that are actually called, but I do not know how precompiled C++ classes are handled.. can the linker optimize those? I have never thought about that.

EDIT:
I think the answer is yes, if you link pre-compiled object (library) files to your project.
But, not so much if you compile your whole project into single object.. something like that.

 

[large_ghostman]

I think I am with you Mr 3V0, For now I try and avoid libs, ok they make it all quicker to do, but then when I have a problem, I have to go take a peek at a register, thats when it gets sticky.
Learning to use say uart without the libs first, means if I get a problem I know which reg to look at and what the bits should be set at, if I use the libs first and it goes wrong, I have to learn about the registers and what the bits do. So this probably just applies to me, but I need to learn the hard bits before I can then use the easy quicker ways. If that makes sense.
C has been a struggle, but the turning point wasnt actually the language itself, the hard bit is knowing what you have to set up first, like OSCON and what ports need to be altered from analogue to digital first. This isnt a C language problem, its a datasheet problem, or rather a lack of good tutorials focused solely on how to get the information you need from the datasheets.
I have several C books, all explain WHILE loops etc the same way. None of them tell you anything about how to read a datasheet and get the information out.
The ARM attraction is also partly because it gives me the chance to learn C then move on to C++ using the same chip.
I do watch EEVBlog, and he is right in a way. For most people it matters not what is used, some are happy with basic or flow code, it will do what they want with little pain. But for some people that isnt enough, some of us want/need to understand how its done.
Ultimately it boils down to opinion, and like bottoms everybody has one and they are not always the same.
I admire those that can do pages and pages of ASM and follow what the program is doing, for me ASM is too cryptic, being dyslexic makes acronyms difficult.
What I like about the tool chain I use for ARM is actually alot like the bit in mplabx, where you set the config and it does the code. Its done slightly differently with the tool I use but its close.
Its a good learning aid, point and click set up the chip, get the code dumped in front of you, then you can go looking at the datasheet to see why the code is the way it is. Many might disagree and I can see why, but for me its a good way around some the problems I have when learning. I learn more by demonstration than just being told.
A good thread tho, always interesting to know why people choose what they do.
If I remember correctly Cobra1 made a pretty good aquarium controller out of mainly flow code. It did what he wanted, and was pretty good. But I expect he is/was limited to being able to fine tune it later.
I cant remember what we use in IT at school, because I no longer go to the lessons for IT, but they use a language apparently very much like a cross between flowcode and lego mindstorm, it was developed for schools, my IT teachers love it, you can make robots and all sorts.
But it teaches you nothing about what is going on. Instead of IT I have home tuition on those days for extra maths, and to learn the different curriculum, my IT scores were good, so it was decided to use those days to learn things I needed.

 

[misterT]

LG: Avoiding third party libraries is a good idea with simple devices/peripherals. Just like you said.
When you need to use the USART, for example, write your own library module. It can be as simple as a separate code file containing only USART related stuff with good commenting. No need to actually compile it to a library object. Eventually you will have your own library.. or a set of re-usable modules.. whatever you want to call it.

Libraries are important part of programming, but you should not use them blindly. If I would need to implement bit-banging USB, I would search for a free library, because the programming task is huge. But it does not mean that I do not have to learn how USB works.

 

[large_ghostman]

I have the odd attempt at getting usb to work, but so far no luck, then I discovered usb to serial cables and the need to use usb for me went away. But yes I would use a stack someone had written and make changes to fit what I need, Microchips one is ok, the main problem is they have lumped it all into one. It would be easier to have say a stack just for HID, no other files just files for HID,then you could start getting your head around it.
But again your spot on with having to know about it, I got an example from I think pyro electro working, but what I didnt know know was it was just constantly polling for usb, when I looked at the pc task manager, the processor was tied up just constantly looking at the usb.
But for simple on chip stuff I prefer to just poke the 1's into place . for now anyway.
The PSP has me intrigued, I keep reading the datasheet but am convinced I have it wrong, If it does what I think it does then you can also control the pic from it. Thats for another day.
ADC is another good one to learn, the lib hides most of it from you, but it isnt actually hard to get it to do what you want with the registers.
CAN I have mixed feelings about, also like USB, its a bit of a steep curve.
EEPROM (on board) might as well use the libs as not much exciting to do or see.
IRDA I am playing with now, as I need connection to pda over IRDA link. no comment yet havnt looked at it much.
SPI thats a must do yourself one, much more to be learnt from setting all that up yourself and pretty easy.

So C isnt hard to learn, whats hard to learn, is everything that goes on before (void) main(void)or more to the point everything before
whle(1) {
}

 

[NorthGuy]

Many PICs have modules which do things in the hardware without using any processor time. UART modules are good. CAN module in PIC24H is very good. Cannot tell about USB, but USB is very high speed so if you bit-bang it you may not have time to do anything else. A USB to Serial chip can do all the work for you.

 

[large_ghostman]

Many PICs have modules which do things in the hardware without using any processor time. UART modules are good. CAN module in PIC24H is very good. Cannot tell about USB, but USB is very high speed so if you bit-bang it you may not have time to do anything else. A USB to Serial chip can do all the work for you.

Sorry North Guy, I think I have totally given you the wrong idea!
I wasnt talking about not using the modules, I do use them for the reasons you state. What I was meaning was. I dont use the libs that you get with the compiler to use them,

for example
This is some of the set up from C18 for the on board UART, if you use #include uart.h, then you can set it up using something like the following example

Interrupt on Transmission:
* USART_TX_INT_ON
* USART_TX_INT_OFF
* USART_TX_INT_MASK

Interrupt on Receipt:
* USART_RX_INT_ON
* USART_RX_INT_OFF
* USART_RX_INT_MASK

What I prefer t0 do for now, while learning, is to actually set the registers myself, so if I want to say put the usart interrupt on transmission on, I wouldn't use

USART_TX_INT_ON

what I would do is actually set the registers myself in code. that way I learn what bits of what registers do what. I dont bit bang anything the chip can do onboard if i can help it.
but while learning
USART_TX_INT_ON dosnt tell me what bits in what registers were set. But setting them by hand does,
Really sorry I gave the impression I was talking about not using the modules! Can is on my must have a go at list!!!!

 

[3v0]

Not using libs especially ones without source code can be a good thing. But you don't have to shun everything provided.

For example reading code with USART_TX_INT_ON is more informative than the same code written with a binary literal.

And by the same token libs with source code should be considered unless one is the learning mode.

 

[large_ghostman]

Not using libs especially ones without source code can be a good thing. But you don't have to shun everything provided.

For example reading code with USART_TX_INT_ON is more informative than the same code written with a binary literal.

And by the same token libs with source code should be considered unless one is the learning mode.

Yep I agree and again only half assed explained, Take something like CAN which I want to try, That I will do back to front, I will get it up and running using the LIB, then once working, I will go through the code and take it apart, and use the registers instead, Yes I do read the libs code, so I get an idea what order to do things etc. Sorry for really messing up explaining how I do it! I dont shun the libs and I do use them, but normally only after I have done it the other way!
After all once you know what bits of say ADCON1 do, and have changed them manually a few times, and got the ADC working that way in a couple of projects, then when I want to use ADC again I use the libs for speed, but if I get a problem and need to debug, then by that point I know what registers to watch etc.
Man I have made this all sound difficult!!!
So as a sum up
Yes I use LIBS provided for most things, but only after I know how the mod works in the first place .
I admit the USART example was poor, I grabbed it as an example. It does tell you alot because it has been well named etc, but as I said the reason I wouldnt use it at first is because it dosnt tell me what registers its using or which bits, it just tells me, Transmit interrupt is off. so If it was first time using the UART,
I would look at the lib and see that, then I go read the datasheet and find what register/s need to be altered to turn the transmit interrupt off, I then do the code using the register bit names and comment the line.
Next time I use uart I will mix and match, for example I always set it up by hand, but would always use the READ function etc from the LIB.
Its purely my way to make the learning stick, I read the libs alot and learn alot from them.

 

[NorthGuy]

The tricky thing about UART is not how to set bits, but how to use the module so that it (a) doesn't interfere with other operatons, (b) doesn't stall, (c) has a flow control so that nothing get lost. The library gives you an impression that these things are taken care of, but, in fact, it's a very thin layer which doesn't add much. People use the library and don't think twice about consequences. Ever heard of devices bricked during firmwre upgrades. That's one of the reasons.

The real functionality is in the hardware, not in the library.