how to choose a PIC? - Page 1
Forum section: electronics / general

author: Kidsam
author_rank: Contributor
timestamp: October 13, 2012, 01:53:02 am
content: greetingsi'm trying to figure out how to choose a pic, for a couple of future projects of mine, though im not sure how, as i'm pretty new to themthe things i'm looking for on one chip are:13 or more outputsPWM capabilitiesand the project i want to use it for is a LED array cube, with some animations programmed inthis one may wait untill im more experienced, but i will probably make smaller cubes in the meantime, i figure i need 4 outputs, 4 for each length segment, 4 for height, and 4 for width, and one for PWM , though i could cut it down to needing 9 pins, though it would require using alot more external componentsanother project is for a small solar powered robot(beambot)and i hope to use a PIC chip on itwould need 2-6 outputs and low power needs (it would switch on+off alot as power is avaliable)i've been usinghttp://australia.rs-online.comto look at parts, and i can look up chips for example with 20 pins and PWM capable that look like they would suit my LED projects, however i can find "suitable" chips for $1.20 and chips that appear just as suitable for $8 or sofor examplehttp://australia.rs-online.com/web/p/microcontrollers/7432647/$1.87vshttp://australia.rs-online.com/web/p/microcontrollers/6669848/$6.50, same amount of pinsso what specifications do i need to actually look at when i buy a chip? are those two chips both suitable for the project, or do i need to look for extra memory or something like that

author: Smokey
author_rank: Super Contributor
timestamp: October 13, 2012, 02:30:28 am
content: if you are new to PICs, and plan on using the XC compilers, my advice is to use one of the chips that they use for the official development boards. You don't actually have to use the dev board itself, just the same chip. I say this because all of the sample code from microchip is built for the official dev boards. If you use the same chip then you won't have to do much porting. They usually use good general purpose chips for the dev boards as well.I know that doesn't really answer your question, but its a place to start.

author: TheDirty
author_rank: Frequent Contributor
timestamp: October 13, 2012, 03:46:01 am
content: You can use the product selector tool.http://www.microchip.com/productselector/MCUProductSelector.htmlAfter that, you need to check which chips that fit your criteria are available from your distributor.Usually people pick chips that are generic and have a decent amount of peripherals. It's easier just to grab 20 of those and use them even if they are overkill rather than grab 1 of 10 different uC's that better match the requirements of the individual projects.There are some common starter ones like 16f877A and 16f628A. I would highly suggest starting out with one of the enhanced (updated) cores. The enhanced cores usually come in a LF version as well as a regular F version, the L is for low voltage, which you'll want for a solar project. I have used a few 16f1933's and for low pin count 12f1840.

author: andete
author_rank: Contributor
timestamp: October 13, 2012, 04:26:24 am
content: Quote from: TheDirty on October 13, 2012, 03:46:01 amIs it me or is that selector really slow? It's been calculating for 3 minutes now.

author: mariush
author_rank: Super Contributor
timestamp: October 13, 2012, 04:44:14 am
content: nevermind, things have changed lately and my advice no longer applies that well.

author: Kidsam
author_rank: Contributor
timestamp: October 13, 2012, 05:01:24 am
content: Quote from: Smokey on October 13, 2012, 02:30:28 amwell, i'm not sure about the development boards, i just bought the pickit 3i also have the chipsPIC16F84A-04/P andPIC12C508A which the seller has bundled with the pickit, though from the datasheets they look like faster chips, but without PWM functionalityanyway thanks for the replies

author: Simon
author_rank: Unknown
timestamp: October 13, 2012, 07:08:13 am
content: Don't use the 16F84, it's so old, time to let sleeping dogs lie. I tend to consider the 16F88 for anything needing a few pins although I'm yet to do anything significant.

author: David_AVD
author_rank: Super Contributor
timestamp: October 13, 2012, 09:16:44 am
content: I've started using the PIC16F1827 in some new designs. Quite cheap (< $2) and capable. Also the PIC16F1822 (8-pin) has a UART, SPI, etc and less than $1.

author: ptricks
author_rank: Frequent Contributor
timestamp: October 13, 2012, 01:42:21 pm
content: Any of the pic32mx chips can do what you want and they are fast, low cost, and current technology. The dip versions of these chips would work well.Also, microchip is very friendly when it comes to free samples. Just go to the microchip site and register, they usually allow hobbyist about 5-6 chips a month for free.If I was just starting out with pics then I recommend the pic16f1823. It isn't because that chip is the best of the best, it is because the datasheet for that chip is probably the best, easiest to understand that I have ever seen for a MCU.

author: nctnico
author_rank: Super Contributor
timestamp: October 13, 2012, 03:25:37 pm
content: I agree. I'd stay away from the 8 and 16 bit PICs. That is 80's technology. Go for PIC32 or an ARM based controller. Another advantage of the latter are that the C compilers and debuggers are available free.

author: Simon
author_rank: Unknown
timestamp: October 13, 2012, 03:37:34 pm
content: oh here we go again. Why use a ferrari to go 100 metres down the road ? if the project is simple then why use such powerful devices. You can run C even on 10F micro's. Granted it's not a great idea but if you just want to flash a LED I bet it's work fine. Microchip and most others do C compilers for 10-16F parts as well as the compilers for 18-32F. Of course the issue with anything under 18F seems to be the paged memory but if it's a small program under one page size or you split it appropriately there won't be a problem

author: TheDirty
author_rank: Frequent Contributor
timestamp: October 14, 2012, 12:22:01 am
content: I have not used PIC32, but I've used my share of ARM chips, older ARM7, and now CM3, CM4, and CM0. They do not replace 8/16bit micros for easy low requirement projects. Beginners should still start out on these. The peripherals are easier to understand and less things to go wrong.To be controversial on another topic, I wouldn't even bother with assembler anymore if you are just a hobbyist. Unless you really want to get into low level, there's just no need. I've given up learning assembler for new architectures. I used to learn instruction sets for new architectures I would get into, but I just started using PICs about a year ago and never even bothered learning the instruction set. The last uC I got into was MSP430, I learned the instruction set and outside of the practice programs never ended up using any of it in any actual project.

author: Simon
author_rank: Unknown
timestamp: October 14, 2012, 07:41:08 am
content: I spent years trying to head the advice of assholes on that other forum banging on about the purity of assembler. I nearly gave up until I made a final dash for it and "sinned" with basic, oh it felt so good to be liberated.I'm now trying C

author: andyturk
author_rank: Frequent Contributor
timestamp: October 14, 2012, 01:49:28 pm
content: Quote from: Simon on October 14, 2012, 07:41:08 amC *is* the new assembler. C++ is more useful though, if your compiler supports it.

author: mrflibble
author_rank: Super Contributor
timestamp: October 14, 2012, 05:13:56 pm
content: Quote from: Simon on October 14, 2012, 07:41:08 amYeah, going the asm only route is a bit silly in 2012. My most recent additions to the mcu menagerie are msp430 and stm32f4, and I haven't written a single line of asm for either yet. All the asm exposure I've had on those is reading the startup code to get an idea of what's being done there. Other than that it's C all the way.

author: mrflibble
author_rank: Super Contributor
timestamp: October 14, 2012, 05:16:37 pm
content: Quote from: andyturk on October 14, 2012, 01:49:28 pmOn that subject, anyone have practical experience with C++ on the stm32f4? Right now C does the trick, but for some of the stuff I'm writing now a bit of OO would be nice. And the same C++ question for msp430... any experience anyone?

author: AndyC_772
author_rank: Super Contributor
timestamp: October 14, 2012, 06:16:37 pm
content: Quote from: nctnico on October 13, 2012, 03:25:37 pmThe smaller PICs are perfectly suitable for many purposes and in some cases contain a better peripheral set than the 32 bit parts. The debugger and C compilers are free for all the PICs; all you don't get for free is the code optimising stuff, which by all accounts is of questionable value anyway.

author: andyturk
author_rank: Frequent Contributor
timestamp: October 14, 2012, 07:08:19 pm
content: Quote from: mrflibble on October 14, 2012, 05:16:37 pmI'm using C++ with STM32F1xx, which is essentially the same. My code runs equivalently on the F4 and VL Discovery boards (with mods to the linker script). I thought about using an MSP430 until codespace issues started to crop up.

author: Unknown
author_rank: Unknown
timestamp: October 14, 2012, 07:20:49 pm
content: Quote from: AndyC_772 on October 14, 2012, 06:16:37 pmCode optimization may not be critical if the uC is way overkill in terms of memory size and performance, but pretending that the past ~forty years of compiler development is of questionable value is wrong in my opinion. Compiler optimization is probably the number one reason why programming languages like C have mostly replaced assembly these days. I wouldn't use a non-optimizing compiler for any application if I can help it.

author: nctnico
author_rank: Super Contributor
timestamp: October 14, 2012, 08:44:18 pm
content: Quote from: AndyC_772 on October 14, 2012, 06:16:37 pmWell, you could use a Model-T Ford to go to work every day. It will get you there and back but would it be wise? If you refer to PIC32 parts I guess you are right. IMHO they are Microchip's half assed attempt to hop on the 32 bit boat. Half assed because they choose a MIPS core instead of ARM. Not that MIPS is really bad but the general community support for MIPS is extremely limited because there are very few MIPS based devices out there.And yes, you really want optimisation in a compiler. Sometimes you need to cram a little bit more code into a controller or get a bit more speed from certain parts of the code. In some cases I find myself compiling one C file with optimisation for speed and the rest with optimisation for size. With any ARM controller you get those for free with GCC but for PIC32 you have to pay. How dumb is that if you want to penetrate a very crowded market?

