Microchip to acquire Atmel - how do you feel about this? - Page 1
Forum section: electronics / general

author: benSTmax
author_rank: Regular Contributor
timestamp: January 13, 2016, 03:04:47 pm
content: So, in the end Atmel wants to be bought by Microchip ...http://www.prnewswire.com/news-releases/microchip-technology-announces-that-its-proposal-to-acquire-atmel-has-been-deemed-a-superior-proposal-by-atmels-board-of-directors-300203728.htmlhttp://www.reuters.com/article/us-atmel-corp-m-a-microchip-tech-idUSKCN0UR1UJ20160113Jan 22ndThis is the Microchip's strategy for Atmel (improve the gross-margin, the operating income and cut from R&D and probably others)http://www.microchip.com/pdf/Atmel_Acquisition_Investor_Presentation_FINAL.pdf

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 13, 2016, 03:24:43 pm
content: Kind of expected this. Atmel has been running razor thin margins on their uC business so it wasn't sustainable in the long term.I still wish my work got Atmel first.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 13, 2016, 04:08:42 pm
content: And Dave's episode #448 may become a prophecy rather than a joke ...https://youtu.be/HWlpqSrabKs

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 13, 2016, 07:05:47 pm
content: I think they should prefix all Atmel part numbers with PIC, just to piss off the fanboys.

author: MT
author_rank: Super Contributor
timestamp: January 13, 2016, 07:12:39 pm
content: Do the opposite not work equally well?

author: Ian.M
author_rank: Super Contributor
timestamp: January 13, 2016, 07:20:10 pm
content: Because the PIC community doesn't have the cross-over with the Arduino community that the Atmel/AVR community does, the proportion of rabid fanbois seems to be much lower.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 13, 2016, 08:39:22 pm
content: Quote from: mikeselectricstuff on January 13, 2016, 07:05:47 pm... I never thought about this but I have to admit the fanboys will see red in front of their eyes if they will have to program a future "PICmega128"

author: dannyf
author_rank: Super Contributor
timestamp: January 13, 2016, 08:43:02 pm
content: The acquisition may not clear anti-trust concerns.Unless the regulators deem both companies / 8-bit mcus so hopeless in competition vs. 32-bit chips that even the combined entity will not gain much power over their customers.edit: from that perspective, if the deal is stopped on anti-trust basis, it would be a great piece of news for both atmel / microchip investors; if the fed offered its blessing, well, great for atmel investors, and terrible for microchip investors.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 13, 2016, 09:28:49 pm
content: Quote from: dannyf on January 13, 2016, 08:43:02 pmTake this as gossip as I cannot share my source...But "a source" has pointed out that PIC is trying the buy so it can get a quick acquisition of an ARM product line. While I love the PIC32s, Microchip isn't thrilled with their performance as the industry loves the overly complex ARM parts.

author: dannyf
author_rank: Super Contributor
timestamp: January 13, 2016, 09:33:48 pm
content: QuoteI would be surprised by that - Microchip couldn't have been so stupid as to sign up an exclusive deal with mips. Buying Atmel to get ARM is too expensive than licensing it from ARM.QuoteA couple years ago I was asked to look at a Microchip's presentation with investors when it should a survey on what people are working on for their next projects. PIC32 was right there in the top ranking, when compared vs. INDIVIDUAL ARM chips,Microchip's PIC32 problems are exclusively theirs.

author: MT
author_rank: Super Contributor
timestamp: January 13, 2016, 10:19:24 pm
content: QuoteWell i use ST chips mainly so i dont feel anything!.Quote from: XFDDesign on January 13, 2016, 09:28:49 pmThat sounds quite desperate!QuoteARM is not overly complex it's ST manuals who are partly crap and because of that i feel butthurt!

author: ajb
author_rank: Super Contributor
timestamp: January 13, 2016, 10:44:28 pm
content: Quote from: dannyf on January 13, 2016, 09:33:48 pmIf they were ONLY buying Atmel to get into ARM, sure, but Atmel is a lot more than that to Microchip. They have a bunch of other product lines, and they're a direct competitor, so there's a lot of actual and strategic value to the acquisition. Anyway Microchip have certainly attached a dollar value to getting Atmel's ready-made, already-on-the-market portfolio of ARM parts versus having to spin up their own ARM line from scratch, and that's certainly something that they're weighing. Remember, it's not just the licensing cost to get an ARM line to market, it's the design and integration of all the peripherals, layout, validation, fabrication windup, marketing, and documentation, all of which have a capital cost as well as an opportunity cost in longer time-to-market.

author: EEVblog
author_rank: Unknown
timestamp: January 13, 2016, 11:17:38 pm
content: Quote from: benSTmax on January 13, 2016, 04:08:42 pmThe Force was strong with that prediction.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 14, 2016, 01:19:24 am
content: Quote from: dannyf on January 13, 2016, 08:43:02 pmHow would that be an issue - there are plenty of other MCU companies out there so nowhere near a monopoly situation.

author: coppice
author_rank: Super Contributor
timestamp: January 14, 2016, 01:32:20 am
content: Quote from: mikeselectricstuff on January 14, 2016, 01:19:24 amNot only are there plenty of MCU suppliers, none have a dominant position. The biggest MCU supplier, Renesas, only has about 20% of the market, and the barriers to entry are fairly low by semiconductor standards. Microchip and Atmel aren't even the biggest MCU suppliers in their segments of the MCU business. The other things Microchip and Atmel make don't have such a big overlap as their MCUs. What possible anti-trust issues could there be?

author: EEVblog
author_rank: Unknown
timestamp: January 14, 2016, 01:43:08 am
content: Quote from: mikeselectricstuff on January 13, 2016, 07:05:47 pm+1

