which one for noob?
I have some undesrtanding in electronics
>>912244
Depends on what you want to do.
PIC/STM: Buying a box of lego
Arduino: Buying a newer box of lego with those custom made weird looking bricks in there
RasPi: Buying a lego model someone else built
>>912257
Forgot to add, in terms of purity it goes:
PIC -> STM -> Arduino -> RasPi
In terms of ease of use it goes:
RasPi -> Arduino -> STM -> PIC
And in terms of usefulness it is all equal because you use the correct tool for the job.
Sometimes you need to flash a PIC, sometimes you just need to throw a RasPi and some copy-pasted code at it until it works.
I'm a PIC man myself but in fairness I think that's because I got started before the arduino and raspi were even a thing, maybe there's no need to do things the hard way to be honest.
>>912244
Beaglebone.
>>912261
Something I've noticed in many fields is that people will evaluate newer solutions in terms of "how easy is it to do the exact thing I've always been doing?".
So they only see disadvantages to newer platforms, because in trying to use them as faster versions of the older ones, they never see any of the unique advantages.
For example, you'll find people writing mission-critical stuff in Excel, but they've never in their life pressed alt-F11. Or people coding on Raspberry Pis, yet never having touched an IDE or remote-debugger.
BTW sorry for my bad english grammar
But i didnt mentioned arduino, i am talking about AVR-C programming by using registers and etc.
And btw doesnt atmega's has more power than PIC and drains less current than PIC?
BTW, doesn't avr-c would be good start point for learning to program in C?
>>912283
No, it's much easier to learn C on the desktop, where you have much better tools.
AVRs are definitely better for C programming than PICs, but there's a zillion versions of both so you can find a device that fits your needs from either. BTW, the old 8/16-bitters don't have the power consumption advantage they once had. The newer Cortex-M0/M0+ devices are more than competitive, with the advantage of a better development environment with fewer compromises.
My goal is to learn how to use properly registers and data transfer like uart and etc :)
>>912299
It doesn't fucking matter, just pick something and use it. Also lurk moar.
>>912299
Doesn't matter, learn to program first so you don't produce abortions like this: http://pastebin.com/Rn0P0NbE
>>912244
RasPi: Configuring Linux software into a network server, media player, etc. Most RasPi projects are pure software.
Arduino: Making circuits on a breadboard and writing simplistic code to control them.
STM: Making more complex circuits and writing more complex code to control them.
PIC: Surpassed in every way. Why does it still exist?
Thanks everybody
So i decided to learn AVR-C :) not arduino
RasPi- i know about internet technologies just a little bit
STM- i m noob so probabbly it'll be too difficult for me to handle this thing
PIC- its dinosaur surpassed by other
Beaglebone- almost never heard about it, i dont need some rare stuff
Thats in my honor opinion :)
>>912343
>Compares RasPi to Linux
>When in actuality it is the most locked down of the examples provided
You make no sense.
>>912299
>My goal is to learn how to use properly registers and data transfer like uart and etc :)
Then strike out anything with Linux on board (like *pi or beaglebone).
I've never played with PICs, so no opinion on it.
AVR: easy to play in ASM/C/C++, well documented, quite powerful. (I recommend avra for pure ASM and avr-gcc for C/C++)
ARMs in general: selecting the right toolchain and getting started takes time, don't think of ASM, you'll get lost, C/C++ is fine. (for toolchain: probably arm-none-eabi, which has some multilib issues, plus mass of switches depending on exact arch)
In detail:
Cortex-M0: surprisingly weak (comp. power) compared to AVR's
Cortex-M3: nice to start from, it's relatively easy to get a toolchain, find libs and and example codes
Cortex M4+ / M7: powerful + lots of memory = super! (but more complex and more expensive)
I've found it easier to understand AVR manuals, since AVR's have less options and more functional description than ARMs (at least than NXP LPC's).
>>912310
The correct answer.
What I like about PIC is that you can always use the right microcontroller for the job.
Instead of going massively overkill and putting more hardware into flashing a fucking LED than we used to get to the fucking moon then you can trim the fat and use a chip only as powerful as you need, with the instructions you need.
I cringe at today's modern concept of being excessively wasteful in engineering and software design simply because the hardware has gotten to a level which can make up for it. That is so fucking awful.
Sometimes all you need is 12F629, so why use more? Because you're lazy fucks, that's why.
ATMEL studio is nice IDE from first impression, but it wont work on linux :/ even wine cant run it, so i have to use virtual machine with windows to program. Avr dude and toolchain (something like that) is too difficult for me to use.
But assambler is most difficult language to learn, advantage just efficiency?
Maybe someone can give me a hint about simple ide for linux (please no arduino ide)?
I am now learning to use manjaro linux
BTW i m not a rich fag from 'murica to be able buy expensive legimate tools like genuine programmers and etc, so the price of tools is really important for me
>>912366
I know you've already declared PIC to be obsolete, which is incorrect, but i'm not trying to change your mind on that it is up to you afterall.
However, you can get a 40pin PIC USB programmer from ebay for around 5-10 dollarydoos and the microcontrollers cost cents.
yeah one of the good sides of pic as far as i can see is low price. if looking at aliexpress or ebay
>>912364
> IDE for Linux
Use a text editor or an ordinary C/C++ IDE...
Then, for compiling use avr-gcc instead of just gcc:
avr-gcc main.cpp -o main.elf
to extract ihex file (format ready to be flashed on the uC):
avr-objcopy -O ihex -R .eeprom main.elf main.hex
for programming, that depends on your programmer. avrdude is not that complex ;-)
> But assambler is most difficult language to learn, advantage just efficiency?
AVR asm is quite easy, but if your program gets bigger, then you won't grasp it.
>>912366
> genuine programmers
Most ARMs don't require a programmer at all. You just need a USB to 3.3V serial converter (or a serial port and voltage level converter). Less than 2$ on aliexpress.
AVR's can be programmed with parallel port or you can make your own programmer: http://www.fischl.de/usbasp/
Take a look at LUFA also.
One more time thank you guys for information, it helped me a lot.
So i decided to use avr-c with atmel studio.
I m gonna use arduino platform (included power supply, pins and etc), but write code in C and program it using tiny usbasp. If i succed in avr, then maybe it would be good point to learn assembler or another uC programming, but first i m gonna flash some LEDs, measure voltages and etc :)
Thank you all, i everyone minds and ideas :)
>>912244
I'd pick barebone AVR-GCC for beginners, PIC is the same basicly but in general they have less support. however, it is a good idea to first start in ASM. If you know how to code in ASM, even just the simple stuff, it will greatly improve your C code as well. After that step up to 32bit arm cores, since they are as cheap as RISC cores nowadays but more complicated.
>>912280
Not necessarily, avr's run at 1instruction/clockcycle whilst pics run at 1/4instruction/clockcycle, but they do run at 4 times the frequency thus performance is comparable, basicly the same.
>tfw remembering the good old pic/avr fanboy arguments
>>912283
yes i do think so. AVRs tools are solid IDEs imho. I started on AVR as well.
>>912287
The disadvantage is it is much harder to learn the core itself. RISC cores are simpler to understand and imho therefore a better starting point. When developing real applications m0 cores are clearly better if you do not need 10cent cores.
also >>912362
>>912299
see above, AVR or PIC ASM gives you the best insight in registers, although C is sufficient as well.
I started in C but personally think a start in ASM would've accelerated my learning.
>>912343
dont listen to this idiot
>>912347
dunno if you are still here, but good choice
>>912364
you'd better step over to windows, almost all the good IDEs for this kind of software is on windows
>>912366
AVR programmers are literally a few bucks on ebay
>>912387
please let update us on how you are doing in the future, would be nice to see
>>912397
>RISC cores are simpler to understand and imho therefore a better starting point.
ARM is RISC. Regardless, you should be proficient in C before switching to microcontrollers. There will be enough of a challenge without having to solve all the dumb beginner C mistakes at the same time.
>>912405
you know what i mean, i consider the acorn risc as vastly different from the 'normal' risc cores such as pic and avr.
And there is more beginner information on ASM for avr than cortex m0.
>Regardless, you should be proficient in C before switching to microcontrollers. There will be enough of a challenge without having to solve all the dumb beginner C mistakes at the same time.
I dont think so. I started on microcontrollers and the fact that there is human-device interaction and can actually see what your code does in the real world kept me motivated. Challenge is no problem if you want to learn and are enjoying yourself.
But then again, opinions are opinions, so lets agree to disagree.
>>912414
also forgot to mention, when starting with microcontroller c programming you avoid picking up bad programming habits that would be perfectly viable on a desktop pc due to the speed, but severely impact embedded performance. I have seen some people writing code for microcontrollers that was so absolutely horrific, yet i have not seen the reverse happening.
tldr; embedded also teaches some good programming habits and efficiency you'd otherwise not know/care about.
>>912418
(Small) microcontrollers teach bad habits, like unstructured code, globals everywhere, buffer overruns that just happen to work and so on. And even the best microcontroller environments won't let you inspect the code like eg. Visual Studio or Xcode.
>>912414
PIC is not a RISC by any definition. It's barely an architecture, more like a leaky collection of implementation details. And just a reminder that the term "RISC" originated with machines like the IBM 801, MIPS, SPARC and so on.
If you claim there's no beginner information on ARM assembly then you haven't looked. For anyone looking to get started with Cortex-M, I would recommend buying a copy of "The Definitive Guide to ARM Cortex-M0", or the M3/M4 version, depending on which you're planning on using. For a beginner chip I'd probably go with the STM32F103, it's an old and simple chip that's almost as easy to use as an ATmega, and there's tons of cheap Chinese eBay boards that use it.
>>912261
>purity
how autistic can it get?
>>912261
>PIC
They are old, and outdated. Just get plain AVR's and a cheap 2 dollar ebay usbasp programmer for learning how to program microcontrollers, they are just as pure (or even more pure) as PIC, removed some drawbacks existing in PIC (bank switching crap, having a pipeline so not needing 4 cycles for an instruction, and such). When you think you are able to handle them you can start using about any 32-bit microcontroller you'd wish to. Your choice does depend heavily on how close you want to get to hardware. You can use that faggot's purity level as hardware-level-meter when replacing PIC with AVR, AVR/PIC is closest to hardware, so if you like the software side most you'd go raspberry.
>>912435
>And even the best microcontroller environments won't let you inspect the code like eg. Visual Studio or Xcode.
Except that they do.
Atmel studio is visual studio with a plugin. Also the tools from freescale fully support breakpoints in the code.
>(Small) microcontrollers teach bad habits, like unstructured code, globals everywhere, buffer overruns that just happen to work and so on.
These problems occur with small desktop code as well and is not a microcontroller specific problem, but a small code specific problem, and everyone is bound to make these mistakes at least ones, and learn from them.
>PIC is not a RISC by any definition.
It is, PICs use the reduced instruction set, see https://en.wikipedia.org/wiki/PIC_microcontroller under performance and compiler development for proof.
>If you claim there's no beginner information on ARM assembly then you haven't looked.
First of all i never claimed that, and secondly i said that there is more ASM stuff for beginners on avr in comparison to cortex m0 because it is a relatively speaking newer core.
>>912463
>They are old, and outdated.
Are you really retarded or just pretending to be? Pics are effectively in performance just as modern as the 8bit avrs. There is literally almost no difference except maybe which IDE you prefer and amount/type of information available. Beginners are equally well off on both pic or avr.
>>912653
>Pics are effectively in performance just as modern as the 8bit avrs.
They're not, the clocks go up to 40MHz on a 18f8723, and at 4 cycles per instruction it will be a 10MIPS max, while a similar AVR will do 16 to 20MIPS, also the AVR does have more instructions (immediate XOR for example) which would take a PIC multiple instructions. At last the bigger amount of registers accounts for more to be done before data has to be stored elsewhere which are practically wasted instructions.
>There is literally almost no difference except maybe which IDE you prefer and amount/type of information available
Like those factors are not most important for beginners, don't forget to mention the huge price difference on compatible programmers, in favor of AVR of course.
>Beginners are equally well off on both pic or avr.
Certainly not. PIC's are loved by a handful of old people having experience with PIC's and because of their price they're a better choice for commercial mass production devices, but AVR's are the way to go if you want to do 8 bit as a hobbyist.
>>912675
I just saw a 18F1xk22 for example go up top 64 MHz so there are faster ones than just 40, but still that makes the best PIC as fast as the slowest AVR's, if you take into account the higher instruction count on a AVR.
All of this would be fine and dandy if people actually used the microcontrollers efficiently and to the fullness of its capabilities. But they don't.
So they'll buy the "better" AVR, shit out some barely functioning crippled code and use it to about 15% of its capability so in real-world terms the two are equal.
And here is where you say "No, actually I am a genius and write my instructions 100% efficiently and flawlessly, squeezing every ounce of use out of every controller" and we'll all know you're lying and you can fuck right off.
>>912676
counter example: PIC16F628A
fairly old yet does 20Mips just as the atmega counterparts.
>>912675
The immediate instruction is all well and good but you don't get any choice in destination so it all kind of evens out depending on what you want to do with it
I would say pic programmers are no more expensive, microchip programmers all do debug.
I would be weary of using an atmel micro seeing as the company makes no profit and is ready to go under at a moments notice.
>>912675
>They're not, the clocks go up to 40MHz on a 18f8723, and at 4 cycles per instruction it will be a 10MIPS max, while a similar AVR will do 16 to 20MIPS, also the AVR does have more instructions (immediate XOR for example) which would take a PIC multiple instructions. At last the bigger amount of registers accounts for more to be done before data has to be stored elsewhere which are practically wasted instructions.
They are, you are just cherry picking a random microcontroller see >>912681
>Like those factors are not most important for beginners
I never said one is better than the other, just different. So who cares.
>Like those factors are not most important for beginners, don't forget to mention the huge price difference on compatible programmers, in favor of AVR of course.
Price difference is not huge at all. An official pickit is 10 euros, that is a lot cheaper than the cheapest official AVR programmer, and neither the price of an avr programmer not that of a pic programmer is significant enough to base your choice upon.
>Certainly not. PIC's are loved by a handful of old people having experience with PIC's and because of their price they're a better choice for commercial mass production devices, but AVR's are the way to go if you want to do 8 bit as a hobbyist.
Why dont you google before claiming shit. There are as many good pic tutorials and starter guides as there are for avr. And i'd say lately pic stuff is easier to find because the search results are not cluttered with arduino bullshit.
I started with AVR myself but you shouldnt bullshit about pic. They are the practically the same, period. It doesnt matter at all which you pick, just select one at random. I thought those stupid fanboy wars where finally over but you convinced me otherwise.
>>912681
The datasheet says 20MHz and 4 clocks per instruction, or 5MIPS. Which is a typical speed for older PICs. Where did this 20MIPS come from?
>>912653
>https://en.wikipedia.org/wiki/PIC_microcontroller
That article also says that
>it shares some common features with RISC designs
... instead of saying it's a RISC processor. Microcode isn't exactly RISC-like. Accumulator machines aren't exactly RISC-like. Register-to-memory operations aren't exactly RISC-like. Well, Microchip calls RAM registers, so there's some wiggle room with the last one.
Not that it really matters if it fits to RISC's rather loose definition or not.
>>912385
>You just need a USB to 3.3V serial converter
Would it work if you just added two zener diodes to the D+ and D- lines to keep them under 3v3?
>>912689
>... instead of saying it's a RISC processor. Microcode isn't exactly RISC-like. Accumulator machines aren't exactly RISC-like. Register-to-memory operations aren't exactly RISC-like. Well, Microchip calls RAM registers, so there's some wiggle room with the last one.
You didnt look under performance did you?
>advantages: RISC architecture
and under Compiler development
>The easy to learn RISC instruction set of the PIC assembly language code can ...
and look at the bottom of the wiki page, it is literally listed under RISC-based processor architectures...
>>912679
Writing crippled code on a nice microcontroller is still better than writing crippled code on a crippled microcontroller. I know it's a bad argument but yours is too.
>>912681
They say it's 5 themselves.
https://www.microchip.com/wwwproducts/ProductCompare.aspx?product1=PIC16C622A&product2=PIC16F628A
>>912684
I actually seem to be wrong on the immediate xor which is actually is not supported by the avr's as I can see in the datasheets, but still the amount of instruction do provide a advantage over code density compared to PIC's.
>>912695
You haven't seen a random atmega datasheet have you? The readability of those is another advantage compared to PIC's.
>>912691
No because its not just the voltage it's the protocol. Usb and serial differ on various layers, not just the physical
>>912696
>Writing crippled code on a nice microcontroller is still better than writing crippled code on a crippled microcontroller. I know it's a bad argument but yours is too.
his argument is actually valid, although written a bit oddly.
I think he is trying to say that it doesnt really matter which is faster, because a hobbyist never uses the full potential anyways, so it does not even matter which one is objectively better.
>They say it's 5 themselves.
Yes i noticed myself, my apologies.
Although the above still stands, There are not a lot of avr/pic beginner projects that ever need more than 1 mhz, let alone 5.
>>912697
I think they are both just as readable. And even if they are not, you should learn to read even crappy datasheets because that is one of the most valuable skills to have in microcontroller programming...
>tfw spend a week studying a crappily written datasheet section of the lpc11cxx series to figure out how CAN works and then discovering that even their example code does it wrong.
>>912701
o yeah, and regular pic sleep consumption is sometimes orders of magnitude better than avr consumption.
But really who cares in this nitpicking. When using them professionally one may be better than the other depending on application, but for a hobbyist (especially a beginner) it does not matter two fucks.
>>912701
I think we can agree in generalized way on most points, and let's say if you want datasheet readability at all (which might be really important for a beginner) you should at least start with 8-bitters. The pro's and cons of both major players should have been almost completely discussed above.
>>912692
In other words, the article can't really decide if it should call it RISC or not. And the fact that Microchip calls it RISC just tells that their marketing department thinks it's a good thing. It was (and still is) a buzzword. If you look at their older datasheets, they were less blatant with it and just called it it "RISC-like".
8b PIC architecture is older than the whole RISC concept. It is understandable that the term doesn't really fit. On the other hand, PIC was an attempt to create a simple core with decent performance, so it isn't surprising that the term fits somewhat.
>>912688
>They are, you are just cherry picking a random microcontroller see >>912681
Well you've gone wrong there mate, and if microchip's website would have better sorting options it'd be a lot easier to not cherrypick, I just tried to look up the more expensive ones because you can't sort on maximum instruction count per second in their product list, while on AVR's there are just 3 tiers with 16 and 20 MIPS maximums as most common.
>>912706
may or may not be, in both cases it does not really matter if you are a beginner anyways...
>>912708
>I just tried to look up the more expensive ones because you can't sort on maximum instruction count per second in their product list, while on AVR's there are just 3 tiers with 16 and 20 MIPS maximums as most common.
as if that is relevant to a beginner that picks a microcontroller that is used in a tutorial...
Especially if OP wants to program in assembly I'd recommend AVR because of the more common CPU architecture compared to the crippled Programmable Interrupt Controller (disguised as a microcontroller) architecture.
>>912713
No, i decided to learn C programming because assembly doesnt look so easy, first of all i have to learn how to read datasheets that i could use properly uC. Lets say, i would like use timers instead delay function..... and there are a lot of stuff in datasheet, so only tutorials can help me to choose register that would do the job, but in other case previuos register may be not good? Thats why i am against assembly, because in my opinion assembly is way to hard to learn than C when i dont have programming experience :/
>>912717
fair point. Good luck in your endeavours.
>>912722
Thank you
>>912717
>in my opinion assembly is way to hard to learn
My experience has been that it's rather easy to learn enough asm to write something useful. Difficulty is in writing good, readable, maintainable code in a way that isn't overly slow and tedious to write.
That said... yeah, stick to C. If you want to tinker with asm, pretty much all C compilers have support for inline asm.
>>912653
>Atmel studio is visual studio with a plugin. Also the tools from freescale fully support breakpoints in the code.
Breakpoints are the bare minimum for anything calling itself a debugger. But on microcontrollers you don't get profiling, tracing (except hobbled software hacks, or on high-end parts with very expensive tools), reversible debugging, or the option to freely inspect and modify every aspect of the running system.
>wikipedia
>proof
Get real.
>Pics are effectively in performance just as modern as the 8bit avrs.
Nothing with bank switching has any place in 2015.
>>912761
>But on microcontrollers you don't get profiling, tracing (except hobbled software hacks, or on high-end parts with very expensive tools), reversible debugging, or the option to freely inspect and modify every aspect of the running system.
implying beginners need that to learn coding
>Get real.
More proof than you have managed to produce kiddo.
>Nothing with bank switching has any place in 2015.
Nice proof and well supported by facts and numbers.
Except when talking about beginners learning the basics of a language. You continuosly seem to forget that this is not a discussion about a high end system needing to squeeze every last bit of performance out of the chip. This is a beginners starting point and they have effectively the same performance for them especially.
>>912706
PICs predates RISC by so much they have no relation. As someone mentioned above, it's an accumulator architecture, more similar to eg. the 6502.
One real nasty thing about PICs is that Microchip is shit at actually making chips. All PICs have pretty nasty errata, which need careful study before designing anything with one in them. The proprietary programming/debugging interfaces are also shitty (Atmel's debugWIRE protocol is also proprietary, but at least you can program them easily. ARM is completely open.)
>>912765
Sour grapes, moving goalposts and strawmen. And you're unironically calling other people fanboys.
>>912767
>The proprietary programming/debugging interfaces are also shitty (Atmel's debugWIRE protocol is also proprietary, but at least you can program them easily. ARM is completely open.)
doesnt really matter for beginners
>>912769
Funny that you bring all this up as if it is an argument with right and wrong, and not a discussion without a conclusion. It was never my objective to convince other people, merely to show the difference (or lack thereof) between microcontrollers for beginners. You seem to think differently.
>Sour grapes
where? Because that does not apply anywhere within the context of this argument
>moving goalposts and strawmen
I am not moving goalposts, i am returning them to their original position, namely that it should all be applied within the context of a beginner learning programming. Also, i jumped in somewhere in the middle of the argument, and i think you are mixing two people up.
Also, attacking someone on the arguments he uses is actually irrelevant goalpost shifting and not a positive contribution to the discussion. But alas.
And i am not making up strawman arguments, the same thing is still discussed, so nice try with your buzzwords.
And if i go by your buzzwords, this would be called a fallacy fallacy.
>And you're unironically calling other people fanboys.
This has nothing to do with fanboys or whatever, i personally do not even use pics, on the contrary, i use AVRs, i can even make a picture if you desire showing a few dozen AVRs to proof it. But PICs are put in unfair daylight here, even though they are practically equivalent to avr for beginners using C.
And all of this is irrelevant to the discussion at hand, a discussion which has already been waged thousands of times on the internet and which already reached a conclusion here, see >>912717
>>912387
Can we stop bumping this thread now?
Sorry for disturbance, but can somebody give their best stuff to read about AVR-C? Best what i could found is:
http://i.imgur.com/3Y08eFg.png (most important parts) and MAKE AVR programming?
ofcourse there are lot forums, but i would liek to have some solid book (PDF/epub)
>>912825
i really like this site: http://extremeelectronics.co.in/category/avr-tutorials/
although a bit disorganized, just go through them in chronological order
>>912825
http://www.avrfreaks.net/
>>912798
What?