author: Smokey
author_rank: Super Contributor
timestamp: October 14, 2012, 09:06:27 pm
content: If you want another stupid PIC compiler optimization fun fact.....The official microchip USB bootloader example code only fits in the right memory footprint if optimizations are on. After the trial you have to alter the offsets on all your code. Fun huh..I brought this up to the microchip rep during a site visit. Dunno if they can really do anything about it though.(edit to add official microchip compiler)

author: AndyC_772
author_rank: Super Contributor
timestamp: October 15, 2012, 06:25:42 am
content: OK, I get the philosophical argument, though it hasn't stopped me from completing numerous successful projects using PICs with the free tools. Lack of optimisation hasn't caused me any issues at all, and it's certainly not a reason to avoid using a perfectly good range of microcontrollers.Can anyone provide quantitative data on just how effective Microchip's optimisation actually is? (ie. not the manufacturer's claims, but actual project performance and/or code footprint improvements)

author: Kremmen
author_rank: Super Contributor
timestamp: October 15, 2012, 07:21:02 am
content: The weary argument that one can write more efficient code in asm than in C expired long long ago. In some exceptional cases of minutely detailed optimization, maybe. Generally a competent C/C++ compiler can match and exceed the ability of a human to produce code with consistent high quality.My recommendation would be to learn C++ and how to use it to create proper structure to the code. By this i mean things like classifying functionality into object classes that have well defined behavior and that hide their internal variables and only publish an interface. This helps to create cleaner, more understandable and maintainable code and there is no penalty in doing so.The myth that introducing classes into an application will automatically result in bloated code has also been busted long ago. For example i just completed and delivered a series of CNC mill spindle rpm meters/speed monitors powered by a Mega328P - the same Arduino uses. I wrote the code in AVR Studio 5 (and 6) as a C++ project (i.e. using the GCC compiler). There are some 5-6 classes handling eeprom/configuration, encoder input, rpm calculation, display formatting and configuration user interface. Less than half of the available memory spaces were needed, so another similar app would still fit easily. The meter is easily able to count revs up to the max displayable 65535 rpm and beyond (limited only by the fact that the final number is a uint16_t in this version).

author: nctnico
author_rank: Super Contributor
timestamp: October 15, 2012, 10:49:07 am
content: That is a good hint. OTOH you don't need C++ to write object oriented code. In C you can declare variables and functions as static within a source file which means they are not visible to the rest of the program. A few 'public' (non static) functions serve as an API to the rest.

author: Kremmen
author_rank: Super Contributor
timestamp: October 15, 2012, 11:17:51 am
content: Depends on what exactly you mean by "object oriented". Generally speaking, no, you cannot write OO code just using C, but you certainly can emulate some OO features using it. Providing well defined data structures and procedures that operate on those structures is a step towards that. But other features like proper information hiding are harder, and some like inheritance, polymorphism, class templates and other "true" OO features just cannot be done in C. How much of those you want or need in a small microcontroller environment is of course a different question but just for the sake of the argument that is so.Personally, I much prefer to use the proper features of a reasonably well defined standard, such as C++ language, instead of coming up with what may be called neat tricks or in the worst case, kludges. (I don't specifically mean your example. That is a standard scope/visibility feature of C and in my book it does not count towards OO especially. Of course you did not make that claim either).So anyway, whatever floats your boat, it is not for me to dictate. This is just my opinion.

author: andersm
author_rank: Super Contributor
timestamp: October 15, 2012, 11:42:11 am
content: Quote from: Kremmen on October 15, 2012, 11:17:51 amBoth inheritance and polymorphism can be done in C, it just takes a lot more work. After all, most basic C++ features are just compiler automated structures and function pointers. If you program for OS X you run into many examples of object-oriented APIs implemented (at least originally) in C. However I'm not arguing you should do it this way rather than using C++, just that it can be done.

author: Kremmen
author_rank: Super Contributor
timestamp: October 15, 2012, 01:11:47 pm
content: OK, let me rephrase: C does not support OO as part of the language definition. This may be trivially so and that is why we have C++. You are right in that you can code the OO functionality using C and elbow grease but i didn't quite mean that. Been there, done it but really, that way you will miss many of the OO rules enforcing that a proper C++ compiler will do for you. Just an example is managing self-pointers to object instances. Can be done but makes for lots of extra work.I am not familiar with things Mac, but i suspect that we have different levels of OO in mind here.Object-like code is possible in C but why would you want to do it when C++ is available. But then you already said so.

author: ptricks
author_rank: Frequent Contributor
timestamp: October 15, 2012, 05:09:43 pm
content: I would learn C but also learn some basic assembly too. The reason for knowing assembly is that with chips like the pic the compilers are often slow to catch up with new chip models. If you happen to be using one of these new chips and the compiler version doesn't support it yet, you might not be able to use any of that chips new features without knowing some assembly. Often you can do things like setting up chip configuration or ports much easier in assembly than relying on a C macro to do it. I like to mix assembly and C and use primarily C for the programming. It also helps to know assembly when you compile a program and it doesn't work correctly yet nothing appears wrong in the C code. Compilers are far from perfect, especially when it comes to pics

author: ptricks
author_rank: Frequent Contributor
timestamp: October 15, 2012, 05:16:44 pm
content: Quote from: mrflibble on October 14, 2012, 05:13:56 pmThere is nothing wrong with using assembly if you are comfortable using it. Where assembly is wrong is when someone doesn't like using it, gets confused using it . I know some very talented pic programmers that only use assembly. One of them wrote a program that creates a UART , interfaces a 16x4 character LCD , and supports an SD card for data, this all runs on a pic16c505 chip, the chip only has 1K of flash and 72 bytes of ram, no hardware UART so it is bit banged, and he made it all fit. In the right hands assembly is great, but don't use it just for the sake of using it.I tried recreating what he wrote with 3 different compilers, none of them could make it fit.

author: Kremmen
author_rank: Super Contributor
timestamp: October 15, 2012, 06:08:26 pm
content: If one tries to be objective (no pun intended) then the choice of coding level should be dictated by the highest priority at hand. With this in mind it is faulty logic to suggest something like "always use X in environment Y".Usually/often the highest priority is to produce bug free, well maintainable code that has sufficient performance for the task at hand. Then a high(er) level language is indicated.Sometimes, e.g. when implementing library functions where max performance is desired, it _may_ be the correct choice to code near the bare metal.The highest level of expression/language that is adequate to solve the problem should be used. Those who say otherwise should consider the story of Mel.http://www.cs.utah.edu/~elb/folklore/mel.html

author: Unknown
author_rank: Unknown
timestamp: October 15, 2012, 10:00:48 pm
content: Quote from: AndyC_772 on October 15, 2012, 06:25:42 amI'm not aware of any numbers, and they would be of limited value since it will highly depend on the code involved. For example:Code:uint32_t i;for (i=0; i < UINT32_MAX; i++);Might take an hour without optimization, and zero cycles (completely optimized away) with optimization since it does not produce any results. Optimization will also pre-calculate constants at compile time, this explains this result:Quote from: JohanEkdahl

author: ejeffrey
author_rank: Super Contributor
timestamp: October 15, 2012, 10:14:18 pm
content: Quote from: ptricks on October 15, 2012, 05:16:44 pmIf your goal is to have fun, sure. If your goal is to produce code that does the job at hand with a minimum of bugs and minimum development time, then no, assembly is almost never the right choice. People who say things like "I am used to assembly, I can code Bug Free (tm) code just as well and just as fast as in a higher level language" are wrong. Always. They may be very talented individuals, and they may produce good code in assembly, but they always turn out to produce better code in a higher level language. Assembly programs tend to have fewer features and more limitations than programs written in higher level languages because of the difficulty of doing very simple mundane things like dynamic memory allocation. Sometimes this gives the appearance of being more reliable but that is a false comparison. An equally simple program written in a higher level language would have been completed faster and with fewer bugs.Yes, in certain instances it is required. The extremely small memory footprint of the smallest MCUs is one of a few remaining legitimate use cases. Compilers can actually produce fairly compact code, but there is generally a bit more fixed overhead that can be a problem in such small environments. Also, the complexity of the program you can fit is limited anyway, so doing it in assembly is feasible. Likewise there are still a few use cases in high performance computing. Of course accessing hardware specific features like IO and synchronization primitives often requires bits of assembly -- wrapped in higher level functions and eventually added to the platform library.Even in high performance computing, a fundamentally conservative community that has always been skeptical (with good reason) of the promised advances touted by systems programmers, assembly is disappearing. On modern CPUs, maximizing ILP, optimizing cache layout, making best use of SIMD, and targeting special purpose processors like GPUs and FPGAs is just too hard for humans to do when they are stuck counting instructions. Give them a higher level language and the means to express the problem more clearly, and they produce better, faster code. There is still plenty of hand tuning going on, it is just at a higher level.

author: ptricks
author_rank: Frequent Contributor
timestamp: October 15, 2012, 11:16:43 pm
content: Quote from: ejeffrey on October 15, 2012, 10:14:18 pmNot always, you may not be able to produce code as fast or accurate in assembly as you can using C but there are people who can do it and are doing it and those people are paid very well for their work. Unfortunately there is not a lot of people who understand assembly anymore and that creates a shortage of people that can write compilers, drivers and firmware for embedded devices. Things that work on the low level like initializing a processor for the first time when no compiler exist because it is a new design. I asked someone at a large semiconductor company, not allowed to say which one, how many people here really understand the chip well enough to be able to write the compiler or code all the low level stuff ? The reply was 6 people, 2 were over 55 years old, 2 had just started from college, 2 had been on the job for 1 year or more. The company was basically hoping the senior employees could teach the few interns they could get enough to take over but they were not optimistic. That was millions of dollars in product depending on 6 people and only 2 able to write code by themselves. There just isn't enough engineers wanting to know the low level stuff anymore. You can find plenty of graduates that know C or how to plug up a micro to a jtag or use the ide to program the chips, but the ones that know how to create all that stuff so programmers can use it are few.Back on topic, I stand by what I said. Learn C but don't ignore assembly completely, it doesn't hurt to learn it and it does help to better understand why a certain C instruction is taking so long to execute, why the compiler keeps tossing out errors that make no sense, or being able to debug a program down to the core level. Using the microchip ide you will want to understand what all the registers mean and how the values are changing and why.

author: nctnico
author_rank: Super Contributor
timestamp: October 15, 2012, 11:46:17 pm
content: Most of the people (like myself) that know that kind of low level stuff are freelancers nowadays.

author: westfw
author_rank: Super Contributor
timestamp: October 16, 2012, 07:04:40 am
content: Quote1) It's only the 8bit compilers that have awful optimization in the free versions. The 16bit and 32bit compilers are gcc, which has its own optimizations that would be hard to remove.2) the 8bit unoptimized code is awful. The sort of crap that people have used since the dawn of time to bad-mouth compilers, like someone took the three-operand pseudocode that beginning compiler classes tell you to emit, and wrote a naive translation to machine code. (this is being charitable. The uncharitable explanation is that they have introduced deliberate anti-optimizations.)Here are some quotes from the PICList mailing list, circa 2009. (Note that one of the sad things is that Microchip can fix this at any time, but probably no one will trust their free versions again.)Code:Look how they do 'Var = 0;' :bcf STATUS,Cmovlw 0btfsc STATUS,Cmovlw 1movwf Var'Var = 1;'clrf Varbsf STATUS,Crlf Var,f'Var = 2;'clrwiorlw 2movwf Tempmovf Temp,wmovwf VarAnd so on... </quote>

author: AndyC_772
author_rank: Super Contributor
timestamp: October 16, 2012, 07:10:01 am
content: Quote from: ptricks on October 15, 2012, 11:16:43 pmArguably that pretty much sums up the size of the job market for people with that specific skill, though.I very much doubt the company in question has ever advertised a six figure salary for engineers who are capable of programming in assembler and willing to make a career out of it - and I can virtually guarantee that they'd get plenty of good applicants if they did. If the skill is so key to the project's success, and so hard to come by, then it becomes expensive - and that's just the law of supply & demand.I'm a bit surprised there aren't more engineers at least willing to do it, though. If a CPU is brand new then it absolutely has to be learned afresh, of course. By definition, nobody at all has prior experience with it.I did a lot of programming in assembler back in university and beforehand, back when the BBC micro was the machine to have, and programming it in 6502 assembler was the way to get better performance out of it. When the Archimedes came out I learned ARM assembler too, which was a joy to use by comparison.The last assembly language project I did was my final year university project, which was done on an early PIC where it was the only option. It was an absolute pig to do, and using assembler really got in the way of concentrating on the real task at hand which involved reading the inputs from sensors, performing some mathematical operations on the measurements, and then clocking the results out to a display. The chip wasn't particularly constrained by memory or speed, and it's a job which would have been much, much better done in a high level language.Thankfully I've not had to program in assembler since, though I do now regularly write VHDL which uses a lot of the same skills and mindset.

author: mrflibble
author_rank: Super Contributor
timestamp: October 18, 2012, 01:08:01 am
content: Quote from: andyturk on October 14, 2012, 07:08:19 pmHey, good to hear that C++ is viable on STM32 .During the frustration inducing part of my stm32f4 learning curve I tried C++, but that was one bridge too far at that time. Plenty of errors at the link stage. At this point I am sloooowly getting a handle on things, so I'd like to try again. Are there any particular linker flags / libs that I should be using?

author: mrflibble
author_rank: Super Contributor
timestamp: October 18, 2012, 01:24:13 am
content: Quote from: ptricks on October 15, 2012, 05:16:44 pmThere is plenty wrong with using assembly, even if you are comfortable using it. What's "wrong with it" is that it takes up valuable development time, which IMO is better put into coding functionality. Also higher level generally translates to better maintainability. And from the business perspective it translates to a larger pool of average people writing average code that are then perfectly capable of managing the code base. This as opposed to the magical awesomely clever and handsome rockstar coder that codes asm faster than you do C. And that is with his off hand. Blindfolded. Without coffee on monday morning.But sadly enough the world supply of these mythical creatures is limited, so IMO on average you are better of with mundane boring high level languages.

author: mrflibble
author_rank: Super Contributor
timestamp: October 18, 2012, 01:32:59 am
content: Quote from: AndyC_772 on October 16, 2012, 07:10:01 amHey, that all sounds familiar. Although in my case it was Z80A first, then 68000. 68k asm on ye olde amiga certainly was a breath of fresh air. Memory mapped peripherals, yay!These days not much call for assembler here either. And if I reeeeeally feel the urge to exercise the low level skills it's verilog over here. If that doesn't scratch the low level itch there's always click-n-crash in fpga editor in case you're in the xilinx camp. ;-)

author: nctnico
author_rank: Super Contributor
timestamp: October 18, 2012, 07:58:24 am
content: Quote from: AndyC_772 on October 16, 2012, 07:10:01 amYou're much better off regarding VHDL as a high level language which it is. Otherwise you'll be doing lots of typing on stuff which could easely be solved by a 3 line function. Just for fun look for priority encoder examples. 9 out of 10 will show an equation for each output combination and 1 out of 10 will show a 3 line function which will work for any number of inputs.

author: AndyC_772
author_rank: Super Contributor
timestamp: October 18, 2012, 08:38:00 am
content: I think you'd like my arbitrary n-bit CRC calculator.

author: ptricks
author_rank: Frequent Contributor
timestamp: October 18, 2012, 12:10:46 pm
content: Quote from: mrflibble on October 18, 2012, 01:24:13 amThe problem with that is most of those using the high level languages have no idea what is going on underneath. They only know that if they use this macro or this function it is supposed to generate the program they want, when that doesn't work you have programmers that spend hours scratching their head. I have no issue with using high level languages , but when people don't understand what is going on underneath it leads to problems. I compare it to people that learn electronics by using IC , these people panic when a certain IC isn't available for what they need, they are so used to having a packaged chip that they can't even think about using discrete electronics. I see the people using arduino do this quite a bit, they learn the easy stuff but when something breaks they have no clue how to fix it in hardware or software.