author: VK3DRB
author_rank: Super Contributor
timestamp: January 14, 2016, 02:21:04 am
content: It is not so bad if Microchip buys Atmel.Microchip provides excellent service and support and tend to keep their ICs around forever. Atmel on the other hand has atrocious support (they don't bother answering emails) and provide warnings of products ceasing production as soon as a couple of weeks ahead (eg: The Qtouch debacle in 2008).I program with both brands, and won't get into the technical pros and cons here. But as far as customer service and product availability is concerned, Microchip is a far better company. A buyout might be a big win for customers. Plus Microchip make some great peripheral ICs and power regulators.If their micros start increasing a cost due to less competition, more players will enter the market over time. There is plenty of competition already out there in any case... .TI, ST, Cypress etc.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 15, 2016, 10:18:02 am
content: ... and as expected, Dialog won't raise Microchip's bid. I guess the Dialog shareholders are quite happy to see Atmel go away from them.http://www.wsj.com/articles/dialog-semiconductor-declines-to-raise-bid-for-atmel-1452805166http://www.bloomberg.com/news/articles/2016-01-14/dialog-signals-exit-from-atmel-bid-saying-it-won-t-raise-offer

author: EEVblog
author_rank: Unknown
timestamp: January 15, 2016, 10:39:34 am
content: I couldn't resist based on the thread title:

author: benSTmax
author_rank: Regular Contributor
timestamp: January 15, 2016, 01:11:45 pm
content: Quote from: EEVblog on January 15, 2016, 10:39:34 am+1

author: AndyC_772
author_rank: Super Contributor
timestamp: January 15, 2016, 04:07:24 pm
content: I think if it means a Cortex-M0 or M3 device with a CTMU, then it's a good thing

author: benSTmax
author_rank: Regular Contributor
timestamp: January 15, 2016, 05:43:08 pm
content: Being a user of micros from both of these companies, I have to admit some of the PIC peripherals are quite powerful.Combine these with the Atmel micros and some really cool parts will emerge. The Atmel-only fanboys might get some gems ... but maybe prefixed with "PIC" for the part number

author: tom66
author_rank: Super Contributor
timestamp: January 15, 2016, 06:15:55 pm
content: The PIC16 architecture is getting a little silly, what with them now adding USB to a microcontroller that has only one working register and crazy paging rules. I wouldn't mind seeing a PIC16-style device (with all of the great PIC peripherals) but with an AVR single-cycle core at the heart & 16 working regs.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 15, 2016, 07:00:36 pm
content: Quote from: tom66 on January 15, 2016, 06:15:55 pmAVR CPU & PIC peripherals would be a top-notch 8-bit micro family.

author: free_electron
author_rank: Super Contributor
timestamp: January 15, 2016, 08:22:07 pm
content: Quote from: EEVblog on January 14, 2016, 01:43:08 amand relabel all PIC with AVR.AVR18F2450PIC328

author: nctnico
author_rank: Super Contributor
timestamp: January 15, 2016, 08:45:36 pm
content: I'm not feeling anything since both companies make crappy, bottom of the barrel products and therefore I don't use their parts in any of my designs. Over the years (decades) Microchip and Atmel products have proven to me to have higher (hidden) costs in the long run than the low price of the devices make up for.

author: c4757p
author_rank: Super Contributor
timestamp: January 15, 2016, 10:32:34 pm
content: Quote from: benSTmax on January 15, 2016, 07:00:36 pmThat's an interesting idea. I doubt they'd actually do that, but I'd not mind that at all. PIC's CPU is the single most shite 8-bit CPU I've ever had the displeasure of using, and Atmel's peripherals are, well, boring. Swap 'em around the other way....

author: Howardlong
author_rank: Super Contributor
timestamp: January 15, 2016, 10:43:23 pm
content: Quote from: c4757p on January 15, 2016, 10:32:34 pmIndeed, but let us not forget that this shite architecture is no less than 40 years old now and still selling like hotcakes.But you're right, it's all about the peripherals.

author: c4757p
author_rank: Super Contributor
timestamp: January 15, 2016, 10:52:22 pm
content: I don'treallywant to get a PIC/AVR flamewar going, but really, has anyone ever chosen PIC for the CPU? Nah... Microchip does decent peripherals. It's either that or familiarity.Anyone who thinks the CPU is good is invited to address the four-clock instruction cycleplusrelatively long cycles-per-instruction for many common opcodes, and the ghastly memory access methods that make compiler writing extremely difficult.I'd love to scoop out an AVR CPU and wrap it in some Microchip peripherals. Maybe an M0 core too. Sounds awesome.</dream>

author: VK3DRB
author_rank: Super Contributor
timestamp: January 16, 2016, 01:16:44 am
content: Quote from: nctnico on January 15, 2016, 08:45:36 pmThat's why they are so successful.If you write your code properly and do a robust hardware design around the chips, what's you problem? The only thing I dislike is the price of Atmels debuggers, and Microchip's mediocre IDE. Their chips are fine. Their documentation is pretty good.

author: VK3DRB
author_rank: Super Contributor
timestamp: January 16, 2016, 01:28:41 am
content: Want to design a simple low cost high volume device? Microchip. Want CPU performance but higher cost is not an issue? Atmel. Want to be able to source the same chip is 15 years time? Microchip. Want decent support? Microchip.Its horses for courses. You use the chip most appropriate for the application, cost, availability, support etc.Anyone who can program one brand in C can program the other brand in C. Same with the plethora of other brands/architectures around. But the designer should consider what quality of tools there are.For Atmel ATxmega etc, I really like Codevision AVR, a brilliant IDE written by a brilliant engineer in Romania. The registers are SO EASY to set up within your code, to get you going quickly. So for the cost factor, Codevision AVR can save you heaps of labour by avoiding sifting through a ton of register settings. It would be nice if all chips had such a nice IDE.

author: EEVblog
author_rank: Unknown
timestamp: January 16, 2016, 03:22:39 am
content: Quote from: VK3DRB on January 16, 2016, 01:28:41 amYes, Codevision is very nice.My latest project is PIC 24F, so I've got to go back and learn the new MPLABX. Haven't touched PIC since pre-MPLABX.

author: Someone
author_rank: Super Contributor
timestamp: January 16, 2016, 06:31:38 am
content: Quote from: EEVblog on January 16, 2016, 03:22:39 amAnd they have a free version that is very capable, a great step beyond Arduino.

author: nctnico
author_rank: Super Contributor
timestamp: January 16, 2016, 06:52:12 am
content: Quote from: VK3DRB on January 16, 2016, 01:16:44 amJust compare the specs of their chips to A-brands like TI or Analog. You'll see the Microchip ones are always worse. The hidden costs are in stupid things like chips not behaving according to specifications, little immunity to external noise, logic levels which are choosen stupidly, etc, etc. For example: if you use an ADC from TI or Analog and power it from 5V then most ones will be suitable for use with 3.3V or lower logic levels. Now look at the ones from Microchip. Atmel ditto in other places BTW.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 16, 2016, 11:49:05 am
content: Quote from: EEVblog on January 16, 2016, 03:22:39 amI'm still using the last MPLAB 8.xx which supports a lot of PIC24 and PIC32 devices so see if it supports your device before jumping!For new devices that only have minor differences like memory size (e.g. PIC32MX170) it's not hard to tweak device files to add support.

author: Stonent
author_rank: Super Contributor
timestamp: January 16, 2016, 12:30:32 pm
content: Though the latest Atmel Studio is based on Visual Studio 2015 which I like. I guess it's what you're used to, but I never really cared for Eclipse or any of the other IDEs.

author: dannyf
author_rank: Super Contributor
timestamp: January 16, 2016, 12:31:41 pm
content: QuoteFor a business, what matters most isn't how it is selling now. Instead, how it is going to sell in the future.Future looks quite bleak for Microchip.

author: Howardlong
author_rank: Super Contributor
timestamp: January 16, 2016, 01:18:13 pm
content: Quote from: mikeselectricstuff on January 16, 2016, 11:49:05 amI switch between both 8.92 and X on a daily basis, I still prefer 8.92 as it's far faster in the edit-compile-program-debug cycle despite its little character traits. X I use for the much newer chips that can't be hacked easily into 8 and occasionally to generate a set of #pragma config source code which I copy an paste into my own code: I can't be doing with automated code generators which all too easily overwrite your own careful handiwork and write excessive and largely useless commentary.

author: MT
author_rank: Super Contributor
timestamp: January 16, 2016, 01:42:56 pm
content: Useless and no commentary's at all are one of ST's specialties.

author: Howardlong
author_rank: Super Contributor
timestamp: January 17, 2016, 08:56:13 am
content: Quote from: dannyf on January 16, 2016, 12:31:41 pmIf you've ever had to deal with business cash flow and accounting, you'll know that's not quite true: cash is king.While I agree it does seem counter intuitive and perhaps even absurd that we're still using these 8 bit devices, and that Microchip is still investing in them, to paraphrase Mark Twain, reports of the death of 8 bit have been greatly exaggerated. Repeatedly over many years now the death of 8 bit has been predicted but it's never quite happened.A little frustrating is that the 16 bitters that Microchip have produced continually lag behind in the peripherals that the 8 bitters have. The 16 bit base architecture (ignoring the dsPIC for now) is way better than the 40 year old 8 bit, and is a joy to use in comparison.The dsPIC on the other hand needs a lot of work on the part of the programmer to take advantage of the fixed point ALU, there is no means to automatically leverage its use with the compiler without explicit use of builtins or assembly language, or to use pre-baked library routines. With cheap M4F devices with ever improving peripherals it's hard to see where the dsPIC will fit.In applications, the PIC32MX is just as good as any ARM M0 or M3. Unfortunately the powers that be have chosen to take a rather bizarre direction in the software support, using excessive abstraction and unnecessarily implementing a proprietary software framework more at home with a heavy weight OS than a microcontroller. Luckily on the MX series the old MLA library is still available but is deprecated, although it's an organically derived mess. The new MZ devices pretty much force you into using the new framework. To add to their woes, the first MZ C devices were of appalling quality, although more recently the MZ F devices are far better in that regard. As a competitor to M4F and M7, the PIC32MZ F is certainly a worthy contender.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 18, 2016, 05:30:05 am
content: On the "would anyone pic a PIC for the CPU?" front, I have. I specifically got into the PIC32MZ line as it has a very low barrier to entry over anything arm. Every time I tried to get into ARM, I found it to be a completely rooted venture. Compilers are too expensive (GCC has been a nightmare trying to get to work), Ive not found any programmers for any of the litany of parts out there, and the software side of dev seems to have so much overhead to appease the part, I'd rather get audited by the IRS.PIC32? Open the box and write my own code to twiddle a pin in less than 30 minutes. It's a capable processor, a reasonable amount of horsepower, and of course the great peripheral list (though I still use ADI converters over the "10bit" ADCs).

author: benSTmax
author_rank: Regular Contributor
timestamp: January 18, 2016, 10:30:05 am
content: Quote from: XFDDesign on January 18, 2016, 05:30:05 amI think this was referring only to the 8-bit PIC cores, which are quite an awkward architecture, making the job of C a compiler quite difficult.On the other hand, the 16-bit PIC cores (e.g. PIC24, dsPIC) are nice architectures and in my view they resemble more with the AVR rather than the 8-bit PIC cores.The PIC32 and their MIPS cores are modern and they are an alternative to ARMs.

author: nctnico
author_rank: Super Contributor
timestamp: January 18, 2016, 10:41:03 am
content: @XFDDesign: You are not making a strong case for your abilities to figure something out.There are so many tutorials out there to get an ARM microcontroller going...

author: AndyC_772
author_rank: Super Contributor
timestamp: January 18, 2016, 11:09:51 am
content: Quote from: XFDDesign on January 18, 2016, 05:30:05 amGiving up on ARM is a bad idea in the long run, I'm afraid. The microcontroller world is getting ever closer to standardising on Cortex-M, and having the ability to use this enormous range of parts is absolutely necessary for an embedded developer, IMHO.Download yourself a trial version of CrossWorks and see how you get on. After days spent trying to get Eclipse up and running, searching out "helpful" tutorials that were inevitably outdated, misleading or just plain wrong, I found it an absolute breeze.

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 12:09:52 pm
content: QuoteTwo points:1) you don't quite program the ARM chip, in that you are more than likely programming in C so the stuff that's the ARM core is fully transparent to you, just as if you were programming a PIC/AVR or a PC for that matter, with some minor differences of course.2) the initial difficulties are with the software, both software necessary to get a project set up properly and software necessary to get it to do what you need. The first part is quite ARM- and IDE-specific: you are likely to use CMSIS, and many times vendor-supplied, chip specific start-up / system files. Some IDEs help a lot in this regard, like the new middleware in Keil, or CoIDE. The 2nd part relates to your approach to programming any powerful chip: do you use a library or not. Vendor supplied libraries can be a pain to learn for a beginner and requires a lot of reading and practicing and tracing the code vs. the datasheet, and a level of C-programming skills. This part is fully programmer dependent. If you cannot crack it, you cannot crack it. Not much anybody else can do to help you.Overall, I have found the use of a good IDE like CoIDE quite helpful in getting it going. Otherwise, I have chip-specific templates that I can copy-and-paste to a new project. Coupled with my own middleware, I can get a project going with seconds. The downside with this approach is the large number of files that need to be compiled initially: a minimalist project for me on a STM32F3 is ~25MB and over 1000 source / header files, and the initial compilation takes a couple minutes on a fairly fast workstation, using Keil.The advantage is obvious that it is platform dependent: I can copy my user code to different chips and fitted with the right library and middleware, the project is ready to go and just works.If you are starting out, I would suggest that you take a look at CoIDE - I am a big fan of their products (pre 2.0). Select a chip, select functionalities you want on that chip, and hit compile and you are ready to go. Absolutely a delight to use. the 2.0 beta, however, is a total disappointment.

author: andersm
author_rank: Super Contributor
timestamp: January 18, 2016, 12:30:09 pm
content: Quote from: benSTmax on January 18, 2016, 10:30:05 amIMO they have the same problem as all 16-bitters, namely that you run out of address space even quicker than on an 8-bit CPU, and then have to start adding ugly kludges that don't play well with C and overhead.QuotePIC24 is far more modern (or at least newer) than MIPS! Personally I don't think MIPS make a great microcontroller core. There's too much historical baggage for compatibility, and the large register file consumes more stack and increases latencies. Cortex-M is much more elegant, and since it's a completely new architecture, the designers have been free to innovate. It's possible the architecture doesn't scale as well, but for high-end applications there's Cortex-A and Cortex-R.

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 12:51:35 pm
content: pic24 is the part that microchip should have marketed earlier and more.What a shame.

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 12:52:52 pm
content: I suspect that their reluctance to market pic24 is to protect their 8-bit pics - a golden goose then.Unfortunately, as the market moved on, it is that very golden goose that killed them / their desire to innovate.

author: coppice
author_rank: Super Contributor
timestamp: January 18, 2016, 12:54:37 pm
content: Quote from: dannyf on January 18, 2016, 12:51:35 pmThey tried pretty hard, but Microchip have never been that successful with larger MCUs. Their big successes have always been in the low pin count market.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 18, 2016, 01:28:52 pm
content: Quote from: coppice on January 18, 2016, 12:54:37 pmOne reason might be the lack of "interesting" peripherals (e.g. NCO, COG and all the others - the so called "Core Independent Peripherals") in PIC24 and 32

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 18, 2016, 04:17:23 pm
content: Quote from: nctnico on January 18, 2016, 10:41:03 amThere is also tumblr which has countless people making up all kinds of gender identities that don't exist. It doesn't mean they're "valuable." And "get an Arm micro going" means what exactly? The tutorials for the STM eval board walked you through powering it up and getting their blinking light demo to work. Not actually putting code on it, but just powering it up. This satisfies what you say, but isn't actually "useful."The "free" compilers do not work for me (never got a response out of the micro, no usable framework to just get a micro equivalent of "hello world" just feeling in the dark) and I don't even know if the code that was produced was even correct. The "retail" compilers are so prohibitively expensive, they don't even mention price. If I were committed to spending a few thousand a year on software licenses that require renewals, I'd be going full tilt DSP. When I need more horsepower than what the PIC32 can offer, I go roll my own purpose-built core in an FPGA. Navigating that abyss has actually been far more easy to approach than ARM.Quote from: dannyf on January 18, 2016, 12:09:52 pmI mean getting code loaded into the device when you do a design. You deal with all the hardware requirements, get things routed, fab the PCBs and stuff the boards and now you need to get your code in. I picked up an STM Arm eval board, and they put the goods to burn a part on-board, but get rather silent about getting code in on a final design. It is, if anything, on-par with Atmel's 32bit offering (you use the avr dragon...maybe? who knows. I never got a straight answer about what tool I have to buy for burning code into their 32b micro so I scratched them off the list). I'm able to burn PIC32s with the same tool as burning a dsPIC or PIC18.QuoteI don't have the coin to drop on Keil, so again the barrier to entry prohibits me from the club. Microchip does not, nor does Atmel (though Microchip does charge for "better" compilers).QuoteWe had a discussion at work about "complexity and difficulty of use translates to how powerful something is," in justifying how poorly documented and clunky Allegro is. An analogy was drawn: The Harrier has the highest pilot fatality rate of the present fleet of US forces. It is so terrible, that pilots have been getting incredibly few flight hours. If the logic follows about the difficulty of something to use translates to effectiveness, then it would be reasonable that more branches of service would use the craft in Close-Air-Support than say the A-10 (which they just delayed retirement for, again, due to the complexity of the F35 ).I have invested some amount of time just trying to find books to get my feet wet, but the ones I have found are little more than copies of a datasheet from one particular vendor of ARM core. While Atmel has some differences from ATMega to XMega (for example), they're not so extreme that it requires one to learn a whole new part. Microchip, with their peripheral system having been as well made as it is, translates reasonably well across architectures too (dsPIC to PIC32 has been a breeze for me, outside of a few expected quirks).QuoteAgain, I don't have the coin to afford Keil, or IAR, so I'm priced out of the space anyway. For the people who are embedded designers primarily, I can absolutely see the reasoning in spending the few thousand to rent the compiler - it's a tool like any scope or similar. For those of us not in that club, it's inaccessible.

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 04:45:22 pm
content: QuoteBecause the answer is so simple / in the open that they never expected any embedded engineer to ask: use stlink or jlink. Or a hyper-terminal + bootloader, ....QuoteYou can try the trial version - free with some limitations or CoIDE - free without (code) limitations but may not support your chip.All it does is to take some thoughts / planning to see what you need and what's out there that may fit your needs. If for example you pick the ST chips, there are tons of inexpensive / free tools with full or limited support for those chips.If you pick the Atmel chips, there support is more limited.Setting up a modern IDE is fairly simple and consistent from IDE to IDE. Same goes with setting up a project.You either suck it up and learn to do it; or keep whining about it and never get anywhere.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 18, 2016, 04:58:07 pm
content: Quote from: dannyf on January 18, 2016, 04:45:22 pmWhen I still played with the ST Board, and what I recall from reading, stlink was wrapped around some required supporting hardware that was on the eval board. That's fine. I can make a middle board if I knew what was needed, again that wasn't specified. But maybe you're closer to your point in your condescension than you expect: I'm not an embedded engineer. If I were, as I said before, dropping a few thousand on a compiler would make sense. My investments go to spectrum analyzers, rf sig gens, and radio-oriented test gear. I am an RF Engineer primarily, and have other tools that are not my primary focus. I suppose it's basically like the "PC Master Race" thing with ARM.QuoteAnd that's really reiterating my point. Everything about ARM is "go away" unless you're willing to commit large sums of money. The trial-ware game is something I did with Protel as a kid. I'm willing to spend some money on a compiler. I'm willing (and have) spent money on books and hardware. But there has to be a return on it. Crippleware does not give you a baseline. The success of this route is shown by Analog's VisualDSP++ package. "Yes, you can spend $5,000 on a C compiler for <some> DSPs, with a $500/yr renewal license! By the way, our documentation is terribly poor, and unless you're a significant customer, you won't get any FAE support which will be required to figure your way through the parts." The result of that path has been the effective death of their processor line. If someone comes out with a $250-500 ARM C Compiler that I can crack out some code on, get the damned waste of Si to toggle a pin, then I'd buy it today.QuoteAye, IDEs generally are not too bad. I'm not bitching about IDEs though, am I? As to "suck it up and learn to do it, or keep whining and never get anywhere," that isn't true is it? It's posturing. I tried to get into ARM. It was such a disorganized shitstorm of a mess, I dismissed it casually and "went somewhere" with the PIC32, just as I said in my first comment on the matter.PIC32 offers me a very good option, with reasonable horsepower, good capabilities, decent documentation, an out-of-the-box fully functional no-bullshit compiler, with its premium version still costing less than an ARM compiler, AND the best part of it all: I got a functioning result with the eval board in less than 30 minutes from the time I opened the box. Even you have pointed out that doesn't happen with ARM and its 25MB of underlying setup.

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 05:16:36 pm
content: QuoteYou may want to re-read it.QuoteAnything, not matter how difficult or easy it is, can be a mess to someone, depending on that person's skills and commitment.All I was trying to say is that to a regular person, it should be fairly simple: if all it takes is to downside a piece of software, and click some buttons to set up a program, and read some code / documentation / datasheet, a "caveman" should be able to do that, to borrow a commercial.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 18, 2016, 05:27:34 pm
content: Quote from: dannyf on January 18, 2016, 05:16:36 pmOk, so let's do a BS test that shows I'm below a caveman. The geico point of "so easy a caveman can do it" for auto insurance can be written out:1. Open a web browser.2. go towww.geico.com3. Enter the zipcode in the appropriate box. Click okay.4. Proceed to enter in your information, clicking next when finished with each step.5. Once complete, you will be presented with a list of options for insurance coverage. Pick any one you wish to purchase, or simply close the tab if you are uninterested.Please show me the idiot I am, by expressing the "so easy a caveman could do it" step by step form as above, to pick go from an ARM to say toggling a pin. Hell, just to make it extra super easy, assume we're using the STM32F0 Discovery kit so it's a common platform. The only restriction is no trial ware: this isn't AAA with a teaser coverage.(In thinking about it, just for fun, I might actually do JUST THIS with the PIC32 to further show how easy it actually is).

