Author Topic: Atmel vs Pic in Linux environment  (Read 15553 times)

0 Members and 1 Guest are viewing this topic.

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: Atmel vs Pic in Linux environment
« Reply #25 on: June 24, 2017, 06:11:06 pm »
That'd be one of the colors that needs more than 3.3V, eg. blue, white, green.

Have you actually tried it? Because if you did, you wouldn't write this.

Common green LED has Vf around 2V. Even blue LEDs work just fine from 3.3V supply.

This video hopefully proves that you can certainly drive a blue (and thus likely white LED too as they have the same Vf) and green LEDs from a 3.3V micro:


Heck, many white and blue LEDs work from 3V lithium coin cells.
https://youtu.be/YgHmks7PoQo?t=17

And you can always make the I/O pin sink current and connect the anode of the LED to a higher voltage if the voltage of the logic one on the pin is not enough for the LED to turn on. But that's really a very basic thing.

Of course, I am not going to claim that all LEDs are made equal, but you can certainly find enough LED types that will work.
« Last Edit: June 24, 2017, 06:21:23 pm by janoc »
 

Offline rolycat

  • Super Contributor
  • ***
  • Posts: 1101
  • Country: gb
Re: Atmel vs Pic in Linux environment
« Reply #26 on: June 24, 2017, 06:17:37 pm »
That was true a decade ago. Nowadays people go for ARM based processors and for good reasons: PIC (8 bit) and AVR are archaic architectures and will run out of memory and processing power real quick.

They both are about equally archaic. First PIC appeared in 1976, first ARM in 1981.

'Archaic' means antiquated or primitive, not just of a certain age.

In any case, the first ARM processor was created in 1985, not 1981 - almost ten years after the first PIC.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Atmel vs Pic in Linux environment
« Reply #27 on: June 24, 2017, 06:19:32 pm »
You can get a feel for the variety of boards that work using the 'mbed' concept of an online toolchain by looking here:
https://developer.mbed.org/platforms/

To use the toolchain, you have to actually buy a board and use the .htm file on the board to register the device.  No cost but still there is a registration hoop to jump through.

8 bit PICs like the 16F family are often a good solution but they have a truly ugly architecture.  They are a PITA to program with assembly language and C compilers spend most of the code creation dealing with banking and paging.  Until recently, there simply weren't any decent compilers because the chips were too limited to handle the language.  An 8 level (fixed) stack is not encouraging.  I don't know what compilers are doing for this family at the moment, I walked away years ago.

On the subject of AVR, if you want to use AVRs, you might as well use Arduinos and there is a ton of example code and libraries available.  Everything that can possibly be done with an Arduino has been done and the program is out there for downloading.  In my  view, it is absolutely the fastest way to get started with microcontrollers.  The Mega 2560 is a pretty powerful board but the standard Arduino Uno is quite capable and pretty much the benchmark device.  You can also design an ATmega 328p project using the Arduino board as a programming platform and then plugging the DIP chip into some other board.

ARM is where all the new work is being done.  There are several flavors with advancing capabilities but the more modern Cortex Mx devices are easy to program (in the sense that assembly code is no longer required) but can quickly get to be overwhelming with their peripherals or the provided HAL libraries.  I have a hard time getting up the enthusiasm to use these libraries because instead of writing the code I want, I wind up having to understand the code I got (including interactions with everything else on the chip).  I'm just not a fan of the abstractions.

That said, I am happy enough to use the mbed library (adding my own interrupt handlers) and the provided TCP/IP stack.  I certainly don't want to recreate those but for a somewhat smaller project, I would prefer to start at the iron and work up with my own code.  Like I used to do with the LPC2106 and LPC2148.  Writing code right down in the dirt.

Alas, the more modern chips are probably sufficiently complex that it doesn't make sense to work at that level.

Summary:  I would start microcontrollers with Arduino projects.  I would progress to the LPC1768 mbed and if I needed more, I would look at some of the STM offerings.  One way or the other, you have to start somewhere.

 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Atmel vs Pic in Linux environment