author: mrflibble
author_rank: Super Contributor
timestamp: October 18, 2012, 01:54:44 pm
content: Quote from: ptricks on October 18, 2012, 12:10:46 pmThe problem with humans is that they behave like humans. Using one tool or another is no guarantee for understanding or success. This sort of thing has less to do with using asm vs C and more with a certain mindset.QuoteHey, I resemble that remark! I do okay in the digital domain, but analog is not really my strong suit. So I take it you build up fractional-N synthesizers from transistors? Well, I am perfectly happy usingNationalTI or AD parts for that.Quote

author: Bored@Work
author_rank: Super Contributor
timestamp: October 18, 2012, 05:52:38 pm
content: Quote from: mrflibble on October 18, 2012, 01:54:44 pmYou will change your mind once one shows up in an application on which your safety depends.The bad thing with the Arduino crowd is that the moment they manage to blink a LED they think they are embedded engineers. And the job is not complete until they have glued a fscking Arduino to everything. A few years, maybe just a year, and the first of these "embedded engineers" will show up in the industry.That will be a bit like what happened in the new economy, when suddenly every ditch digger became an "HTML programmer", and tried to pass as a programmer once the new economy was over.

author: dfnr2
author_rank: Regular Contributor
timestamp: October 18, 2012, 08:52:14 pm
content: Quote from: ptricks on October 15, 2012, 11:16:43 pmThat is more to the mark. Outside of the most trivial applications, direct assembly should be avoided (and quarantined where needed for hardware setup, etc.) in professional applications, especially if the cost of bugs could be high.However, every programmer should learn the machine/assembly language and register-level programming of the target chip, and should inspect the compiler output strategically to ensure that code generation is correct.

author: mrflibble
author_rank: Super Contributor
timestamp: October 21, 2012, 09:20:00 pm
content: Excuse the 100% self-interest motivated bump ...Quote from: mrflibble on October 18, 2012, 01:08:01 amI'm hoping this escaped your attention... if not, feel free to ignore it.In any event I'd really appreciate some quick pointers on C++ for the stm32 should you have any. Thanks in advance!

author: andyturk
author_rank: Frequent Contributor
timestamp: October 22, 2012, 02:31:58 pm
content: Quote from: mrflibble on October 21, 2012, 09:20:00 pmSorry, I wasn't paying attention...Well, the key thing is use C++ in an embedded environment. STM32 is the same as Stellaris, is the same as everyone else's ARM, etc. I recommend yagarto's arm-none-eabi gcc, but I think any C++ will do.Here are the compiler switches I use (currently):-fno-rtti -fno-exceptions -fms-extensions -Wno-pmf-conversions -Wno-unused-parameter -Wno-psabi -std=gnu++0x1) -fno-rtti turns off run time type information. You probably won't need it and it leads to code bloat.2) -fno-exceptions does what you think. Exception handling is a good thing, but it also bloats the code because the compiler has to generate two exits for each basic block. Embedded apps generally do without.3) -Wno-pmf-conversion allows the compiler to convert a pointer to a member function like void (A::*fn)() to something like void (*fn)(A*). This is obscure, but I've used it for object-oriented callbacks.4) -Wno-unused-parameter turns off complaints about unused parameters in function definitions.5) -Wno-psabi turns of warnings related to varargs.6) std=gnu++0x enables GNU extensions to C++Your environment will need to have some way of taking control once the CPU comes out of reset. This isn't necessarily a C++ thing, but C++ does add a requirement to call all of the compiler-generated static initialization code. The linker strings together all the compiled constructors for each file/module and creates an array of function pointers. After the CPU comes out of reset and before the call to main(), somebody needs to call those functions. This is might be already handled by your environment, but if not, you'll have to write a little loop. Technically, you should also call destructors after main() exits, but that basically never happens for an embedded app.Occasionally you may run into situations where the compiler generates a call to some strange function that you have to stub out. For instance, you'll see references to __cxa_pure_virtual() are generated if you declare pure virtual functions. I'm not sure why this isn't part of the standard library, but I had to stub it out like this:Code:extern "C" {void __cxa_pure_virtual() {for(;;);}void *__dso_handle = NULL;};The main thing with C or C++ is to avoid dynamic memory allocation, since there probably isn't enough free memory to effectively use a heap. In the C world, this leads to lots of global variables. With C++, it's much better since you can put everything in objects (i.e., compiler managed structs) and then declare a handful of global objects which represent the entire state of your program.

author: Kremmen
author_rank: Super Contributor
timestamp: October 22, 2012, 05:30:17 pm
content: Quote from: andyturk on October 22, 2012, 02:31:58 pmYou have a point but still, never say neverI have used dynamically instantiated classes successfully in Arduino, and in that particular application i considered it the path of least problems. In that case i created the program steps of a programmable camera dolly as a linked list of action objects whose precise number of course depends on the contents of that particular sequence program. Worked like a charm even in the puny RAM of a Mega328.Another, perhaps even better reason not to use dynamic allocation, at least in safety critical applications is the nondeterministic nature of dynamically allocated memory. It wouldn't do for say a nuclear reactor controller to run out of allocatable memory due to fragmentation and delayed or nonexistent garbage collection... (Not that that specific application would be left to one single microcontroller anyway).

author: andyturk
author_rank: Frequent Contributor
timestamp: October 22, 2012, 06:50:18 pm
content: Quote from: Kremmen on October 22, 2012, 05:30:17 pmSure, it can work and it's not hard if you simply assume your allocations will always succeed. To be correct, however, you should consider that those dynamic calls could fail, and then what? On a small device with minimal UI, you can't really pop up a dialog and alert the user. Halting is one option, and rebooting is another, but neither is very attractive for a device in the field.But if it actually is safe to assume all allocations will succeed within the limited memory available, then that means there is an upper bound on what your program actually needs. Making those bounds explicit is the main difference between dynamic vs static allocation. For instance, if your Bluetooth gizmo only needs to communicate with two peer devices, you can pre-allocate (at compile time) buffers and such for those two connections and guarantee you won't have to handle an out of memory situation.This is the approach taken by ChibiOS (a very nice open source RTOS) and it works incredibly well. C++ makes it even easier because the compiler will generate most of the initialization code for you (as long as you've written constructors).

author: nctnico
author_rank: Super Contributor
timestamp: October 22, 2012, 09:55:03 pm
content: Quote from: andyturk on October 22, 2012, 02:31:58 pmThat depends on how you define dynamic memory. I always use a scheduler so there is only one 'process' doing something. This means that every process has the entire stack size at its disposal. It is a very efficient use of memory.

author: andyturk
author_rank: Frequent Contributor
timestamp: October 22, 2012, 11:06:11 pm
content: Quote from: nctnico on October 22, 2012, 09:55:03 pmThat's a true. But there's always a tradeoff somewhere, because the stack itself is basically just a pre-allocated array. If you make the stack bigger, something else gets smaller.Efficiency is important, but robustness is right up there too. Any time you have a call that might fail (i.e., that could have thrown an exception under a bigger OS), you have to think about how to handle it. The same is true if you're allocating memory from the stack. Be careful with C's variable length arrays because the compiler can't check to see that space is available.

author: nctnico
author_rank: Super Contributor
timestamp: October 22, 2012, 11:34:26 pm
content: Fortunately the ARM Cortex Mx devices have a stack pointer check in the hardware. If you have a seperate stack space for exception/interrupt handling then you should be able to detect a stack overflow and somehow recover.

author: mrflibble
author_rank: Super Contributor
timestamp: October 23, 2012, 07:03:21 pm
content: Quote from: andyturk on October 22, 2012, 02:31:58 pmThank you very much for the detailed post!I now got things working with a simple test class and some cout << stuff.Print() action. One thing that struck me as odd was that flashing suddenly took quite a bit longer than I was used to. I haven't investigated fully, but I did notice that for example linker.map is quite a bit bigger. New New! with over 50% libstdc++.a related entries! So probably more action required, but at least things are working now.Incidentally, this is with asummon-arm-toolchainbased setup.

author: andyturk
author_rank: Frequent Contributor
timestamp: October 23, 2012, 08:46:27 pm
content: Quote from: mrflibble on October 23, 2012, 07:03:21 pmYup, the standard library is pretty big. The good news is that you probably don't need it. Just try a trivial main() that avoids stream IO and your executable should crunch right down. I used S-A-T for a while too and switched to yagarto for reasons that I've now forgotten. It probably had something to do with getting the right versions of openocd and gdb.

author: westfw
author_rank: Super Contributor
timestamp: October 24, 2012, 12:33:27 am
content: QuoteAssuming you're using one of the gcc-based compilers, add "-ffunction-sections -fdata-sections" to your compile, and "-Wl,--gc-sections" to the link. This will cause functions and data that are not referenced from anywhere to be "garbage collected" and omitted from your final binary. It's pretty magical and discipline-destroying...

author: mrflibble
author_rank: Super Contributor
timestamp: October 24, 2012, 02:33:41 am
content: Quote from: westfw on October 24, 2012, 12:33:27 amThe --gc-section bit I had already, but I missed the other two. Added now.Quote from: andyturk on October 23, 2012, 08:46:27 pmYou were right. I removed the iostream stuff and that made a big difference.QuoteOr maybe the lack of hardware floating point? As for openocd, I did compile in support for that but I'm currently usingstlink. Mainly because that seemed easier at the time... I must admit I didn't really do any research on openocd vs stlink vs whatever else there may be out there. At first I was concerned with just getting stuff to work. Does openocd (in SAT or in yagarto) have any advantages over stlink?

author: andyturk
author_rank: Frequent Contributor
timestamp: October 24, 2012, 05:10:01 pm
content: Quote from: mrflibble on October 24, 2012, 02:33:41 amI haven't used hardware FP in an mcu project yet, but I'm pretty sure both yagarto and SAT will support it, since they're both using GCC. I've used both stlink and openocd. Stlink is obviously only going to work with ST chips, if that's an issue (I started out using Stellaris parts from TI). Both seem to work fairly well, but my impression is that the openocd project is more active. I've been able to post questions to the mailing list and get answers pretty quickly. I haven't tried that with stlink.For me, it came down to getting emacs (my IDE), gdb and the debugging layer to place nicely together. It was a trial-and-error process, but I've got things working fairly well now with emacs 24.1.1, gdb 6.3.50, and a patched version of openocd 0.6. Thepatchis to handle the "'g' packet reply is too long" error with gdb. If you're curious, read athquad's replyhere.

author: ptricks
author_rank: Frequent Contributor
timestamp: October 25, 2012, 03:08:46 am
content: Earlier I mentioned really good ASM programmers. Here is one that is a good example of what can be accomplished if you really are good at ASM.A complete OS, supports up to 8 cpus, 24 bit color gui with acceleration, networking email and web browser, sound, TV card , dvd, mp3, webcams, and printer support, built in IDE, all of it fits on a 3.5" floppy.http://www.menuetos.net/index.htm

author: andyturk
author_rank: Frequent Contributor
timestamp: October 25, 2012, 05:51:16 am
content: Quote from: ptricks on October 25, 2012, 03:08:46 amAll in ASM. OK. But why?

author: Kremmen
author_rank: Super Contributor
timestamp: October 25, 2012, 07:48:37 am
content: My question as well. A tour de force? Demonstration that it can be done? Certainly not because it was the only/best way to do it. Were i the product owner, i would now be shitless contemplating who will maintain the codebase in the medium/long term...

author: mrflibble
author_rank: Super Contributor
timestamp: October 28, 2012, 05:39:22 pm
content: Quote from: andyturk on October 24, 2012, 05:10:01 pmI recall that at the very least older versions of SAT did not support hardware fpu. No real problem since all my current projects are fairly lame in the number crunching department. I mean, some moderate processing at 125 ksps/24-bit is pretty much a snoozefest.QuoteHeh, this time I decided to not go the emacs route... Although it's always fun when you do the emacs keystrokes to save file + run make... only to realizy that those keys don't quite do the same things in eclipse.