author: nctnico
author_rank: Super Contributor
timestamp: January 18, 2016, 05:30:15 pm
content: Quote from: XFDDesign on January 18, 2016, 04:17:23 pmDon't try to twist words! Just admit you can't do what others can. No shame in that but just quit pretending that PIC32 is so great and ARM is an impossible hurdle for everyone to overcome.About a decade ago I used GCC + Eclipse CDT to get my own code running on NXP and ST ARM devices. NXP (still called Philips back then) had a serial bootloader tool but for ST I used OpenOCD (and a parallel port JTAG dongle on veroboard). Until then I used batch files and makefiles to compile code so everything was new for me. I managed just fine by combining various tutorials and checking the output (mapfile and hex file). I only needed a couple of days of reading and doing things step by step to get my own standard platform ported and programs to run. I even compiled an ARM version of the MSP430 GCC C library because of it's small size.

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 05:47:05 pm
content: QuoteI did it earlier but I am happy to give it more meat:1) download a copy of CoIDE 1.x;2) install it on your computer;3) run it;4) select your chip and functionalities you desire in your project;You are done.QuoteThat's simply because the PIC32 has simple peripherals.What I find interesting is that people keep complaining about expensive and fancy tools used to program ARM chips. That's like a Ford buyer complaining constantly about expensive and fancy Ferraris. What good does it do?You are far better focusing on tools that fit your needs, not about the fact that other people are driving around in their fancy "Ferraris". Be happy with your Ford.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 18, 2016, 05:54:25 pm
content: Quote from: nctnico on January 18, 2016, 05:30:15 pmIf we're not twisting words, you wrote, "You are not making a strong case for your abilities to figure something out.There are so many tutorials out there to get an ARM microcontroller going..."An inference that I am inept at figuring things out, "just because other have" but specifically written in a way that conveys specific inferiority. In all of the feigned wisdom, it brilliantly omits the possibility that one made the actual effort and quite simply what was found did not work. Again, no twisting of words here. You then follow this up with a statement essentially stating that "there are so many tutorials to get it going," that is must mean they're all good and they all work, in the same sense that everything we read on the internet is true. Thus, my comments which mocked the fact that not everything we read on the internet is actually true.If your case were as trivial and as strong as you suggest, you would point to a single site or so with a complete tutorial that gets something working from start to finish. Just as the other fellow above goes on about it being so easy a caveman could do it, the best way to actually show the kind of highbrow competence you possess is to show, and not tell. Then, if I follow the motions exactly and it works, then I am most certainly the idiot eh? But of course, it's safer to just posture than to actually put up anything that might not actually be right.QuoteI still use batch files and make files for a number of things, esp on RPi GCC dev (which, yes, uses an ARM). But this isn't the low-level guts kind of coding I'd like to be using an ARM for (DSP work). The tutorials for building GCC for ARM that I found only dealt with the ST Micro line (and thus the choice in buying that discovery board), and while I did turn out some basic code from what I could extrapolate from the STM's datasheet, I had no results of any kind from the thing. There was no launch point to prove the toolchain worked. Searching for this information was a scattered mess (incomplete code examples, stuff that wouldn't compile correctly, or code for a different ARM which I didn't have the CMSIS files required to map things). It might be more of an indictment against the state of online tutorial help than anything, when I think about it.Quote from: dannyf on January 18, 2016, 05:47:05 pmOkay. I'll do precisely this tonight. For fun, I will _video_ the result, but I predict there will be a problem in doing so: that particular procedure doesn't actually output anything. The caveman scenario he gets a printable piece of paper stating he has insurance once he buys it. In your summary, all i have is software on my PC, and as we both know that isn't useful for the micro.QuoteAnd that isn't actually a refutation of anything, let alone the post I made which got this derail going.QuoteNot quite, but you're close: It's like a club of Ferrari drivers looking down and asking why people who want to buy a Ford or Toyota even bother; they should just buy a Ferrari. The problem that the econobox driver is attempting to solve is not necessarily the same one the Ferrari driver is solving even though they are both traveling on the road.QuoteYou meanexactlylike I have been saying since the first post on why I chose the PIC32MZ? Funny that! But then don't come prancing around that your Ferrari is "the people's car" or that it's actually a platform with a reasonable barrier to entry. You've agreed with me on several points now that your "ferrari" has not only high maintenance but high cost of entry, which for some people makes it unobtainable in spite of all your ravings that it doesn't. Pick one direction already.

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 06:09:26 pm
content: QuoteDon't know about other exchanges but this exchange with you involved seems to describe a group of "Ferrari" drivers who are actively cheering you on and providing you various ways for you to drive your Ford on the road, by pointing out all those free parts warehouses and mechanisms in the neighborhood.The Ford driver, on the other hand, seems to be fixated by his inability to own or to drive the Ferrari.

author: andersm
author_rank: Super Contributor
timestamp: January 18, 2016, 06:10:34 pm
content: Quote from: XFDDesign on January 18, 2016, 05:27:34 pmInstall GCC (free)Install Eclipse (free)Install the GNU ARM Eclipse plugin (free)Install OpenOCDIn Eclipse, download the STM32F0xx_DFP packUse the "New Project" wizard to create a STM32F0 blinky project. Make sure to configure the right device (STM32F051, 64KB flash, 8KB RAM)Create a new OpenOCD debug configuration, use the bundled stm32f0discovery.cfg configuration scriptBuild & go!

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 18, 2016, 06:19:22 pm
content: Quote from: andersm on January 18, 2016, 06:10:34 pmIf this works, do you have a paypal? I'll buy you a beer. I'll try this specifically, and even outline the steps I take in getting "GCC" and likely repeat what I've already done. I'll still try it as you put down a reasoned attempt at a list, though.Quote from: dannyf on January 18, 2016, 06:09:26 pm"Stop being poor" is not cheering one on.

