EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: sonicj on December 31, 2010, 12:22:12 am
-
It won't write your program for you (bummer huh?), but it WILL write all of your tedious setup code which is a good chunk (if not the bulk) of the learning curve. Purdy slick imo!
http://www.kaltura.com/index.php/kwidget/wid/1_7bjoamkb/uiconf_id/2342281
-
Several other manufacturers have done this - bit of a gimmick IMO and encourages laziness that can bite you later when some subtle aspect is overlooked - there is no substitute for taking the time to RTFDS.
-
even those who are committed to learning as much as possible can easily become overwhelmed, confused &/or frustrated by trying to comprehend all of the information required to properly setup a µC. i certainly understand how this can been seen as a crutch or laziness by those who have committed years to the craft, but not everyone has that kind of time or patience to dedicate towards exploring micro controllers.
as a n0ob myself, i often know exactly what it is i want the µC to do, i understand the basic principles of whats needed to make it happen, but lack the deeper knowledge of how to get there. having a graphical guide to aid in the setup process helps bridge the gap between reading about something in a data sheet and making it happen in my application. it still requires a understanding of whats taking place to configure the µC and the utility even offers explanations for each setting option with links for further reading. imo, its much like going through the data sheet but in a graphical, intuitive manner. some people can easily learn from reading text books, while others comprehend things best hands on.
personally, i would much rather debug a overlooked setup error later down the road and have a mostly working project than be stuck with a mess of code, increased blood pressure, a set of data sheets and nothing else to show for it. obviously, there is no replacement for years of hard work and experience, but for those of us faced with the steep entry fee into the world of programming µC's, being able to focus on the application code knowing you have a properly configured clean slate is a godsend!
-sj
-
This is pretty cool. I'm going to give it a try with my next project.
-
To say the least, it's buggy. I was unable to get it to install and work. The install went fine, but it doesn't actually show up when I fallow the steps to create a Grace enabled project.
Targeted to the launchpad users and according to the Wiki it only support the value line and the MSP430F2274 at the moment.
-
my install failed on 2 separate machines. turns out i needed to install a dependency, XDCtools or something like that.
heres the info that got me going:
http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/82973.aspx (http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/82973.aspx)
its actually quite painless once you do it few times. warning, you might old and grey by the time the install finishes! ::)
-
I installed the XDC tools fine. If I try to install new features now, I get a 'network error' and it complains about site.xml.
Somebody else mentioned they had to uninstall and reinstall CCS twice before it finally worked. I'll try that later.
-
wow, that sucks...
now that i think about it, i might have had to uninstall CCS on the laptop before it would go. i think i possibly had a older version. the desktop with virgin ccs install added grace & xcd tools without issue.
-sj
-
Boring, really boring.
Every other year someone or some company comes out with some general-purpose graphical development tool for some platform or MCU. And guess what? Every single one of them failed during the last few decades. What survives from time to time are special-purpose tools (e.g. LabView) as opposite to general-purpose tools.
Why do the general-purpose ones fail? It is always the same. The authors always think they have invented the best thing since sliced bread. While in reality they just do a rehearsal. A rehearsal of a bad idea, because drawing is slower, inflexible and more hassle than typing code. A second thing is, these tools are always of low quality. In their rush to monetize their "great" idea they hire rubbish programmers (or are anyhow rubbish programmers), and typically deliver broken software - buggy, incomplete, slow, inflexible, a pain to operate. What they deliver is a promise of a better world, but the better world is never delivered, just the promise.
The authors have no clue about their target market. Experienced programmers don't need this. So some authors have the idea to market it to the stupid ones. You know, those who always shout "awesome" when they see a blinking LED, and to stupid managers, of course. The trouble is, that while "being stupid" is a general trend and fashionable in society, it still isn't fashionable in programming. There aren't many programmers who are stupid an have money at the same time (Bill Gates being the greatest exception). In programming, the ones with the money aren't stupid, but the stupid ones don't have money. The stupid ones rather steal your software than paying for it.
I have a message for all these "graphical programmers" out there. Don't become a programmer if you hate writing code. It is really that simple. No tool in the world will fix your incompetence and make you a good programmer if you hate writing code.
-
I don't believe this is meant as a graphical programmer as it is a menu'ed peripheral setup tool. It simply sets all of the registers correctly for your specifications. It's an extension of the peripheral libraries that many uC manufacturers are distributing with their uC's now-a-days.
-
i will build my own graphic library when i got a project for this. which i did for general library for atmel and pic so i dont have to code the setup/config bit/errata everytime i make a project/program. i dont want to be dependent on other people's bugs. i'd rather spending my time coding than waiting for the developers to fix/update their library which could take months or years. anyway, i believe the guy in the video was the one who intro the msp430 last time. he looks like a jerk to me.
-
More than code generation, maybe (if there was one) a graphical tool for design: choosing the right MCU, assigning pin functions (better if leaving you the freedom of annotating at your own taste), and verifying peripheral conflicts could be helpful for documentation too, IMHO.
Then, if it helps you writing the right values into the registers, why not? You can always verify on the datasheet...