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

0 Members and 1 Guest are viewing this topic.

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #50 on: January 18, 2016, 04:17:23 pm »
@XFDDesign: You are not making a strong case for your abilities to figure something out.  >:D There are so many tutorials out there to get an ARM microcontroller going...

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



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

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

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

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

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

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

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

« Last Edit: January 18, 2016, 04:19:34 pm by XFDDesign »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #51 on: January 18, 2016, 04:45:22 pm »
Quote
get rather silent about getting code in on a final design.

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

Quote
I don't have the coin to drop on Keil,

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

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #52 on: January 18, 2016, 04:58:07 pm »
Quote
get rather silent about getting code in on a final design.

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


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


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

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

Quote
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.
Aye, 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.
« Last Edit: January 18, 2016, 05:01:11 pm by XFDDesign »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #53 on: January 18, 2016, 05:16:36 pm »
Quote
what I recall from reading, stlink was wrapped around some required supporting hardware that was on the eval board.

You may want to re-read it.

Quote
It was such a disorganized shitstorm of a mess,

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

================================
https://dannyelectronics.wordpress.com/
 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #54 on: January 18, 2016, 05:27:34 pm »

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

Ok, 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 to www.geico.com
3. 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).
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #55 on: January 18, 2016, 05:30:15 pm »
@XFDDesign: You are not making a strong case for your abilities to figure something out.  >:D There are so many tutorials out there to get an ARM microcontroller going...

There 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."
Don'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.
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 #56 on: January 18, 2016, 05:47:05 pm »
Quote
Please show me the idiot I am, by expressing ...

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

Quote
with the PIC32 to further show how easy it actually is

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

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #57 on: January 18, 2016, 05:54:25 pm »
Don'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.

If we're not twisting words, you wrote, "You are not making a strong case for your abilities to figure something out.  >:D 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.


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

I 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
Please show me the idiot I am, by expressing ...

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

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

Quote
That's simply because the PIC32 has simple peripherals.
And that isn't actually a refutation of anything, let alone the post I made which got this derail going.

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

Not 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.
Quote
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.

You mean exactly like 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.
« Last Edit: January 18, 2016, 05:57:19 pm by XFDDesign »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #58 on: January 18, 2016, 06:09:26 pm »
Quote
It's like a club of Ferrari drivers looking down and asking why people who want to buy a Ford or Toyota even bother;

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

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #59 on: January 18, 2016, 06:10:34 pm »
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.
  • Install GCC (free)
  • Install Eclipse (free)
  • Install the GNU ARM Eclipse plugin (free)
  • Install OpenOCD
  • In Eclipse, download the STM32F0xx_DFP pack
  • Use 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 script
  • Build & go!

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #60 on: January 18, 2016, 06:19:22 pm »
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.
  • Install GCC (free)
  • Install Eclipse (free)
  • Install the GNU ARM Eclipse plugin (free)
  • Install OpenOCD
  • In Eclipse, download the STM32F0xx_DFP pack
  • Use 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 script
  • Build & go!

If 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
It's like a club of Ferrari drivers looking down and asking why people who want to buy a Ford or Toyota even bother;

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

"Stop being poor" is not cheering one on.
« Last Edit: January 18, 2016, 06:22:31 pm by XFDDesign »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #61 on: January 18, 2016, 06:30:00 pm »
If 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.
Thanks, but I'm not a beer drinker. Download GCC from here, and if you're on Windows, download OpenOCD from here. 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 also documented the process.

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #62 on: January 18, 2016, 06:32:12 pm »
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.
  • Install GCC (free)
  • Install Eclipse (free)
  • Install the GNU ARM Eclipse plugin (free)
  • Install OpenOCD
  • In Eclipse, download the STM32F0xx_DFP pack
  • Use 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 script
  • Build & go!

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

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #63 on: January 18, 2016, 06:36:51 pm »

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

$500 for the pro version is completely within reason. Thanks for pointing this one out.

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #64 on: January 18, 2016, 06:59:32 pm »
"Stop being poor" is not cheering one on.
All 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)!
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 #65 on: January 18, 2016, 07:07:15 pm »
Quote
"Stop being poor" is not cheering one on.

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

Quote
For fun, I will _video_ the result,

That's a very good way to help others identify the issues that have prevented you from programming ARM chips.

Quote
but I predict there will be a problem in doing so:

Sounds like you are very afraid of being successful at programming ARM chips.
================================
https://dannyelectronics.wordpress.com/
 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #66 on: January 19, 2016, 02:37:56 am »
Quote
"Stop being poor" is not cheering one on.

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

You 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.
Quote
Quote
For fun, I will _video_ the result,

That's a very good way to help others identify the issues that have prevented you from programming ARM chips.

Quote
but I predict there will be a problem in doing so:

Sounds like you are very afraid of being successful at programming ARM chips.
See 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.

"Stop being poor" is not cheering one on.
All 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)!

Aye, 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 would love an Atom).
« Last Edit: January 19, 2016, 02:58:48 am by XFDDesign »
 

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 #67 on: January 19, 2016, 04:45:23 am »
@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.
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 #68 on: January 19, 2016, 08:03:37 am »

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

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

 

Offline nctnico

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

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #70 on: January 19, 2016, 09:41:01 am »
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!
Bob
"All you said is just a bunch of opinions."
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #71 on: January 19, 2016, 11:19:11 am »
But to say that ARM lacks cheap tools or is difficult to get into is complete BS!

Your strong arguments convinced me completely. I'll immediately drop the pics in favor of arm.
 

Offline dannyf

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

Offline Howardlong

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

Which 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!
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Microchip to acquire Atmel - how do you feel about this?
« Reply #74 on: January 19, 2016, 01:02:36 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf