EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: FenderBender on August 26, 2012, 03:36:08 am
-
I'm an Arduino boy who wishes he could play in the big leagues. I've downloaded AVR Studio. I'm used to the Visual Studio look and I like it. People don't seem to like it because it's not cross-platform, which is understandable. But with the majority of professional workstations being Windows these days, I could see where they were coming from.
I've been cycling through various microcontrollers and platforms. While I'm comfortable in Arduino, I kind of want to branch out. I briefly considered MSP430. Good micro, but I feel like it would be a big leap for me. I'm still a novice. PIC was on my radar but I think AVR is more powerful in the long run. So I've tentatively decided on getting a AVR Dragon and maybe a cute little development board for it. I don't know.
But people see not to like the AVR Studio environment. Is there something I'm missing? Seems okay to me.
Thanks.
-
If you do like a tool that others don't get on with, that's OK. If you were doing it for a living, it could even be called a competitive advantage!
I tend to use PIC for several reasons, but primarily because the Microchip product selector is excellent:
http://www.microchip.com/productselector/MCUProductSelector.html (http://www.microchip.com/productselector/MCUProductSelector.html)
I've not come across a similar tool for AVR, or MSP430, or any other microcontroller range come to think of it. I do this stuff commercially, so it's important for me to be able to choose the most cost-effective part for a given project rather than just one that'll do the job. That may not be something you need to worry about, of course.
The same tool works for all the 8, 16 and 32 bit PICs, and the learning curve for the 32 bit chips really isn't that bad if you already know the 8 bit ones. There's a good book:
http://www.amazon.co.uk/Programming-32-bit-Microcontrollers-Exploring-Technology/dp/0750687096/ref=sr_1_1?ie=UTF8&qid=1345968317&sr=8-1 (http://www.amazon.co.uk/Programming-32-bit-Microcontrollers-Exploring-Technology/dp/0750687096/ref=sr_1_1?ie=UTF8&qid=1345968317&sr=8-1)
The new PIC development environment is MPLAB X, which I personally don't like nearly as much as the old MPLAB 8. I've found it quite slow and buggy, and clearly a work-in-progress that's not yet really ready for service - but it's under constant development and should certainly become quite a good tool once it's refined enough.
-
Anyway - forget the Dragon, get some JTAG Ice MkII clone. I've got both, going to sell Dragon - don't use it at all.
-
Will an MKII clone support DebugWire?
Alexander.
-
Anyway - forget the Dragon, get some JTAG Ice MkII clone. I've got both, going to sell Dragon - don't use it at all.
For what reason do you not like it? Can it not just function as a programmer if you want. I was looking at the Cpuzone ICE MKII. I don't know. Even though Dragon has got a bad rap in the past, are you really comfortable using a non-Atmel programmer?
-
If you do like a tool that others don't get on with, that's OK. If you were doing it for a living, it could even be called a competitive advantage!
I tend to use PIC for several reasons, but primarily because the Microchip product selector is excellent:
http://www.microchip.com/productselector/MCUProductSelector.html (http://www.microchip.com/productselector/MCUProductSelector.html)
I've not come across a similar tool for AVR, or MSP430, or any other microcontroller range come to think of it. I do this stuff commercially, so it's important for me to be able to choose the most cost-effective part for a given project rather than just one that'll do the job. That may not be something you need to worry about, of course.
The same tool works for all the 8, 16 and 32 bit PICs, and the learning curve for the 32 bit chips really isn't that bad if you already know the 8 bit ones. There's a good book:
http://www.amazon.co.uk/Programming-32-bit-Microcontrollers-Exploring-Technology/dp/0750687096/ref=sr_1_1?ie=UTF8&qid=1345968317&sr=8-1 (http://www.amazon.co.uk/Programming-32-bit-Microcontrollers-Exploring-Technology/dp/0750687096/ref=sr_1_1?ie=UTF8&qid=1345968317&sr=8-1)
The new PIC development environment is MPLAB X, which I personally don't like nearly as much as the old MPLAB 8. I've found it quite slow and buggy, and clearly a work-in-progress that's not yet really ready for service - but it's under constant development and should certainly become quite a good tool once it's refined enough.
Thank you. It's all a bit of a challenge for me.
-
Anyway - forget the Dragon, get some JTAG Ice MkII clone. I've got both, going to sell Dragon - don't use it at all.
But that's like saying to a basic car user, forget the VW get an Audi.
I'd prob. also sell my VW if i also had the Audi.
But that doesn't mean that the VW wouldn't be good enough for basic transportation.
The JTAG Ice MkII , can do everything a Dragon can , plus a bit more (some PDI/TPI).
It is is faster and better protected , but it's also 4 times the price. (If speaking about Original Atmel devices).
I'd still recommend a Dragon , to a new Atmel user.
1: It's 4 times cheaper (than an original MKII-ICE), and can do what the OP wants.
2: It has good support (users at avrfreaks.net)
3: It comes with a warranty , if bought through a local dealer
4: There is "Official" software support
5: It can do HV programming (if ever needed)
@OP remember that you can reuse all your Arduino hw. (boards etc) , when switching to AvrStudio (I suppose you will program in C).
Under the hood Arduino also uses avr-gcc and avr-libc.
So basically you are just switching away from all the "layers" that the arduino-libs add to the plain avr-gcc/avr-libc environment.
If you want to try AvrStudio out wo. a programmer , you could use AvrStudio to generate the code.
Anf then ... just as arduino does.
Use avrdude to program the AvrStudio generated hexfile into the arduino board you allready have.
/Bingo
-
I can highly recommend PIC and MPLABX if you want to go that way. The popular misconception that Arduino is faster than PIC is because the original PIC16 series took at least 4 cycles per instruction while the Arduino platforms only took 1. Nowadays, you can get dsPICs and PIC32s that will easily outpace any Arduino.
-
Will an MKII clone support DebugWire?
Alexander.
Mine does support DebugWire.
-
Oooo nice they make a good dozen Pic32s in DIP. That's interesting to know.
Now one question I have about Pic is the compiler. I'd like to program in C but it is my understanding I have to pay for a compiler?
-
For what reason do you not like it?
Basically, because it's a piece of shit - both as a programmer and as a debugger.
As a programmer in ISP mode it's OK. There's no cable supplied, so you have to make it - but that's fine. What's worse, there are two drivers for Dragon - officialy one that works with AVR Studio and generic that works with avrdude. So you have to choose, if you are going to program one way or the other. If you change your mind - good luck removing old driver from your registry.
As a programmer in HVPP - typically you will have to manually wire a couple dozens of contacts. Every time. No modules for specific uC, nothing. Just a universal programmer (I use TOP3100) will be much more convenient. And you only need HVPP if you messed with fuses and failed miserably. Kind of a rare occasion.
As a debugger... It's a nightmare. You are lucky if you got it going with your AVR Studio. There are numerous threads on avrfreaks about this. Finally, I got mine working after unchecking some obscure checkbox deep inside AVR Studio Tools menus.
Then, each time you upgrade your AVR Studio, you will have to upgrade (or downgrade) Dragon's firmware. Once I had two projects, one for AVR Studio 4 and another for AVR Studio 5. And each time after switching from one project to another I had to download and install firmware. Sounds like a poor design for me.
It doesn't support modern uC. I.e. it does support JTAG for atmega64, but does not support atmega644.
Then I got mkII clone. No problems since then. Works like a charm. 100% compatible with original (yes, it even supports online firmware upgrade if you wish).
If someone is going to buy AVR Dragon - I am going to put mine on ebay. Waste of money.
-
It is is faster and better protected , but it's also 4 times the price. (If speaking about Original Atmel devices).
I don't care if it's original if it works fine. Got mine for $129.99, including shipping - Dragon cost about $70. Not a big difference.
-
Well that's interesting. I heard it was a bit flaky anyhow.
I downloaded MPLAB X just now. I dunno. I like the feel of AVR Studio better. But I haven't done anything in either yet so not a fair judgement.
-
Oooo nice they make a good dozen Pic32s in DIP. That's interesting to know.
Now one question I have about Pic is the compiler. I'd like to program in C but it is my understanding I have to pay for a compiler?
For PIC32 you should use Mplab XC32, it's a GCC C/C++ based compiler and exist a Free license for it but limits the amount of optimizations.
-
By all accounts it's not much of a limit, though. I use the free PIC compilers and can't say I even noticed when my eval period ran out for the optimisations.
-
In terms of development tools, Microchip owns Atmel's ass bigtime (with no lube ???). Atmel's tools are cumbersome, they cost ALOT and provide little functionality (btw. IMO whole design where you can brick your micro with one click and need special hvpp programmer to undo that is broken to begin with). On the other hand you can get GENUINE PicKit 2 or 3 for under $50 which servers as programmer, debugger, simple logic probe and uart to usb converter. And for PicKit 2 they have released source code once they moved on to PicKit 3. On top of that microchip does provide samples if you don't abuse the service, Atmel doesn't give a damn.
Atmel's 8 bit AVR architecture is better than PIC16/PIC18, but again - you cannot really compare Atmel's MCUs to something like dsPIC33, because they're like century apart. I've started from Atmel micros, but then moved to PIC24H/dsPIC33 and MSP430 when Atmega 8 used to cost like $4 in retail (now learning to use Cortex M0's from NXP, and LPC1111 costs like $2 in single qty) and I'll probably never go back to Atmel.
-
Ugh. I Want to find a good platform and settle on it/try to learn it. Of course there are problems with that as you have all said. Atmel's low end range is > Microchips low end range, but Microchips mid/high range > Atmel's. But then there's ARM. And Pic32! And oh boy it's a mess.
I want to learn Pic because seems to have better acceptance in the real world.
But MPLAB X just confuses the hell out of me. BUT, Microchip's guides and documentation are 10x better than Atmel's. So if I wanted to learn "real" microcontrollers, I think Pic would be the best way to go.
But coming from Arduino, all this set-up code and even things like timers and interrupts are new to me!
Now what...
-
I want to learn Pic because seems to have better acceptance in the real world.
Oh really?.. =) Think twice.
-
If you want to learn something that is widely used, go for ARM. It's probably the most widely used core EVER. U can't go wrong with that.
On the other hand low range PICs are used for two reasons: simplicity and long term support. For one unlike Atmel, Microchip has thousands of different models with different peripherals etc, so you can choose simplest one that fits your application and thus decrease cost and increase reliability. I know that low range PICs are used in automotive as safety management controllers (lie a more advanced external watchdog) because of their simplicity.
Microchip is also known for providing support for a very long time, and even if some product is withdrawn, they usually propose some newer design which is designed to be - among other things - 100% backwards compatible with the withdrawn model.
PIC32s are nice, they pack a LOT of power but are far less common than ARM solutions. They are basically MIPS4k core with PIC24H peripherals.
-
But MPLAB X just confuses the hell out of me.
As far as I can tell, ALL of the major Microcontroller IDEs (MPLAB-X (based on Netbeans), Atmel Studio (New version based on Visual Studio), TI's CCS (based on Eclipse), and assorted ARM IDEs (mostly based on Eclipse)) are confusing piles of feature-itis, with substantial annoyances and numerous bugs. Confusing and hard-to-get-started is "typical." You just have to bite the bullet and jump in anyway. (the 2nd one will be easier! And it'll be somewhat easier if you've programmed for desktops using some common IDE.)
There are two alternatives that I can think of:
1) Arduino and similar (now available for AVR, PIC32, and MSP430, more or less.)
Simplistic to the point of being frustratingly lacking in common features. No debugging capability. You've read the flames; they're all mostly true. This is designed for non-technical types (Artists!); you are unlikely to find an experienced developer who actually "likes" the IDE. But a beginner can be up and running in minutes.
2) Your favorite editor, a command line shell, and a bunch of command-line tools (preferably starting with someone else's working makefiles and batch files or shell scripts.) (WINAVR is a good example.) If you've done this sort of thing before, you might like it OK. If you haven't, you'll probably think it's 80s era retro computing (and correctly so!)
-
Yeah the learning curve on modern IDEs is pretty steep in my opinion. Maybe if I was a professional and I had to learn PIC or AVR, I would do it, but since I'm a hobbyist, just getting myself to sit down and learn the little quirks and peevs of MPLAB or AVR Studio isn't worth my time. Likewise as you've said, you loose a lot of functionality and control when you switch over to an Arduino-esque editor. They have lots of libraries to cover your ass, but as far as actually understanding how a microcontroller works, I'm not so sure they do the best job. Everything is pretty hidden. However, a good thing about Arduino is that you CAN ditch almost the entire Arduino thing...like the bootloader, or the libraries if you don't want them.
I saw this interesting thing the other day called Arduino for Visual Studio. I'm not sure if it can do debugging, but it looks like an interesting hybrid between Arduino and an IDE.
-
as far as actually understanding how a microcontroller works
No IDE is going to help you much with that, IMO. And you can ignore simplified libraries (like arduino's) and write real code, or just import pre-prepared stuff and libraries (Most microcontroller vendors are now providing extensive libraries) regardless of the IDE.
Now, an IDE (and particularly a simulator) that *is* aimed at understanding the microcontroller is an interesting idea. It shouldn't be impossible; but the market is probably a bit limited. It would have to be someone's labor of love, and people would only like it for that first microcontroller experience. It would probably be annoying to use "in real life"...
-
Isn't it ironic. Novices are confused and intimidated by config registers and interrupts, and one of the worse things about coding for pics is the lack of interrupts.
-
one of the worse things about coding for pics is the lack of interrupts.
Most of the PICs have interrupts (all but those with 12-bit instruction words, IIRC.) What the basic PICs lack is vectored interrupts (ie a different ISR for each interrupt source._
PIC18 has two vectors.
The 16bit and 32bit PICs (PIC24, PIC30, PIC33, PIC32) have fully modern interrupt controllers with more vectors than you can shake a stick at...
-
Actually for simple interrupt usage I think non-vectored interrupt system is better. You can very easily and intuitively set up desired interrupt priorities using basic C constructs and not bothering about setting the hardware interrupt controller (man, hate to setup the NVIC in ARMs)
-
Yeah the learning curve on modern IDEs is pretty steep in my opinion. Maybe if I was a professional and I had to learn PIC or AVR, I would do it, but since I'm a hobbyist, just getting myself to sit down and learn the little quirks and peevs of MPLAB or AVR Studio isn't worth my time.
You don't need too much time to learn all this. It is not so complicated as it seems.
It is worth to learn a single IDE and single architecture, to be able then to hop to any other platform or modern IDE in no time. It's like you learn how to drive a single car model, and then can easily adapt to any other car.
If you worked with arduino before, why not learn the same hardware? Take Atmel Studio, some AVR microcontrollers, and nail down this .... .
AVR micros is as good as any other micros out there for your purposes.
Many people have said it before - it doesn't matter which architecture you start from. The workflow is pretty much the same everywhere.
- Create project in an IDE
- Setup MCU peripherals
- Write your code
- Debug your program
All modern IDEs are all pretty much the same - only some minor things change. Learn how to use a single IDE - and you'll be able to use them all.
Learn how to use a single architecture - and you can adapt to any other in no time.
And it's better to work your way up starting from 8-bit micros. IMHO starting to work with ARM cores would be too much to wrap your head around. And also with ARM you'll be limited to small pitch packages and 3.3 and lower voltage systems. ARM-based micros are great, but if you try to start from there - it would be like trying to learn calculus, before you even know a basic algebra.
man, hate to setup the NVIC in ARMs
I see I'm not the only one :)
Too much flexibility sometimes is a bad thing.
-
Actually small pitch is a relative term. Anyone who has a bit of manual skills can solder 0.5mmQFP or SOP with little problem, and anything with larger pitch is just plain easy.
3.3V is also worth using, since most of the new goodies like tft displays, cellphone lcds, gps & gsm modules a a lot of special logic work on 3v3 rather than 5v. And for 5V you always have level transpators, open drain/collertors and such (btw - most of 3.3 MCUs have an option to setup I/O pin as open collector and switch higher voltages)
But other stuff is true, 8-bit micros are the way to start. I actually started with Atmel, but I feel that I'd be better off starting with PIC. It's because Atmels are almost all the same, and Microship portfolio is like an order of magnitude bigger than Atmels. plus of course you get much better learning and development support and tools for much lower price than Atmel.
-
Actually small pitch is a relative term. Anyone who has a bit of manual skills can solder 0.5mmQFP or SOP with little problem, and anything with larger pitch is just plain easy.
The soldering itself never was a problem. He is a hobbyist and he might want to do fast some prototypes at home without using breakout boards. Also ARM-based MCUs don't come in a small packages. What if you need only a couple of pins? It all depends on his current needs.
3.3V is also worth using, since most of the new goodies like tft displays, cellphone lcds, gps & gsm modules a a lot of special logic work on 3v3 rather than 5v. And for 5V you always have level transpators, open drain/collertors and such (btw - most of 3.3 MCUs have an option to setup I/O pin as open collector and switch higher voltages)
I would partially agree on this one. Yes, nowdays almost all the digital peripherals is 3V3 or even lower. But if you have some analog circuitry (like op-amps, voltage references, etc.) on a board alongside with MCU, you might want to have 5V instead of 3V3, to avoid putting another regulator. Sometimes it is better to keep it simple. I'm all for using right tools for the right job.
-
Ugh. I Want to find a good platform and settle on it/try to learn it.
How about Aery32, http://www.aery32.com (http://www.aery32.com)? It's a project based on Atmel's UC3A1 (32-bit AVR), which I'm involved to. There's a small breakout board to buy and an open source peripheral library with the build system. The library has been built in away that you can use only the parts you like. The library and the build system doesn't care about the development environment. Use it with IDEs (Atmel Studio, Eclipse, etc.) or in text editor, e.g. Sublime Text 2, which is my personal favourite. Furthermore, the build system has been separated from the library so you can take an advance of the build system only and skip the whole library if you like to write all the stuff yourself. It's also "easy" to add other libraries to project, for example, LUFA (USB framework) has been integrated successfully. In conclusion with Aery32 platform you are "in big leagues" but also up in the speed in couple of hours and can then learn more by reading the MCU's datasheet.
Regarding the AVR Dragon, I have been very happy with that and cannot underwrite its bad reputation.
-
Very interesting. I don't think I'd do 32 bit right off the bat, but possibly down the line a bit. Downloaded Atmel Studio 6.0 yesterday. For all the hate, I like the look and feel though I still feel there's too much in your face up front.
Well I've seen some good and some bad about Dragon. I think I'll take the risk and go for it + Atmel Studio. If it's terrible I'll try something else but it seems like a fair shot.
-
I don't think I'd do 32 bit right off the bat, but possibly down the line a bit.
In my opinion, there's no educational benefits to start with 8bits, if you are in intention to switch in future anyway.
Downloaded Atmel Studio 6.0 yesterday. For all the hate, I like the look and feel though I still feel there's too much in your face up front.
AS6's build system is known to be very slow, 1-2 minutes to build even a small project. With my coding habits, that's making small changes iteratively and then testing on hw, AS6 is just too slow. Thus I do not use it for coding. However, I cannot say that I hate AS6. It has a neat debugging environment that I use every now and then when LED driven debugging is not enough.
-
AS6's build system is known to be very slow, 1-2 minutes to build even a small project. With my coding habits, that's making small changes iteratively and then testing on hw, AS6 is just too slow. Thus I do not use it for coding. However, I cannot say that I hate AS6. It has a neat debugging environment that I use every now and then when LED driven debugging is not enough.
Not universally true (maybe your settings, makefile or something is off?). I just tried, and made a small change to one file in my project. That compiled and linked in 6 seconds on my 2.4GHz Core2. The project is not very small, the binary is 116k. Changing three files raises the compile time to a whopping 8 seconds. Download to target with JTAG ICE 3 is not slow at all either.
-
Not universally true (maybe your settings, makefile or something is off?).
Maybe it's more ASF related. For me an ASF-based project that only sends 'a' via USB CDC class tooks about a minute to build on Core i5. Also with a change to main only. In addition, I have had a theory that clean builds takes time because there so much -Ifoo/bar passed to the compiler.
Update: Rechecking, I had AS5 installed so haven't tested this with AS6.
-
In my opinion, there's no educational benefits to start with 8bits, if you are in intention to switch in future anyway.
There is a big educational point in using 8-bit micros! Because they're order of magnitude simpler than ARM-based ones. To write efficient and bug-free(almost) software for any MCU architecture, one must understand its innards very well. And if you start with ARM right off the bat - you'll learn pretty much nothing about how microcontrollers really work.
On top of that there are many designs where you need to use small micro with a couple of IO pins, and it might be on the same board with ARM, doing its separate functions.
AS6's build system is known to be very slow, 1-2 minutes to build even a small project. With my coding habits, that's making small changes iteratively and then testing on hw, AS6 is just too slow. Thus I do not use it for coding. However, I cannot say that I hate AS6. It has a neat debugging environment that I use every now and then when LED driven debugging is not enough.
It seems that you don't know what you're talking about (no offense, but it's true). AS6 using AVR-GCC toolchain, and so compile time would be pretty much the same as with other IDEs or by using WinAVR.
-
In my opinion, there's no educational benefits to start with 8bits, if you are in intention to switch in future anyway.
There is a big educational point in using 8-bit micros! Because they're order of magnitude simpler than ARM-based ones. To write efficient and bug-free(almost) software for any MCU architecture, one must understand its innards very well. And if you start with ARM right off the bat - you'll learn pretty much nothing about how microcontrollers really work.
On top of that there are many designs where you need to use small micro with a couple of IO pins, and it might be on the same board with ARM, doing its separate functions.
+1 to that. In a complicated MCU - and 32-bit ones are always feature-packed - you have many dependancies (eg. you have to switch this bit in UART registers in order for I2C to work, but themn pin #5-7 can't be used as ADC....). In a simple 8-bit attiny or atmega of even the nasty pic16 there are only a few things to care about.
Maybe a good example of non-8-bit and quite simple MCUs are low range MSP430s (plus documentation is user-friendly)
-
It seems that you don't know what you're talking about (no offense, but it's true). AS6 using AVR-GCC toolchain, and so compile time would be pretty much the same as with other IDEs or by using WinAVR.
No offense taken. However, I'm not the only one who have noticed the slow builds, link (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=124437&start=0&postdays=0&postorder=asc&highlight=). But yeah I do not have as much experience with AS to make such a conclusion I made. And as I said afterwards it could be more ASF related than AS. But for me it has been slow, whatever is the reason. Maybe a stupid user error ;)
-
So I don't get this ASF thing. Is it like a bunch of libraries or something? And do you have to use it? Or...I looked at the getting started guide. Don't exactly understand what it's purpose is.
Thanks.
-
Excuse me for jumping in at the end of this thread, I didn't look at it before now.
One thing strikes me though--as a learner or student, one should consider what it is you are trying to learn. I say this in response to various comments and advice given above.
What I mean is, are you trying to learn hardware or software? If you are trying to learn hardware (real-time computing, interacting with analog or digital inputs or outputs, controlling peripherals, understanding registers, interrupts, CPU architecture and so on) then there is no point starting with the latest and greatest 32 bit micro. You could readily begin with 8 bit devices and (horror!) even learn to program it in assembly language. After all, if you want to learn about hardware, the machine instructions are where you see how the hardware works. That's where the rubber meets the road. If you don't have a good feel for the hardware, a C compiler on a microcontroller is going to be like a layer of fog between you and and the business end of the system.
On the other hand, if you want to learn software and programming and use IDEs like AS6, then do you really need to mess with micros? Why not work with a programming environment on a PC and take advantage of all the support for comfortable programming in that environment? Your home PC has a very nice 32 bit or 64 bit processor inside it, and any program you write can readily run on that processor and do fun stuff right away. On your PC, your C++ (or C#) compiler is no longer a layer of fog but is now a wonderful abstraction layer that hides the intricacies of the machine and allows you to concentrate on what your program needs to accomplish.
It all comes down to what you are doing. If you are an engineer doing professional design and production, then you have to pick and use the hardware and programming environment that does what you need. But if you are learning, you have no such constraints. You should pick and use the hardware and programming environment that best suits your learning objectives.
-
It seems that you don't know what you're talking about (no offense, but it's true). AS6 using AVR-GCC toolchain, and so compile time would be pretty much the same as with other IDEs or by using WinAVR.
No offense taken. However, I'm not the only one who have noticed the slow builds, link (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=124437&start=0&postdays=0&postorder=asc&highlight=). But yeah I do not have as much experience with AS to make such a conclusion I made. And as I said afterwards it could be more ASF related than AS. But for me it has been slow, whatever is the reason. Maybe a stupid user error ;)
Would be good to know what's taking all that time. Is it disk I/O or processor usage? I've never used it before but it's rather hard to justify how compiling code for an 8-bit micro could take so long on a system that's orders of magnitude more powerful.
-
So I don't get this ASF thing. Is it like a bunch of libraries or something?
Atmel Software Framework. Yes, it's a library and a bunch of other stuff like demo programs and integrations to third party libraries (e.g. freeRTOS) etc. Thus it's called a Framework I think.
And do you have to use it?
No. You can use AS without using ASF. Just start a GCC Excelutable project, include I/O header file to your source file (avr/io.h for 8bits and avr32/io.h for 32bits) and start bit banging the registers.
Don't exactly understand what it's purpose is.
The main purpose is to provide functions that you can use for the internal peripherals. These functions hides the bit banging.
-
It seems that you don't know what you're talking about (no offense, but it's true). AS6 using AVR-GCC toolchain, and so compile time would be pretty much the same as with other IDEs or by using WinAVR.
No offense taken. However, I'm not the only one who have noticed the slow builds, link (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=124437&start=0&postdays=0&postorder=asc&highlight=). But yeah I do not have as much experience with AS to make such a conclusion I made. And as I said afterwards it could be more ASF related than AS. But for me it has been slow, whatever is the reason. Maybe a stupid user error ;)
Would be good to know what's taking all that time. Is it disk I/O or processor usage? I've never used it before but it's rather hard to justify how compiling code for an 8-bit micro could take so long on a system that's orders of magnitude more powerful.
Yeah, sorry for the brain fart :-[. Atm. I'm using 32-bit micros (AVR32), but that shouldn't make a difference. Using standalone tools in command line the compilation process is much faster than within AS. And moreover, for me the standalone AVR32 toolchain is even more efficient in Linux (virtual on Windows) than in Windows.
-
Just thought I'd chime in, I teach this stuff to young EEs at uni.
AVR Studio is more than enough to do some serious projects. Sure, it can be a little complicated but I quite like it. AVR Studio 6 is pretty nice compared to the old one as well. Just get an AVRISP ($34 direct from Atmel last time I checked) or some clone (bus pirate does it too, and you get a really useful tool at the same time) and program your arduino board directly. Although I don't really like the Arduino software environment out of personal preference (I still think its awesome), the boards are perfect for mucking around. STK500 is dead, I haven't used it for a long, long time.
As someone who loves using ARM chips, don't worry about them so much as it took me only a day of fiddling to transfer most of my skills from AVR over. No point putting an V12 in a go-cart ;)
Good luck!
-
No point putting an V12 in a go-cart ;)
You've clearly never driven a Westfield SEiGHT, then... a 3.9 V8 in a car that weighs about as much as a packet of crisps. Much fun! ;D
-
Sadly, I think that AVR, PIC16 and PIC18 will be turning into a curiosity or training subjects only. Even now you can buy for example LPC1111 for around the same price as ATMega8. Even if people won;t use any of the advanced features, it simply cheaper. And the price is what drives the industry. Even now there's hardly any commercial product (apart from won-hung-lo crap from the east) where you can find an AVR. Most of the things have some flavour of ARM chip inside (aither as off-the-shelf MCU or some custom/semicustom IC)