Author Topic: Microchip to acquire Atmel - how do you feel about this?  (Read 48543 times)

0 Members and 1 Guest are viewing this topic.

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #75 on: January 19, 2016, 01:06:37 pm »
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.

Well yes, but what about your

application-specific hardware?
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26761
  • Country: nl
    • NCT Developments
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #76 on: January 19, 2016, 01:18:17 pm »
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.
« Last Edit: January 19, 2016, 01:21:21 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #77 on: January 19, 2016, 01:26:51 pm »

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

 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8606
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #78 on: January 19, 2016, 01:27:16 pm »
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.
It 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.
 

Offline benSTmaxTopic starter

  • Regular Contributor
  • *
  • Posts: 87
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #79 on: January 19, 2016, 01:33:08 pm »
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.

Well yes, but what about your

application-specific hardware?
I 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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #80 on: January 19, 2016, 06:48:29 pm »
"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.
================================
https://dannyelectronics.wordpress.com/
 

Offline benSTmaxTopic starter

  • Regular Contributor
  • *
  • Posts: 87
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #81 on: January 19, 2016, 10:54:37 pm »
and as expected ...
http://www.prnewswire.com/news-releases/microchip-technology-to-acquire-atmel-300206644.html
AVRs will come having the Microchip logo in the future ... I don't think there will be any issues with this merger
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #82 on: January 20, 2016, 01:16:28 am »
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.

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

Offline benSTmaxTopic starter

  • Regular Contributor
  • *
  • Posts: 87
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #83 on: January 20, 2016, 09:26:48 am »
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"
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26761
  • Country: nl
    • NCT Developments
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #84 on: January 20, 2016, 12:23:33 pm »
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!
I 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline rsjsouza

  • Super Contributor
  • ***
  • Posts: 5980
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #85 on: January 20, 2016, 12:55:05 pm »
and as expected ...
http://www.prnewswire.com/news-releases/microchip-technology-to-acquire-atmel-300206644.html
AVRs will come having the Microchip logo in the future ... I don't think there will be any issues with this merger
If 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.


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"
That's absolutely hilarious!

Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #86 on: January 20, 2016, 05:34:58 pm »
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!
I 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.

Indeed, 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 thought I was a Luddite!!! Or maybe it is just that they're too hard to get working, now that I can relate to.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26761
  • Country: nl
    • NCT Developments
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #87 on: January 20, 2016, 07:39:09 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #88 on: January 20, 2016, 11:08:08 pm »
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?
================================
https://dannyelectronics.wordpress.com/
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #89 on: January 20, 2016, 11:18:15 pm »
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.

It sounds like the level of your embedded stuff lives far higher up the food chain than mine.
 

Offline mariush

  • Super Contributor
  • ***
  • Posts: 4984
  • Country: ro
  • .
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #90 on: January 22, 2016, 04:10:26 am »
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=1

Didn'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 Microchip
They 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".
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8606
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #91 on: January 22, 2016, 04:22:06 am »
With most firmware you need to be able to debug/diagnose it long after you have the possibility to connect a debugger.
I 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. :)
« Last Edit: January 22, 2016, 04:27:51 am by coppice »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #92 on: January 22, 2016, 01:58:54 pm »
I'll do precisely this tonight. For fun, I will _video_ the result,

XFDDesign, 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.
================================
https://dannyelectronics.wordpress.com/
 

Offline benSTmaxTopic starter

  • Regular Contributor
  • *
  • Posts: 87
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #93 on: January 22, 2016, 08:37:24 pm »
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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #94 on: January 22, 2016, 08:43:51 pm »
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1666
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #95 on: January 22, 2016, 10:10:20 pm »
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.

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.
Complexity is the number-one enemy of high-quality code.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #96 on: January 23, 2016, 11:03:53 pm »
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.

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?
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #97 on: January 23, 2016, 11:08:18 pm »
Quote
I'd rather take the time to write my own. Then I know it's done right.

On 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.
================================
https://dannyelectronics.wordpress.com/
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26761
  • Country: nl
    • NCT Developments
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #98 on: January 23, 2016, 11:59:48 pm »
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.

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?
Usually 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #99 on: January 24, 2016, 12:29:24 am »
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.

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?
Usually 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.

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

« Last Edit: January 24, 2016, 12:31:11 am by Howardlong »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf