Microchip to acquire Atmel - how do you feel about this?

[nctnico]

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.

[Howardlong]

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.

I 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'.

[nctnico]

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.

[Howardlong]

For ethernet, USB and complex algorithms I look at what is available (preferably free 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.

Zactly, I rest my case me lud!

[Karel]

That'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.

Are you really sure you want to write your own USB and Ethernet stacks?

For 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.

[jeroen74]

I did not know LUFA was ported to other architectures, it started out as a library for USB enabled AVRs.

[Howardlong]

That'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.

Are you really sure you want to write your own USB and Ethernet stacks?

For 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.

Are 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.

[Mechanical Menace]

That'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.

Are you really sure you want to write your own USB and Ethernet stacks?

For 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.

Are 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?

ucLinux 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.

[Howardlong]

ucLinux 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.

Good 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.

[andersm]

If you look at the Microchip repositories on GitHub, they're obviously going to position the forthcoming PIC32MZDA as a Linux platform.

[Karel]

That'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.

Are you really sure you want to write your own USB and Ethernet stacks?

For 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.

Are 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?

So far, we mainly use pic32mx. In some cases we needed USB connectivity. For that we used FTDI chips.

[Howardlong]

If you look at the Microchip repositories on GitHub, they're obviously going to position the forthcoming PIC32MZDA as a Linux platform.

When 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.

[timb]

@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 the TM4C123 Launchpad and the TM4C129 Launchpad

The Launchpads may be adapted to program your own board, but the hassle is not worth when considering the XDS100v2 JTAG debugger costs 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.

Pretty 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.

[Howardlong]

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.)

(My bold/italics) I love that! Makes it sound like you figured all that out in five minutes 

It 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.

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.

One 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.

[rsjsouza]

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=1329412

I find it hard to believe Steve Sanghi was completely oblivious to this.

[botcrusher]

So long as they don't scrap my beloved ATmega chips, I'm good
(Edit, just read above post. That really sucks.)

[ajb]

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=1329412

I find it hard to believe Steve Sanghi was completely oblivious to this.

Microchip is reneging on severance benefits Atmel promised its U.S. employees during prolonged merger discussions, according to one disgruntled employee who supplied documents to EE Times.

...

Thus [Microchip CEO Steve] Sanghi proposed and the Microchip board accepted that it would pay half the cash and bonus severance Atmel offered.  Sanghi and [Microchip President Ganesh] Moorty agreed to take a 50% pay cut for a quarter as part of the deal.

“That’s affective today…I took a bullet for the employees of Atmel two days after they were my employees,” Sanghi said.

Oh, 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.

In an interview with EE Times, Sanghi said Atmel had several severance agreements in place, most of which Microchip has honored, including one for vice presidents “we have honored with every executive terminated so far.”

A separate promise to accelerate equity acceleration for four years for all 176 of Atmel’s directors was “unprecedented,” he said. “Out of 17 companies we’ve acquired, we have never seen director equity acceleration at this rate, the best you can find is acceleration for three or four months…it was not conditional to any date so we are honoring it, it’s extremely expensive but we are honoring it,” he said.

Oh, 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.

[tom66]

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!

[yagan98]

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

[dannyf]

"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.

[ajb]

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."

Did 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)?

[JPortici]

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.

[dannyf]

Did someone forget to tell him about the XMega parts?

Because 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.