author: andersm
author_rank: Super Contributor
timestamp: January 18, 2016, 06:30:00 pm
content: Quote from: XFDDesign on January 18, 2016, 06:19:22 pmThanks, but I'm not a beer drinker. Download GCC fromhere, and if you're on Windows, download OpenOCD fromhere. There are other binary distributions for OpenOCD, but that one works and is kept up to date. You can install the Eclipse plugin via the Eclipse marketplace.The plugin author has alsodocumented the process.

author: zapta
author_rank: Super Contributor
timestamp: January 18, 2016, 06:32:12 pm
content: Quote from: andersm on January 18, 2016, 06:10:34 pmOr just use lpcxpresso. A single package install for the IDE, tool chain (GCC) and debugger. Runs on Mac OSX, Linux and windows as IDE or command line make. Free for up to 256K.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 18, 2016, 06:36:51 pm
content: Quote from: zapta on January 18, 2016, 06:32:12 pm$500 for the pro version is completely within reason. Thanks for pointing this one out.

author: nctnico
author_rank: Super Contributor
timestamp: January 18, 2016, 06:59:32 pm
content: Quote from: XFDDesign on January 18, 2016, 06:19:22 pmAll the tools I mentioned are 100% free without any limitations! Oh and I do drive around in a Ford (with a 1.6 litre engine)!

author: dannyf
author_rank: Super Contributor
timestamp: January 18, 2016, 07:07:15 pm
content: QuoteYou seem to be the only person in this exchange who keeps bringing up the fact that you are poor as a reason of unable to code ARM.Everyone else seems to be desperately trying to point out ways where you can program ARM while being poor.QuoteThat's a very good way to help others identify the issues that have prevented you from programming ARM chips.QuoteSounds like you are very afraid of being successful at programming ARM chips.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 19, 2016, 02:37:56 am
content: Quote from: dannyf on January 18, 2016, 07:07:15 pmYou seem to be the only one coming into a PIC/Atmel thread coming to defend ARM in all of its bureaucratic nonsense. And I'm not saying that I'm poor, you will recall that being a part of your car analogy. "Just drive a Ferrari, it's great!" 'I cannot afford a $100,000 car.' "Well stop being poor then, just go test drive them." etc.You have already stated that your codebase requires a massive amount of infrastructure to get anything off the ground. You've pointed to the standard fare compilers which cost a ton. You also point to cripple ware packages that posses the shelf life which would make packaged meat sitting in the sun look good. I will point out that your "cave man" nonsense concluded before any code made its way to any particular part, which rather defeats the purpose. You're free to dismiss the fact that none of these problems exist with the PIC32. You're free to assert that the ARM is a superior part. But, you can be dismissed without care when you assert how great the ARM is, for being everything I've specifically made issue about. As an earlier analogy was made, if this were a gold standard of "good product" then the A10 would be retired in favor of the harrier.QuoteSee earlier point, your list never actually got to sticking any code on a micro, which come to think of it if the extent of your work is getting to the point where you write code but never put it on a processor I suppose I then concede that is a very easy way to develop. It just doesn't actually do anything.Quote from: nctnico on January 18, 2016, 06:59:32 pmAye, GCC is free, if it ever produced code that did anything for me. That was the problem. As to the Ford, nothing wrong with them though I'm biased to Japanese cars (exception being Ariel. I wouldlovean Atom).

author: rsjsouza
author_rank: Super Contributor
timestamp: January 19, 2016, 04:45:23 am
content: @XFDDesign, not all development environment for ARM devices are expensive or come with "some assembly required"; in my experience I have found that Code Composer Studio (free, unless you want to use a high end JTAG debugger) plus either MSP432 or Tiva (TM4C123 or TM4C129) and the software packages such as MSPWare (for MSP432) or TivaWare (for the other two) comprise a good all around development environment.Also, they have some good material to help with theTM4C123 Launchpadand theTM4C129 LaunchpadThe Launchpads may be adapted to program your own board, but the hassle is not worth when considering theXDS100v2 JTAG debuggercosts less than US$100 and can be used with Code Composer for free. Also, the XDS100 can be used with other devices of the TI product line such as DSPs, Cortex A8s, etc and even with OpenOCD.

author: Howardlong
author_rank: Super Contributor
timestamp: January 19, 2016, 08:03:37 am
content: Quote from: zapta on January 18, 2016, 06:32:12 pmIndeed. But then battle with the LPC-Link2 hardware debugger Redlink Server software interface which seems to break at the drop of a hat at you have to unplug everything, restart the IDE and/or terminate Redlink Server from Task Manager. Once you're done that a few dozen times, you learn over time how best to avoid it crashing as well as streamlining the inevitable recovery process when it does.I built a new board a few days ago but with a device I'd not used before, a bottom of the range LPC810, although I've developed and built boards with far more complex devices like the LPC4370 before but had a reference design to base the debugger interface on. It took a good two or three hours to get the toolchain and debugger to work with it, and finally get a blinky to work. True, you can use an online recipe but that just shows you how to upload a hex file through the serial bootloader. To get a LPC-Link or LPC-Link2 to work so you can do some real development took quite a bit more time.It may well be that I have a ton more experience with developing boards with PICs across the entire range than on ARM, where I am limited to my experiences of developing my own boards for half a dozen TI and NXP parts. I find that to get the PIC boards up and running and the toolchain configured to use them is much quicker than anything I've yet to come across on ARM.What I'm saying is that getting a prebaked toolchain up for a dev board always seems a long way from getting a board of your own design up and running in the ARM world.Always learning, that is all.

author: nctnico
author_rank: Super Contributor
timestamp: January 19, 2016, 09:34:05 am
content: @Howardlong: that is why I have given up on on-target debugging decades ago. It is always a house of cards which keeps falling apart. For NXP ARM parts I always use the serial bootloader which works like a charm. For other controllers like the MSP430 I use the simplest programmer but still avoid on-target debugging like the plague.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 19, 2016, 09:41:01 am
content: I can understand people saying they like PIC better than ARM, that is a matter of preference.But to say that ARM lacks cheap tools or is difficult to get into is complete BS!

author: Karel
author_rank: Super Contributor
timestamp: January 19, 2016, 11:19:11 am
content: Quote from: donotdespisethesnake on January 19, 2016, 09:41:01 amYour strong arguments convinced me completely. I'll immediately drop the pics in favor of arm.

author: dannyf
author_rank: Super Contributor
timestamp: January 19, 2016, 12:09:51 pm
content: "But to say that ARM lacks cheap tools or is difficult to get into is complete BS!"I have heard stories of men who coded the world into existence but find it too challenged to set up gcc tools and ides to code the arm chips.I guess this guy will be our first test case of why, once he follows through by posting his video of installing some ide on his pc. We will know then what he is capable of, but more importantly what he is not capable of.

author: Howardlong
author_rank: Super Contributor
timestamp: January 19, 2016, 12:35:41 pm
content: Quote from: nctnico on January 19, 2016, 09:34:05 amWhich begs the question... how are you debugging your targets with application-specific hardware? Probing toggling pins and printf on a UART? Not that there's anything wrong with that, I still do that extensively, and for a great many years that was the only way, but I think I've just been spoilt over recent years with the very fact you can debug on target that it seems an inevitable pre-req before coding anything more than a blinky. Maybe I should go back to the good old days!

author: nctnico
author_rank: Super Contributor
timestamp: January 19, 2016, 01:02:36 pm
content: I debug & test complex algorithms and other code on a PC. Much easier and faster. For example: a PC can eat through half an our worth of audio samples in a blink of an eye. Or how about unit/stress testing a complicated memory allocator or protocol stack? Again a PC can go through many more scenarios in less time than a microcontroller and create a comprehensive report on disk as well.

author: Howardlong
author_rank: Super Contributor
timestamp: January 19, 2016, 01:06:37 pm
content: Quote from: nctnico on January 19, 2016, 01:02:36 pmWell yes, but what about yourQuote from: Howardlong on January 19, 2016, 12:35:41 pm

author: nctnico
author_rank: Super Contributor
timestamp: January 19, 2016, 01:18:17 pm
content: Application specific hardware usually only needs a very thin driver layer and you can use test equipment to verify whether it is controlled right. The other software talks to that through some kind of driver API. That driver API can be modelled so the rest can be tested on a PC. All in all it depends on the complexity of the system how far to take testing on a PC. One of my first big projects was an ISDN protocol stack. I developed & verified that on a PC first using test benches for various situations so when I ran it on a microcontroller (after a couple of months of development) it almost worked first time. I had to chase a nasty compiler bug to get it working.

author: zapta
author_rank: Super Contributor
timestamp: January 19, 2016, 01:26:51 pm
content: Quote from: Howardlong on January 19, 2016, 08:03:37 amI use the Link 2 but was not aware of any Redlink server, nor did I have to start the IDE (there is that red square button that terminates the debugging session). I am using it on Mac OSX if it matters.Most of the time I just use the USB bootloader and set it up in the IDE as an external tool that builds an loads in one click. The hardware debugger is just for rare tough problems.

author: coppice
author_rank: Super Contributor
timestamp: January 19, 2016, 01:27:16 pm
content: Quote from: nctnico on January 19, 2016, 01:18:17 pmIt amazes me how few people use this approach. I try to make sure my final code can still be built and run on a PC, so most future maintenance work can be conducted on a PC. Debugging in the target only makes sense for target specific code, and in most projects that's a small percentage of the total.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 19, 2016, 01:33:08 pm
content: Quote from: Howardlong on January 19, 2016, 01:06:37 pmI am using heavily the PC as well when developing the HW-independent code/libraries.For the HW-specific part, I am trying to use APIs that are as generic as possible and use the provided simulator (for the tools providing one) to run the target firmware through some test cases.This approach helped me in the past, when some of the devices I created were not working as expected when deployed in the field. I was able to connect to these devices, take a snapshot of their RAM(by attaching to the running target and pausing the firmware execution) and then use these snapshots to fix the firmware. By doing so I was able to find out about some situations that I never really thought about in the beginning. (they were mostly related with HW behavior)Some of the best simulators I've ever worked with are the one provided within Keil MDK and the one provided for the former-Freescale/Motorola (now NXP) S08 family.These simulators provided debugging commands that allowed me to create various scripts for setting up the simulated HW in various situations, inject various RAM contents and see how the firmware was behaving.

author: dannyf
author_rank: Super Contributor
timestamp: January 19, 2016, 06:48:29 pm
content: "Some of the best simulators I've ever worked with are the one provided within Keil MDK"Some of the features provided by keil are revolutionary. Like the ability to plot a variable in chart. People have since implemented that via uart, or in the case of segger, j-scope. Except that keil did it way back.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 19, 2016, 10:54:37 pm
content: and as expected ...http://www.prnewswire.com/news-releases/microchip-technology-to-acquire-atmel-300206644.htmlAVRs will come having the Microchip logo in the future ... I don't think there will be any issues with this merger

author: Howardlong
author_rank: Super Contributor
timestamp: January 20, 2016, 01:16:28 am
content: Quote from: nctnico on January 19, 2016, 01:18:17 pmYou can use test equipment if it exists for your application, but I am also referring to any other devices you might have on your board like codecs, complex external clock configurations, Ethernet PHYs, digital up and down converters, LCD displays etc.Certainly of course any application algorithms I code up and test on the PC first. Most of my firmware work is in the DSP field for RF and indeed I'd be nuts to try to get those algorithms working on the target device first, but I don't have anywhere near a decent enough hardware representation emulated to be able to just drop it in an expect it to work first time. You are lucky if you do have the luxury of having your hardware emulated well enough or a common API with an already tested HAL. Almost all of my work on the device itself is getting that HAL developed and working.If you can get a set of complex device specific peripherals configured correctly together with DMA, timers and interrupts behaving well with your external on board hardware devices first time that is fit for purpose just from reading a data sheet then I lift my cap to you, you are a better man than me!My work flow is to unit test everything first and a significant proportion of that work is getting each of the peripherals working correctly together with DMA, timers and interrupts on the device itself and interfacing correctly with other on board hardware in both the digital and analogue domains. Once that's done, I can integrate with test harnesses and finally the application code. If the HAL is already done for you and you're lucky enough that it fits your application's requirements then yes, not a lot of time is needed on the device itself, but someone somewhere will have been there before you doing that work I'm sure.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 20, 2016, 09:26:48 am
content: I found this on a forum ..."I felt a great disturbance in the EE field, as if millions of Atmel vs. Microchip arguments cried out, and were suddenly silenced"

author: nctnico
author_rank: Super Contributor
timestamp: January 20, 2016, 12:23:33 pm
content: Quote from: Howardlong on January 20, 2016, 01:16:28 amI build/verify these parts of code step-by-step using test equipment, toggling I/O pins and collecting statistical data like the number of interrupts, number of bytes transferred, DMA transfers, etc. There is not much you can do here with a debugger because interrupts and DMA transfers often have hard realtime requirements.

author: rsjsouza
author_rank: Super Contributor
timestamp: January 20, 2016, 12:55:05 pm
content: Quote from: benSTmax on January 19, 2016, 10:54:37 pmIf Microchip feels the Atmel brand has strong market recognition, they will keep the logo on their parts - similarly to what TI did years ago by leaving the Burr-Brown logo.Quote from: benSTmax on January 20, 2016, 09:26:48 amThat's absolutely hilarious!

author: Howardlong
author_rank: Super Contributor
timestamp: January 20, 2016, 05:34:58 pm
content: Quote from: nctnico on January 20, 2016, 12:23:33 pmIndeed, as do I, but without doubt being able to place a breakpoint and look at variables/memory/peripherals to understand what is going on without having to write special code and go through several iterations before you've figured out what the problem is must have some value, surely? Your average serial UART channel, even at a few Mbps, just doesn't cut it even in audio DSP.I'm just really quite surprised that these days people don't value a debugger as part of their analysis toolkit, that's all: and I thoughtIwas a Luddite!!! Or maybe it is just that they're too hard to get working, now that I can relate to.

author: nctnico
author_rank: Super Contributor
timestamp: January 20, 2016, 07:39:09 pm
content: In some of my projects I have a mem command to look at memory locations. In my experience it helps to keep these kind of tools in the firmware to do diagnosis later on when a product is installed somewhere. With most firmware you need to be able to debug/diagnose it long after you have the possibility to connect a debugger. IOW: If I feel that I need to look at certain information now to check things I can foretell that I will want to look at that information later on as well. With a debugger you have to point it at a location (out of many...), look at the contents, interpret the contents and then make a decission whether you expect that value or not. In my firmware I typically have a status command which dumps all these kinds of values in one go in plain text with the proper units. Much easier to understand and much easier to see whether some values are wrong or not. Firmware needs a certain ability of doing (self) diagnostics.

author: dannyf
author_rank: Super Contributor
timestamp: January 20, 2016, 11:08:08 pm
content: I'm really tired of trying to get into Harvard, or MIT or CalTech, or schools like that in the US.What are their counterparts in the UK/Europe?

author: Howardlong
author_rank: Super Contributor
timestamp: January 20, 2016, 11:18:15 pm
content: Quote from: nctnico on January 20, 2016, 07:39:09 pmIt sounds like the level of your embedded stuff lives far higher up the food chain than mine.

author: mariush
author_rank: Super Contributor
timestamp: January 22, 2016, 04:10:26 am
content: NY Times story about Microchip buying Atmel :http://www.nytimes.com/2016/01/20/business/dealbook/microchip-technology-to-buy-atmel-for-nearly-3-6-billion.html?_r=1Didn't know they also bought Micrel last year, those guys had some nice switching regulators and lots of power management stuff. Seems like smart decision for MicrochipThey also bought Supertex (they have some high voltage ics and led drivers and ultrasound products from what I can see) and ISSC (bluetooth stuff mostly as far as i know) .. overall quite a range of products under a single "roof".

author: coppice
author_rank: Super Contributor
timestamp: January 22, 2016, 04:22:06 am
content: Quote from: nctnico on January 20, 2016, 07:39:09 pmI think a lot of engineers are just too short sighted to plan in the perpetual possibility of attaching a debugger. If there are blown JTAG fuses, or other security methods to keep people out of the code, a debugger obviously can't be directly attached to a production unit. That doesn't stop you getting a specially constructed sample of the product without the fuses blown, and debugging with that.The simplicity of attaching most modern debuggers through a low pin count JTAG port has been a huge boon for keeping debugger use a perpetual option. Boards in orbit are an obvious exception.

author: dannyf
author_rank: Super Contributor
timestamp: January 22, 2016, 01:58:54 pm
content: Quote from: XFDDesign on January 18, 2016, 05:54:25 pmXFDDesign, how are you doing finding/downloading/installing the IDEs or the compilers?A few days have passed and I am starting to get worried that your promised video isn't forthcoming.If you need any kind of help (not that I think you need help), please let us know.Ciao.

author: benSTmax
author_rank: Regular Contributor
timestamp: January 22, 2016, 08:37:24 pm
content: I started with ARM MCUs back in the Luminary Micro days. I got a development kit that came with Keil on its CD.For me, Keil was the real ARM eye-opener and it helped me understand the details that I missed/forgot after reading the ARM CPU PDF manuals. After running (in debug) the given examples I realized the learning curve was cut short by this great IDE.You don't have to buy a kit and start with ARM MCUs. Just download the evaluation version of Keil and step through the provided simulator examples. You cannot ask for more ...For anyone starting with ARM MCUs I highly recommend Keil (the evaluation version is perfectly fine for learning purposes) because it is a simpler IDE (it helps the people that haven't worked with Eclipse before) and the visualization options (registers, memory, ...) are simply awesome.

author: dannyf
author_rank: Super Contributor
timestamp: January 22, 2016, 08:43:51 pm
content: I would vote for Keil as well: for its simplicity and its utilitarian approach: nothing fancy and single-mindedly focused on getting the job done.RTT in v5 is also very good, but incomplete.If you work over many platforms, IAR is a worthy consideration: it is even more utilitarian than Keil.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 22, 2016, 10:10:20 pm
content: Quote from: Howardlong on January 17, 2016, 08:56:13 amThat's why I never use vendor frameworks. Ever. It's just not worth the pain and hassle. I'd rather take the time to write my own. Then I know it's done right.

author: Howardlong
author_rank: Super Contributor
timestamp: January 23, 2016, 11:03:53 pm
content: Quote from: Sal Ammoniac on January 22, 2016, 10:10:20 pmAre you really sure you want to write your own USB and Ethernet stacks?

author: dannyf
author_rank: Super Contributor
timestamp: January 23, 2016, 11:08:18 pm
content: QuoteOn many not-too-complex applications (see a mp3 player), that's practically impossible to do.And in many shops, you have to jump so many hoops to get people to discuss the possibility that you would be wise to give up.

author: nctnico
author_rank: Super Contributor
timestamp: January 23, 2016, 11:59:48 pm
content: Quote from: Howardlong on January 23, 2016, 11:03:53 pmUsually the USB and ethernet stacks aren't vendor provided to begin with. But for simple peripherals like SPI, UART, CAN, I2C, GPIO, timers, etc, etc you are far better off writing your own or using field-proven code from third parties than to rely on the vendor provided libraries.

author: Howardlong
author_rank: Super Contributor
timestamp: January 24, 2016, 12:29:24 am
content: Quote from: nctnico on January 23, 2016, 11:59:48 pmYes, but I wasn't talking about SPI, UART etc, I was specifically addressing complex peripherals like Eth and USB. I absolutely agree that there is a lot to be said for using your own code for driving simple peripherals. Most APIs for simpler peripherals are barely fit for purpose, trying to be jacks of all trades and masters of none. And at the end of the day, you need to understand how these simple peripherals work to use them, and using someone else's crappy abstraction isn't going to help you very much. Not to mention when you want to start using DMA with them.For Microchip eth and USB are vendor supplied, I can't imagine even contemplating writing either stack, far better for my sanity and efficient use of resources to buy it in or use the vendor-supplied stack, at least you stand a chance spending time writing your application and not a protocol stack.Even if you use something like LWIP, someone's still going to have to write a driver for it and manage both the on chip eth and external phy. While the external phy isn't too bad, I'd not be too keen on writing and debugging the eth driver. For USB, well, I wouldn't even want to start marrying up a given physical interface and come up with an API.Regrettably Microchip have pretty much forced the use of their Harmony software framework now on PIC32MZ if you want to use the integrated Ethernet or USB. With it, there's a whole steaming pile of abstraction to learn. But as you need to understand the simpler peripherals anyway to use them, why would you want waste time learning the shortfalls of someone else's abstraction when you could've written your own?In the end I am in agreement with you, but I was specifically raising what to do about more complex peripherals. Sure, you could buy in a Lantronix adapter or similar, but for medium to large volume price sensitive applications that's not commercially viable. FWIW, the same applies to the use of FTDI chips in the USB space: they're an expensive peak in the BOM, so I avoid them for anything other than small volume stuff.

author: nctnico
author_rank: Super Contributor
timestamp: January 24, 2016, 12:39:20 am
content: Well you can always use the vendor provided source code as a starting point for your own. NXP has libraries with source code for their peripherals. I used those as examples for my own code. You don't always have to start from scratch.

author: Howardlong
author_rank: Super Contributor
timestamp: January 24, 2016, 12:51:39 am
content: Quote from: nctnico on January 24, 2016, 12:39:20 amI wonder, are you talking from experience when trying to port code for Eth or USB from one stack to another!? If so then you are a wiser man the me. That is _not_ a small task. I do speak from experience, by the way, and it's most definitely not an economically viable way to approach it. Far better to buy it in, unless of course you're doing it for the academic exercise, which in itself is a worthy reason, but it won't get the job done cheaper or faster, that's for sure. I know, I've been there. Just sayin'.

author: nctnico
author_rank: Super Contributor
timestamp: January 24, 2016, 02:20:47 am
content: For ethernet, USB and complex algorithms I look at what is available (preferably open source -LGPL- so the source is also available for debugging) and what others haved used succesfully. For example NXP has ported LUFA (an open source USB stack for microcontrollers) for use in their USB enabled device so you can build USB host gadgets. Even with that it took me 2 weeks to get it working and iron out some bugs in order to make a reverse USB to serial bridge. I'm happy someone took the time to create LUFA because before that there wasn't anything like that out there. I look at commercial libraries as well but for the low volume products I usually create the prices are usually insane.

author: Howardlong
author_rank: Super Contributor
timestamp: January 24, 2016, 02:25:47 am
content: Quote from: nctnico on January 24, 2016, 02:20:47 amZactly, I rest my case me lud!

author: Karel
author_rank: Super Contributor
timestamp: January 24, 2016, 10:26:02 am
content: Quote from: Howardlong on January 23, 2016, 11:03:53 pmFor that we use Linux. If we don't use Linux, we don't use USB or ethernet. Without Linux we write everything ourselves,including FAT32 and SD-card drivers.

author: jeroen74
author_rank: Frequent Contributor
timestamp: January 24, 2016, 08:42:39 pm
content: I did not know LUFA was ported to other architectures, it started out as a library for USB enabled AVRs.

author: Howardlong
author_rank: Super Contributor
timestamp: January 24, 2016, 11:09:52 pm
content: Quote from: Karel on January 24, 2016, 10:26:02 amAre you sure, that sounds like a rather blanket statement? So you demand Cortex A and reject all Cortex M and PIC32 for any USB and Eth development? I can understand your statement somewhat on a host, but not on every device. It seems a bit of overkill to throw Linux at most USB device applications, not to mention the inevitable cost implications on a medium to large volume product. You'd put Linux in a mouse, flash drive, soundcard or basic HID interface for example?Edit: I'm not sure how I could forget to mention my own experiences with embedded Linux USB stacks. Like, for example, the MIPS OpenWRT fork not properly calculating bandwidth of FS devices, or the RPi Mk1 USB stack which has numerous limitations.For OpenWRT in particular, I spent several days debugging that sucker about three years ago. In the end I considered it not fit for purpose despite fixing the problems I found: I was spending far too much time trying to understand and make the distro work, and not making the application itself. That application ended up on NXP's LPC4370 using their LPCopen APIs and recommended add ons, ported from reference designs. Another newer version is in the pipeline on PIC32MZ EF.And the RPi? The USB code was hidden away in the GPU for some reason, I gave it up as a bad job, but the RPi team acknowledged that the stack was not compliant, and it was never going to be fixed in that device. In contrast, the RPi 2 (as well as numerous other OSes and distros) work flawlessly in the same application.

author: Mechanical Menace
author_rank: Super Contributor
timestamp: January 25, 2016, 06:11:43 am
content: Quote from: Howardlong on January 24, 2016, 11:09:52 pmucLinux runs happily on a lot of Cortex M and MIPS parts. The main barrier is flash and ram, but tbh a lot of the time you'll only be running the kernel and your app without even having busybox involved.

author: Howardlong
author_rank: Super Contributor
timestamp: January 25, 2016, 06:36:59 am
content: Quote from: Mechanical Menace on January 25, 2016, 06:11:43 amGood point. Someone still has to write the BSP though, so in that respect you're still in the same boat as someone who's running on bare metal. If you're lucky, both will be using a reference board as a starting point for their hardware. If not, both are going to have quite a bit of work to do.

author: andersm
author_rank: Super Contributor
timestamp: January 25, 2016, 07:11:56 am
content: If you look at theMicrochip repositories on GitHub, they're obviously going to position the forthcoming PIC32MZDA as a Linux platform.

author: Karel
author_rank: Super Contributor
timestamp: January 25, 2016, 07:40:54 am
content: Quote from: Howardlong on January 24, 2016, 11:09:52 pmSo far, we mainly use pic32mx. In some cases we needed USB connectivity. For that we used FTDI chips.

author: Howardlong
author_rank: Super Contributor
timestamp: January 25, 2016, 07:39:19 pm
content: Quote from: andersm on January 25, 2016, 07:11:56 amWhen I spoke to a buddy of mine who's been a staffer at Microchip for many years, he did allude to this a couple of years ago. Indeed it's now transpired that the devs behind the Harmony framework are Linux kernel types, which explains a lot, although not in a good way if you want a sleek HAL. In my experience the network layer for example on Harmony with a 200MHz PIC32MZ doesn't perform anywhere near as well as on an old 80MHz PIC32MX announced in 2009 using the old MLA/MAL.

author: timb
author_rank: Super Contributor
timestamp: January 25, 2016, 11:16:49 pm
content: Quote from: rsjsouza on January 19, 2016, 04:45:23 amPretty much this. You can also run Code Composer in your browser! Just install a Chrome/Safari plugin and you can program your board from the cloud. It actually works quite well!Personally, I just use the latest version of GCC-ARM-ABI-NONE to compile, with a stripped down version of TivaWare which provides all the headers and libraries. You can use any IDE you want this way, I use Xcode through a custom version EmbedXcode. (I take the TivaWare package from TI and strip all the non-GCC parts from it, which reduces the size considerably. Then I fix the Makefiles for some of the PC-side applications to compile on OS X and Linux. It's available on my GitHub if anyone wants a copy.)One of these days I'd like to combine the GCC, OpenOCD, TivaWare and EmbedXcode packages and release it as a single package, to make it easy to get up and running on OS X.

author: Howardlong
author_rank: Super Contributor
timestamp: January 26, 2016, 01:03:50 pm
content: Quote from: timb on January 25, 2016, 11:16:49 pm(My bold/italics) I love that! Makes it sound like you figured all that out in five minutesIt is my experience that getting any environment up and running from recipes like this is rarely as simple as it seems, because they're always dependent on precise versions (if you can still find those versions) of the the components to work, and only work on a specific OS... which might or might not have had a bunch of unknown prerequisites loaded.I've lost count of the number of recipes like this I've been through only to spend hours if not days trying to figure out why they won't work. Pretty much every cross compiling Linux kernel development recipe I've ever tried falls into this category in my experience, it's like developing on quicksand.The pre-baked sandboxed deployments help an awful lot in this regard.My biggest fret about using CCS has been in trying to understand how to set up the paths correctly for a custom project, and using them in the right way, rather than fighting against them all the time. I still have yet to fully understand the way it's meant to work. For me it's an unnecessary complication, or at least it's just not explained too well, or I'm just too thick and impatient to understand it anyway.QuoteOne of these days... ;-)At the end of the day I am sure we all have our own favoured way of working, and all have their pros and cons. Personally I'd rather have a consistent and reliable environment, one that I don't have to spend hours tinkering with, nursing and updating, hours that could be spent getting a real piece of hardware out.

author: rsjsouza
author_rank: Super Contributor
timestamp: April 18, 2016, 01:50:27 pm
content: Sorry for reopening an old thread, but it seemed very appropriate.I don't know what everyone feels about it, but certainly the employees are feeling very angry/sad:http://www.eetimes.com/document.asp?doc_id=1329412I find it hard to believe Steve Sanghi was completely oblivious to this.

author: botcrusher
author_rank: Regular Contributor
timestamp: April 18, 2016, 02:14:53 pm
content: So long as they don't scrap my beloved ATmega chips, I'm good(Edit, just read above post. That really sucks.)

author: ajb
author_rank: Super Contributor
timestamp: April 18, 2016, 05:58:48 pm
content: Quote from: rsjsouza on April 18, 2016, 01:50:27 pmQuoteOh, bullshit. Averaged out over the year you took a 12.5% pay cut, and you act like people should be thanking you that they're getting even half of the benefits they were promised? Fuck off. Maybe Atmel made some promises to their employees that they shouldn't have, but guess what? You're Atmel now, now and those are your promises. Be an asshole and slash those benefits in half if you want, but don't act all magnanimous because you didn't slash them even further.QuoteOh, but you've taken good care of all of the suits. Who cares if the poor schlubs who make a fraction of what they do get screwed. Man, fuck this guy.

author: tom66
author_rank: Super Contributor
timestamp: April 18, 2016, 06:32:28 pm
content: I can relate to the Harmony issues. I had a similar issue recently getting mTouch (capacitive button sensing) to work on a PIC16F.First, I purchased a low-cost Curiosity dev kit because it has an mTouch button on it. The factory firmware works perfectly well with this board, cap sensor lights the LED when pressed and all that. So, you'd suppose this factory demo application would be available on Microchip's website? Nope! Searched for a good half hour before giving in. None of the demo applications for other processors support it either!So, I decide to overwrite the firmware and replace it with new software using the mTouch library. First, it turned out my JRE for MPLAB X was out of date so I had to manually replace the JRE and change a configuration file. Then, I had to faff around with getting Microchip's Code Generator working because no, you can't use mTouch without that, it would be too easy. Finally, I do all of this and it does pulse the pin but because the interrupts aren't configured correctly, it doesn't work for detecting presses. Not to mention it uses something like 99% of the CPU with my main loop barely getting a chance to execute! I'm four hours in the hole and making no progress. So, in the next half hour I knock together a simple CapTouch library of my own which works perfectly. Microchip throw over 1,000 lines at the problem and produce a barely functional library: 50 lines later I have a simple capacitive touch sensor, which is all I wanted. Why do they make it so abstracted and complex?? It's a f**king 8-bit processor with 512 bytes of RAM and a few K's of flash...It doesn't need abstraction, it can't handle it!Microchip just screw up software. They just can't write decent software for their own CPUs!

author: yagan98
author_rank: Newbie
timestamp: May 05, 2016, 04:25:20 pm
content: Ganesh Moorthy - MCHP President & Chief Operating Officer:"The 8-bit AVR microcontroller, which is still very popular among a broad base of engineers, had atrophied under Atmel over the last five years as resources were diverted to touch and 32-bit microcontrollers. That stopped on April 4 as we reprioritized resources to reinvigorate the iconic AVR microcontrollers to drive growth. We expect to release a steady stream of innovative new AVR microcontrollers over the next 12 months that will lead its resurgence even as we continue to release a steady stream of innovative new 8-bit PIC microcontrollers."I think it makes sense.source:http://seekingalpha.com/article/3971573-microchip-technology-mchp-steve-sanghi-q4-2016-results-earnings-call-transcript

author: dannyf
author_rank: Super Contributor
timestamp: May 05, 2016, 05:00:55 pm
content: "We expect to release a steady stream of innovative new AVR microcontrollers over the next 12 months that will lead its resurgence"They want to be the biggest fish in Ana ever shrinking pond.Not a good long term strategy.

author: ajb
author_rank: Super Contributor
timestamp: May 05, 2016, 05:55:37 pm
content: Quote from: yagan98 on May 05, 2016, 04:25:20 pmDid someone forget to tell him about the XMega parts? They already package some pretty powerful peripherals in with a ~32MIPs AVR core, how much more innovative is it worth getting with an 8-bit architecture?For that matter, what's been so "innovative" in the low-end PIC line over the last five years (honest question, I haven't followed them)?

author: JPortici
author_rank: Super Contributor
timestamp: May 05, 2016, 06:04:13 pm
content: well i consider the 10f to be the low-end pic line (or, baseline)12f is getting yesterday's 16f peripherals, 16f is getting very interesting, new and better peripherals with every new chip... linear memory addressing (besides bank switching), 16bit resolution PWM, 24 bit counter, adc with math pac/pid controller, configurable logic cell, data signal modulator, nco, usb ... it only lacks an 8 bit multiplier.... the reason why they just don't add that -and ethernet- and kill the 18F line.. or add new 16F peripherals to the 18F line... i don't know.

author: dannyf
author_rank: Super Contributor
timestamp: May 05, 2016, 06:33:09 pm
content: QuoteBecause he realized, quite correctly may I add, that there is no future for XMega parts, just like ATmel realized that there is no future for their own AVR32 parts.I think Microchip may realize, hopefully soon, that there is no future for PIC32 too.