« Reply #28 on: June 24, 2017, 07:59:20 pm »
I think it is good to be aware of, and to learn ARM and not to be so insular as to only have AVR in your toolkit. But there is nothing wrong with AVR for many applications.

FWIW I used to program ARM in assembly language back in the 1980s.  :popcorn:
« Last Edit: June 24, 2017, 08:14:45 pm by Fungus »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Atmel vs Pic in Linux environment
« Reply #29 on: June 24, 2017, 08:13:44 pm »
I have a hard time getting up the enthusiasm to use ARM libraries because instead of writing the code I want, I wind up having to understand the code I got (including interactions with everything else on the chip).  I'm just not a fan of the abstractions.

Yep. I also have a lack of enthusiasm for them. They don't fit anything I do.

For basic uC work I already have something that gets the job done at a throwaway price (ATMega328 chips on $2 boards).

I know how to optimize code, I've written arcade-perfect Space-Invaders (with sampled sounds) on a Mega328, I've written Tiny85 raytracers for fun. If I need more than a Mega328 I always need a LOT more, eg. video output or WiFi or something like that, things those little ARM modules don't offer.

« Last Edit: June 24, 2017, 08:16:40 pm by Fungus »
 

Elf

  • Guest
Re: Atmel vs Pic in Linux environment
« Reply #30 on: June 24, 2017, 08:15:03 pm »
Teaching Grandma to suck eggs?

I used to program ARM in assembly language back in the 1980s.  :popcorn:
Good for you? I was trying to support your point, and was addressing the people who seem to think that ARM (PSoC, whatever) is the only legitimate solution to any problem. I assumed that this would be clear from the context of my previous posts.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Atmel vs Pic in Linux environment
« Reply #31 on: June 24, 2017, 08:18:29 pm »
I was trying to support your point, and was addressing the people who seem to think that ARM (PSoC, whatever) is the only legitimate solution to any problem.
I know, but you also implied I only have AVR in my toolkit.

(or maybe you meant the world in general and I misunderstood)
 

Elf

  • Guest
Re: Atmel vs Pic in Linux environment
« Reply #32 on: June 24, 2017, 08:21:33 pm »
I know, but you also implied I only have AVR in my toolkit.

(or maybe you meant the world in general and I misunderstood)
No, just that for a beginner I would recommend that they also learn ARM, and not just AVR if that is their main choice. Really, whatever your personal preference is (as in, anyone, not you specifically), I think it is good to learn and regularly use at least a few different types of platforms.
 

Offline colorado.rob

  • Frequent Contributor
  • **
  • Posts: 419
  • Country: us
Re: Atmel vs Pic in Linux environment
« Reply #33 on: June 24, 2017, 08:22:43 pm »
:wtf: happened here??

No one cares what your favorite microcontroller is. |O

The question is what meets the OP's needs.

BTW, there are other forums better suited for this sort of question than the "Test Equipment" forum.  We've got a forum dedicated to microcontroller questions.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Atmel vs Pic in Linux environment
« Reply #34 on: June 24, 2017, 08:24:13 pm »
and was addressing the people who seem to think that ARM (PSoC, whatever) is the only legitimate solution to any problem.
Nobody is claiming that but with ARM you have the widest choice in vendors, microcontroller complexity, lots of speed, low power if you want, it is a 32 bit architecture, it is fast, etc, etc so it is a very good choice to use ARM especially if you start. Almost any other choice will you hold you back in some way.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Elf

  • Guest
Re: Atmel vs Pic in Linux environment
« Reply #35 on: June 24, 2017, 08:35:38 pm »
No one cares what your favorite microcontroller is. |O

The question is what meets the OP's needs.
Unfortunately I think when you have <Product A> vs. <Product B> anywhere in the title it sort of degenerates to this; Ford vs. Chevy, etc.

As far as the original question goes, I think AVR has a good toolchain available under Linux:

While there are tools for PIC available, I wouldn't call the 8-bit PIC lineup very C friendly.
 
The following users thanked this post: jiro

Offline alm

  • Super Contributor
  • ***
  • Posts: 2840
  • Country: 00
Re: Atmel vs Pic in Linux environment
« Reply #36 on: June 24, 2017, 09:25:22 pm »
You conveniently left out debugging :P. I think debugging is the weak point for AVR, both hardware and software. For hardware you can get the bare board for $50 or the more usable one with case for $100. Both PIC and STM32 have more affordable tools (especially STM32 with a $10 bare board and $20 with case and proper buffers). As for software, avarice works but development does not seem very active (last commit > 1 year ago, never mind the last release). Also support for currently available debuggers seems limited.

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Atmel vs Pic in Linux environment
« Reply #37 on: June 24, 2017, 09:27:10 pm »
No one cares what your favorite microcontroller is. |O

The question is what meets the OP's needs.
Unfortunately I think when you have <Product A> vs. <Product B> anywhere in the title it sort of degenerates to this; Ford vs. Chevy, etc.

As far as the original question goes, I think AVR has a good toolchain available under Linux:

While there are tools for PIC available, I wouldn't call the 8-bit PIC lineup very C friendly.

The ATmega128 used to be one of my favorite chips.  I used exactly the toolchain above on Linux.  I really LIKED writing code for that chip.  It's an old chip by today's standards but it is fun to work with.

It does require makefiles and 'make' but even that is fairly easy.  Once you have one Makefile, you pretty much have them all for a given architecture.

I didn't find that Eclipse brought all that much to the dance and would often just use 'gedit' and 'make'.  I don't mind messing around at the command line.  It's important to remember that this was more than 10 years ago and Eclipse has improved greatly.  For my PC Fortran coding, it even creates the makefiles.  It may do that for C projects as well but I haven't done a lot of that in recent years.

No, I didn't use 'vi' or 'emacs'...
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Atmel vs Pic in Linux environment
« Reply #38 on: June 24, 2017, 09:41:48 pm »
'Archaic' means antiquated or primitive, not just of a certain age.

How PICs can be antiquated when new models are released almost every month?
 

Offline rolycat

  • Super Contributor
  • ***
  • Posts: 1101
  • Country: gb
Re: Atmel vs Pic in Linux environment
« Reply #39 on: June 24, 2017, 10:55:24 pm »
'Archaic' means antiquated or primitive, not just of a certain age.

How PICs can be antiquated when new models are released almost every month?
In the message to which you responded, nctnico stated that 8 bit PIC was an archaic architecture.

Putting lipstick on a pig does not make it less of a pig.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Atmel vs Pic in Linux environment
« Reply #40 on: June 24, 2017, 11:19:37 pm »
'Archaic' means antiquated or primitive, not just of a certain age.

How PICs can be antiquated when new models are released almost every month?
In the message to which you responded, nctnico stated that 8 bit PIC was an archaic architecture.

I'm sure he meant "old", not "antiquated". Microchip still makes and sells lots of PIC16s. They're still the best for the tasks they're designed for - low cost, power, space. And new models are substantially better than what they had 10 years ago.

Of course, there are lots of people who prefer blinking their LEDs with ARM rather than with PIC, but this has nothing to do with architecture.
 

Online igendel

  • Frequent Contributor
  • **
  • Posts: 359
  • Country: il
    • It's Every Bit For Itself (Programming & MCU blog)
Re: Atmel vs Pic in Linux environment
« Reply #41 on: June 25, 2017, 12:42:29 am »
Putting lipstick on a pig does not make it less of a pig.

Core Independent lipstick, please!  :D

Seriously though, these trash-throwing discussions on MCUs are getting tiresome. Can't we all just... get along?  :(
Maker projects, tutorials etc. on my Youtube channel: https://www.youtube.com/user/idogendel/
 

Offline stj

  • Super Contributor
  • ***
  • Posts: 2153
  • Country: gb
Re: Atmel vs Pic in Linux environment
« Reply #42 on: June 25, 2017, 12:42:56 pm »
the stuff is so cheap, just buy it all!

a USBasp is about $2
an atmega328 on a pcb is about the same,

an stm32f103 on a pcb is about $2,
a chinese stlink is about $2

just get it all and have enough change from your 10-bill to get a bottle of beer!  :-+
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Atmel vs Pic in Linux environment
« Reply #43 on: June 25, 2017, 02:11:43 pm »
MPLAB X works on Linux.

8-bit compiler (XC8) is Ok. The paid version is slightly better.

16-bit compiler (XC16) is mediocre. PIC24/dsPIC33s have very reach instruction set and the compiler doesn't take full advantage of it. But it's fine if you don't need to push these PICs to the limit.

32-bit compiler (XC32) is good - the MIPS processor is a RISC processor optimized for C.
I disagree on XC16.

No optimization is crap, granted, but O1 is so much better, and included in free version.

To get the most out of the chip one should read the compiler manual...

for example, if you want to use the hardware divider you have to use the __builtin functions (or ASM)
This is because the hardware divider is 32/16 bit and cannot detect 16 bit overflows so the compiler will always use a software algorythm. If you are sure you will have a 16 bit result just use __builtin

Same for DSP instructions, and other things you would otherwise write in assembly
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Atmel vs Pic in Linux environment
« Reply #44 on: June 25, 2017, 02:14:23 pm »
Re: 8 bit is archaic, that's mostly true. I have to re-do a wireless remote that used a 16f... and this time i'm going to use the lowest power arm chip i can get (or a pic24/pic32mm)

Oh, the headaches...
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Atmel vs Pic in Linux environment
« Reply #45 on: June 25, 2017, 02:51:51 pm »
Some people seem to believe that the "free" version of the Microchip C-compiler doesn't support all optimizations.
This is not necessarily true. It's what Microchip wants you to believe.
The C-compiler "from Microchip" is actually a copy of GCC (GNU C compiler). Because GCC is opensource (GPL) and
because Microchip can not claim any rights on GCC, it's very easy to disactivate the artificial limitations built-in in GCC
by Microchip. It takes just 5 minutes of your time. No need to reverse engineer any proprietary code or to break any law.
Ofcourse, Microchip will never tell you this...

Edit: Here's the link to a post how to do it: https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099
« Last Edit: June 25, 2017, 02:57:40 pm by Karel »
 

Offline alm

  • Super Contributor
  • ***
  • Posts: 2840
  • Country: 00
Re: Atmel vs Pic in Linux environment
« Reply #46 on: June 25, 2017, 03:06:30 pm »
That only applies to the 16-bit and 32-bit compiler. The 8-bit compiler shipped by Microchip (XC8) is proprietary, and as far as I know there is no legal version that is free and includes full optimization support.
« Last Edit: June 25, 2017, 03:08:13 pm by alm »
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Atmel vs Pic in Linux environment
« Reply #47 on: June 25, 2017, 03:14:33 pm »
The most you can optimize is avoiding continous bank switching... unfortunstely there isn't much you can do with the compiler. The best tricks are done manually (see the piclist.com code archive... tons of goodies and tricks)

But at least the core independent lipstick makes it so you can offload most of the workload :D (and they seems to be making a great effort to cripple the peripherals with MCC)

This applies to pic12/16. XC8 for pic18 has its strangeness (like weird macro to put data in eeprom, builtin functions commented OUT. Not even a warning, but in the source code you see the goddamn comments that says function was deprecated, have the very same one with MCC plus the additional bloat :-- )
But generated code is ok, i guess. I never have to use assembly on a pic18
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Atmel vs Pic in Linux environment
« Reply #48 on: June 25, 2017, 03:18:19 pm »
That only applies to the 16-bit and 32-bit compiler. The 8-bit compiler shipped by Microchip (XC8) is proprietary, and as far as I know there is no legal version that is free and includes full optimization support.

You are right. I tend to forget that because we don't use 8-bit mcu's and only very occasionally 16-bit.

For hobby use, what is the reason to stick with 8-bit mcu's?

 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Atmel vs Pic in Linux environment
« Reply #49 on: June 25, 2017, 03:45:48 pm »
For hobby use, what is the reason to stick with 8-bit mcu's?

It depends a great deal what you want to get from your hobby.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf