EEVblog® Electronics Community Forum
General => General Technical Chat => Topic started by: VK3DRB on October 03, 2016, 12:09:50 pm
-
I used to use the trusty old MPLAB, but today I needed to develop code for the new 16F18323, which is a very nice chip feature-wise, for low cost 8 bit micro. MPLAB does not seem to support it, but MPLAB X does. So I installed MPLAB X - bloatware extraordinaire, almost as bloated as Atmel's Studio 7. I used the MPLAB XC8 compiler and their graphical code wizard addon.
MPLAB XC8 compiler (or the IDE) had this bug with this line in main():
getch(); // No problems compiling
char ch = getch(); // Blows up with a 712 "can't generate code for this expression" error.
Nothing wrong with the function or prototype char getch(void); which was created by the Graphical Code Generator to get a character from a EUSART receive character interrupt.
I wasted at least a couple of hours trying to work out what was wrong. Search the Internet. Nothing particular. Paths maybe? Restarting the program does nothing. I eventually reboot the PC for another reason. Voila! Problem gone. What crap. So what more bugs are there? I feel like swapping to the more expensive pin-compatible 16F1823 just to get the job done under MPLAB 8.
As bloated as Atmel Studio 7 is, it seems pretty robust and has some nice features. I compiled a fairly complicated piece of code for an Atmel ATxmega128A1 and it worked fine. That IDE is bigger than Texas. Why does a C code environment need a Microsoft based spell checker that is built in? In any case, it appears they have done a reasonable job, except for the bloat.
The king of bloatware compilers is Microsoft's Visual Studio Community Edition, installed over old Visual Studio versions. It's a Community Edition alright, a community of bugs you can't kill. What a bloody mess. Uninstall everything. Clean the registry. Different bugs. Lather. Rinse. Repeat. Still dirty. After a day of stuffing around, install on another machine - it works. Maybe Weird Al Yankovic can do a video on Visual Studio I'm Fat Edition.
I think decent companies (that excludes Microsoft for a start) should adopt the paradigm of KISS (Keep It Simple, Stupid). Instead they try to be all things to all people in one bloated package. That is why I liked the old MPLAB. It just bloody worked.
OK, they are "free" except for the time wasted. Should I quit complaining because these IDE's/compilers are free and not properly tested, ie: use at your own peril? Or should we expect more, because we are buying their chips and using the compiler to sell more of their product? Not sure what paradigm to use, but I dislike all the glitz, glamour, adverts, and "Where do you want to go to today" bloatware. I just want a tight, efficient, fast and easy to use, and above all, reliable compiler, using for example Notepad++ and/or Eclipse for the editor. Am I asking too much? Have these companies lost the plot, or am I just getting old and grumpy?
-
I spent ten years in front of Visual Studio with stupid large solutions (2-8 million lines of C#/C++). I spend most of my time in front of Vim now. I couldn't agree more with your assertions. I've gone from 10-20 crashes/showstopping bugs a day to perhaps 1 every couple of months now.
The stupid thing is the entire VS IDE is still only a 32-bit binary so it can't address more than a couple of GiB of RAM. This causes it to destroy itself occasionally. Then when you install things like Resharper, wham it won't even open a large project without crashing.
Unix/Linux is an IDE. tmux is the window manager. vim is the editor. make/gcc is the build toolchain. python is the scripting language. bash is the glue. Everything existing apart yet working in complete unity.
-
May the powers that be hear your voice.
This is what you get when a generation of programmers who had no choice but to write high-performance code exits the stage and is replaced by a pack of clowns raised on Java. Once upon a time, high-performance code was the only kind that worked, because hardware was so feeble. I'm not blaming young programmers as a group, those at the top are as brilliant as those of yesteryear. However, it's clear that the number of people writing code has exploded, and there is a lower barrier for entry.
On top of that you can add the effects of test-driven development, which works for a good team but will not make a bad one better. Who tests the tests? They are often written by the same people who write the code, leaving them prone to the same thought errors, and resulting in bugs merely being shifted out of the code proper into the test harness. These problems can be dealt with in a good team, but the test-driven framework is often worshipped and seen as a guarantee of correctness.
The problems with bad code at Microsoft in particular are well documented by former employees who complained of a culture hell-bent on new features, and that actually rewarded inventive circumventions of bugs more than fixing the bugs themselves.
Try profiling one of these bloatware applications and watch it spend most of its time doing method dispatching.
-
As someone who has jousted with the 800 line Java stack trace a few times in my years, hell yes to all of that.
-
Just tested this on XC8 version 1.38 on OS X (with the required processor) and it works ok:
char getchar(){
return 'a';
};
int main()
{
char c=getchar();
return 0;
}
So, is the error somewhere else?
P.S.: I also don't like HUGE IDEs.
-
Once apon a time I thought VB6 was bloat ware...
What drives me mad with MS is they only listen/hear the people who live and breath software development and attend all their events, in search of the latest new (unfinished) technology to play with.
In reality the bulk of development is maintaining large existing systems, which are too large and complex to rewrite every time they abandon a technology for the new flavor of the day.
-
I too have seen occasional XC8 bizarreness like this, often in seemingly benign scenarios, but it's the exception rather than the rule. I can't ever remember a reboot or restart fixing it though.
XC8 does work in MPLAB 8.92, even the current 1.38, but the old IDE doesn't know anything about the relatively new PIC183xx series, which generally puts it off-limits.
Regarding the blight of bloatware IDEs, I totally agree that there's a correlation between those written using managed language/framework combos such as Java and C# and general slowness, and general lack of care over machine resource usage. I am not sure how much of this is due to the framework itself, and how much is due to the libraries themselves, and a lack of understanding how those libraries use resources.
There are also silly things in the design of MPLAB X and Netbeans themselves, which insists on parsing everything under the sun, and doesn't deem to be possible to turn it off. As soon as you load up a fairly minimal (!) Harmony app, unless you're using a reasonably pokey machine you'll be suffering from a general lack of responsiveness and excessive CPU use.
However, if I may, if you ever had the misfortune to run Microsoft's Programmer's Workbench (PWB) IDE back around 1990, all can be forgiven. This was an attempt to answer Borland's IDEs (which had an extremely good reputation among developers), and has to be the worst one I've ever used, it was almost unusable it was so slow, I mean really slow.
-
Regarding the blight of bloatware IDEs, I totally agree that there's a correlation between those written using managed language/framework combos such as Java and C# and general slowness, and general lack of care over machine resource usage. I am not sure how much of this is due to the framework itself, and how much is due to the libraries themselves, and a lack of understanding how those libraries use resources.
All of the above. Primarily grounded in the sheer headroom these platforms give you with the crazy high performance and maintainability but only up to a point. When you hit the wall, the complexity takes you down.
-
I too have seen occasional XC8 bizarreness like this, often in seemingly benign scenarios, but it's the exception rather than the rule. I can't ever remember a reboot or restart fixing it though.
XC8 does work in MPLAB 8.92, even the current 1.38, but the old IDE doesn't know anything about the relatively new PIC183xx series, which generally puts it off-limits.
Regarding the blight of bloatware IDEs, I totally agree that there's a correlation between those written using managed language/framework combos such as Java and C# and general slowness, and general lack of care over machine resource usage. I am not sure how much of this is due to the framework itself, and how much is due to the libraries themselves, and a lack of understanding how those libraries use resources.
There are also silly things in the design of MPLAB X and Netbeans themselves, which insists on parsing everything under the sun, and doesn't deem to be possible to turn it off. As soon as you load up a fairly minimal (!) Harmony app, unless you're using a reasonably pokey machine you'll be suffering from a general lack of responsiveness and excessive CPU use.
However, if I may, if you ever had the misfortune to run Microsoft's Programmer's Workbench (PWB) IDE back around 1990, all can be forgiven. This was an attempt to answer Borland's IDEs (which had an extremely good reputation among developers), and has to be the worst one I've ever used, it was almost unusable it was so slow, I mean really slow.
For similar parts it is possible to tweak things to make MPLAB 8.92 work with them.
I have a feeling that addding actual new parts is hard but you can tweak definitions of other parts you don't use, e.g. I added PIC32MX170 support which my MPLAB thinks is a 32MX150F128C
From memory think it just involved tweaking the default XC32 linker file to addd the extra memory, and a file that tells MPLAB the device ID fpr programming
I also hate big IDEs - by all means have stuff you can install later if you want, but just include the basics in the default setup, and don't insisty I bury everything in gazillions of folders.
-
As someone who has jousted with the 800 line Java stack trace a few times in my years, hell yes to all of that.
OMG, I must have only been a squire, I jousted with mere ~90 line call stacks. After a while you learn where to look though.
I really like VS very very few crashes :-+, also like Eclipse :-+ but was fighting XC8 and MPLab whatever today, it's a bit more primitive, and you get that insane message about the Omniscient Code Generation, WTF is that?
-
I spend most of my time in front of Vim now.
Another vote for Vim + command line tools.
Vim is also quite interesting in that it has a bunch of cool plugins out there, which you can install if you want them. In addition to the syntax highlighting built in, syntastic will check your code's syntax in a bunch of language, youcompleteme, for autocompletion, various beautifiers, git-wrappers like fugitive, etc. I'm really happy with the ecosystem, and if any of that vim add-on crap bugs me, I turn it off and keep working.
-
"MPLAB XC8 compiler (or the IDE) had this bug with this line in main():"
Your experience is quite common. Apparently finding bugs iss quite easy, especially with novice programmers.
-
I am always hesitant about installing a chip company's IDE (after getting burnt many times in the past), but PSoC Creator has been a very pleasant surprise. It starts quickly, works quickly and has never crashed on me. It's easy to use and well laid out. I like it a lot.
The absolute worst for me is Code Composer Studio (more like Crapy Compost Shit amirite), which is a 20+GB abomination! It's a Java based pile of trash. Wrestling with it makes me so angry... If it were a person, I'd make a Human Centipede out of it (with Visual Studio being the front; then I'd force feed VS spicy Mexican food and laxatives). That's the kind of hell CCS deserves.
Fuck CCS.
-
saves tons of cost and time compared to developing your own IDE from scratch
no need to worry too much about that: people who talk a lot about developing their own IDEs from scratch are generally those who are least capable of developing their own IDEs.
-
Those who wrote the MPLAB Code Configuator obviously have never tested it properly. The code generated for adc.c is blank, even if there are no warnings.
Anyone who has used the CodeVision/AVR will know its code wizard is superb. It sets all the registers and comments the lines beautifully. It written by a Romanian for whom English is not his first language. One bloke who created a great compiler. Compared to CodeVision/AVR this MPLAB Code Configurator is crap. Unfortunately CodeVision is for AVR's, not PICs.
STOP PRESS: I found the root cause of the problem: I used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.
-
So, is the error somewhere else?
He said he rebooted and the error went away.
therefore isolating the the problem to a bug infested bloated OS not the compiler :P
-
STOP PRESS: I found the root cause of the problem: I used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.
It is not clear (to me) how this would not work and then work on either side of a reboot.
Probably a registry issue with the program. I am going ahead with the MPLAB X with its bugs because I want to use the steerable PWM features that 16F18323 chip has over the PIC16F1823. Plus the 18323 is about 20 cents cheaper than the 1823 for this mildly cost sensitive project.
Found another bug in MPLAB X. Clicked on refactor a function name. Refactoring slider came up as 50% done and hanged the program. CTRL-ALT-DEL again. At least it saved everything from the previous recompile.
-
For similar parts it is possible to tweak things to make MPLAB 8.92 work with them.
I have a feeling that addding actual new parts is hard but you can tweak definitions of other parts you don't use, e.g. I added PIC32MX170 support which my MPLAB thinks is a 32MX150F128C
From memory think it just involved tweaking the default XC32 linker file to addd the extra memory, and a file that tells MPLAB the device ID fpr programming
I did the exact same thing for the MX270, worked a treat.
I did look into doing a similar trick for the 16F183xx series, but ISTR when I looked at the programming protocols they were different enough to other supported devices that I considered it not reasonably feasible to come up with a hack to use with MPLAB 8, but ISTBC.
-
2,79 GB is bigger than Texas?
Used vim+cmd, changed a long time ago to the AS6 and now 7, and I would rather spend my time with AS6 than using vim and 100 different cmd tools to have the same things..
I hate Eclipse based crap though..
And with ssd's so cheap right now, putting the base OS and the most used programs in one is a good idea.
-
I hate Eclipse based crap though..
Eclipse has a major problem dealing with large multi-file projects when refactoring. It loses the plot where if for example you have a function name, constant or variable used in, say a few hundred places, Eclipse will on occasion refactor some and not others. You only find out if it stuffed up on recompiling. Worse still, if on the odd chance you wanted to swap identifiers, your project might be screwed up and your have to do a revert using SVN or whatever. But Eclipse free. Use at own risk.
What is not acceptable is Altium charging for bug fixes via a subscription. You pay $10K, bugs are thrown in for free and you have to keep on paying subscriptions to get them fixed. A bad business model that cheeses customers off. For ten grand, bug fixes should be free forever and you only pay for upgrades that have new features.
-
STOP PRESS: I found the root cause of the problem: I used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.
I'm not at all surprised. TBH, in the end MCC is rarely worth the hassle. At the end of the day you _have_ to understand your peripherals to a reasonable level at the hardware and register level anyway, so the value of MCC is limited.
Here are my reasons _not_ to use MCC, in no particular order:
o Strait-jacketed code organisation;
o Bugs;
o Missing peripheral functionality;
o Lack of forward and backward compatibility between MCC releases;
o Over-complex, jack-of-all-trades drivers (e.g., I2C);
o Difficulty of maintaining your own code inside its machine generated code (you're continually at risk of it over-writing your code);
o You spend more time debugging MCC generated code than if you'd written your own;
o Even the simplest project creates multiple source files, making it very difficult to narrow down anomalies to small succinct self-contained reproducible code snippets - as we have found here!
o Generates bulk peripheral SFR assignment code with comments, but doesn't separate them out into a field-by-field human-readable result;
o You still need to understand how the peripherals work!
Reason to use MCC:
o Possibly marginally quicker to get very very basic prototypes working once you've learned how to use it.
In general, any code generator you should use at your own risk, and take time to understand its limitations. While a few, like Visual Studio's Visual C++ forms code generator, work reasonably well, those that do work well also properly manage to differentiate between machine and developer generated code. The same cannot be said for MCC.
-
STOP PRESS: I found the root cause of the problem: I used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.
It is not clear (to me) how this would not work and then work on either side of a reboot.
Probably a registry issue with the program. I am going ahead with the MPLAB X with its bugs because I want to use the steerable PWM features that 16F18323 chip has over the PIC16F1823. Plus the 18323 is about 20 cents cheaper than the 1823 for this mildly cost sensitive project.
Found another bug in MPLAB X. Clicked on refactor a function name. Refactoring slider came up as 50% done and hanged the program. CTRL-ALT-DEL again. At least it saved everything from the previous recompile.
maybe something is wrong with your computer?
I've been using X since it came out, on different machines and different OS. Every time a new version introduced stupid bugs that required you to reboot the application a newer version came out a couple of days later that addressed the problem.
Despite some idiocies that were never addressed, i like it far more than the old mplab (that by the way needs a to be rebooted frequently here)
-
Part of the issue with what is seen as bloat is to maintain backwards compatibility. C++ is a prime example of this, they try very hard with both the language and compilers to never break old code. So if there was a stupid screwy way of doing something in 1989 it will never go away, hence you still have guys writing C++ code like they would have in 1989 so the language specs and compilers have to handle all that old cruft.
Specific to Microchip, they have what 500ish current part numbers, with multiple versions, plus discontinued parts still supported, each of those probably has at least ten work-arounds for silicone bugs, so you have an enormous number unique parts they are trying to support, and work around silicone bugs which becomes an even more enormous problem as time goes on. Given that there will be software bugs as well in the development tools you have a real mess. I'm sure someone can lash together some other tool set that works great for them on a limited series of parts but pales in comparison to what the factory dev tool support.
-
Part of the issue with what is seen as bloat is to maintain backwards compatibility. C++ is a prime example of this, they try very hard with both the language and compilers to never break old code. So if there was a stupid screwy way of doing something in 1989 it will never go away, hence you still have guys writing C++ code like they would have in 1989 so the language specs and compilers have to handle all that old cruft.
Specific to Microchip, they have what 500ish current part numbers, with multiple versions, plus discontinued parts still supported, each of those probably has at least ten work-arounds for silicone bugs, so you have an enormous number unique parts they are trying to support, and work around silicone bugs which becomes an even more enormous problem as time goes on. Given that there will be software bugs as well in the development tools you have a real mess. I'm sure someone can lash together some other tool set that works great for them on a limited series of parts but pales in comparison to what the factory dev tool support.
I'm not sure I agree: MPLAB X has always been a dog, even when it was supported at the same time as MPLAB 8.x. Just compare the compile times, load times, debugger/programmer communication times, for examples off the top of my head. It's the same compiler, just to shell out from Java is extraordinarily slow compared to the native code MPLAB 8.
I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.
-
MPLAB X has always been a dog, even when it was supported at the same time as MPLAB 8.x. Just compare the compile times, load times, debugger/programmer communication times, for examples off the top of my head. It's the same compiler, just to shell out from Java is extraordinarily slow compared to the native code MPLAB 8.
1.) Compile times can be longer because of the licence check Microchip built in into GCC.
Some people noticed improved compile times when replacing the license check binary with a simple executable that returns immediately.
This is easy to do with the information somewhere else on this forum.
2.) Startup time of the IDE is 16 seconds (no SSD). I find this acceptable for a program that I usually start once a day.
3.) Programmer communication time is long with the PK3. With the ICD3 it's much better. Only when you change the target, new firmware will be loaded which takes some extra time.
I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.
People who don't understand the concept of pointers to pointers aren't programmers...
-
I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.
No, that's not the reason. Most objects in Java & C# are referenced by pointers, you just don't explicitly see the pointer in the language. In other words, if you pass an object to a function, only a pointer is actually copied.
There are various other reasons that Java & C# can be slower than C & C++. In my experience, the biggest slowdowns come from (1) huge class libraries that cause slow startup times and memory hogging, and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it? :--
-
... and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it?
Unfortunately, efficient programming costs more time & money than upgrading to a faster cpu & more memory.
-
"500ish current part numbers,"
That's microchips biggest asset and it's biggest liability at the same time.
I suspect they make far more margins on those parts than on new parts. So a cash cow.
Because off that, they are very reluctant to venture into newer technology that may risk the cash cow. Killing themselves slowly over the long term.
-
I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.
No, that's not the reason. Most objects in Java & C# are referenced by pointers, you just don't explicitly see the pointer in the language. In other words, if you pass an object to a function, only a pointer is actually copied.
There are various other reasons that Java & C# can be slower than C & C++. In my experience, the biggest slowdowns come from (1) huge class libraries that cause slow startup times and memory hogging, and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it? :--
i don't strange if every class have several subclasses inherited , plus properties that can be shared with other classes part to the main , adding that the method of the classes that too can be shared with others classes.
On resume , with the new programming paradigm you have a mess worse that gordian knot, and for this motive many programmer that when they have to modify a java application , the form more easiest is remaking since zero
-
... and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it?
Unfortunately, efficient programming costs more time & money than upgrading to a faster cpu & more memory.
Indeed, if you're developing for one person. If you're developing for 10,000, not so much.
But I do agree with your general views.
-
2.) Startup time of the IDE is 16 seconds (no SSD). I find this acceptable for a program that I usually start once a day.
Startup is under 10 seconds for me and I'm on a little old laptop that I paid $200 for so if its slower than that something is wrong with your OS.
-
... and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it?
Unfortunately, efficient programming costs more time & money than upgrading to a faster cpu & more memory.
Yes and no. That approach works fine if you ship your code to an end user as you distribute the load away from what costs you money. If you own your infrastructure, rent it from Amazon/Google etc or have a monolithic black box somewhere in your architecture, this never adds up to a viable approach. There's a wall and it gets way more expensive than programmer time at a point in the future because you need to spend the cash right up front to climb over it. Programmers increase linearly. Infrastructure capacity/scale, not so much. Unfortunately balancing this and feature creep is one of my many hats.
-
Indeed, if you're developing for one person. If you're developing for 10,000, not so much.
I don't agree. A programmer (or his boss) that develops a program for 10,000 people, doesn't care that they (the 10,000 people)
have to pay for a faster cpu & more ram.
-
There's a wall and it gets way more expensive than programmer time at a point in the future because you need to spend the cash right up front to climb over it. Programmers increase linearly. Infrastructure capacity/scale, not so much. Unfortunately balancing this and feature creep is one of my many hats.
Except, your wall analogy is not generally true.
While it is true that you have to pay up front for new and faster hardware, you immediately get the what you paid for: faster performance. Whereas with software development, the costs accumulate over time until the desired optimization is ready for release, but you also have to wait for that long until you can benefit from it. As the saying goes: time IS money...
-
Indeed, if you're developing for one person. If you're developing for 10,000, not so much.
I don't agree. A programmer (or his boss) that develops a program for 10,000 people, doesn't care that they (the 10,000 people)
have to pay for a faster cpu & more ram.
Nothing to do with caring or not - simple business.
If you're shipping 10K units, you can spend up to slightly less than $10K on work that saves $1 per unit
-
There's a wall and it gets way more expensive than programmer time at a point in the future because you need to spend the cash right up front to climb over it. Programmers increase linearly. Infrastructure capacity/scale, not so much. Unfortunately balancing this and feature creep is one of my many hats.
Except, your wall analogy is not generally true.
While it is true that you have to pay up front for new and faster hardware, you immediately get the what you paid for: faster performance. Whereas with software development, the costs accumulate over time until the desired optimization is ready for release, but you also have to wait for that long until you can benefit from it. As the saying goes: time IS money...
I disagree. Hardware only goes so far. When you have to pay for a cluster of two active-active 48 core E7 Xeons with 1024Gb of RAM, associated enterprise SSDs and then the SQL Server license for it because you hit that wall you will understand what I mean by hardware cost.
My point is performance management is a continual process that you need to factor into every feature or architectural change.
-
I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.
I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.
Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.
Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.
-
For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.
Depends on what sort of stuff you're doing - ICD3 is definitely way faster for larger parts, but PK3 works just fine for smaller ones, and is more tolerant to abuse - IME ICD3 can get itself into wierd states that sometimes need exiting and restarting MPLAB to recover. I usually use PK3 on small 8-bit parts - there was definitely a good reason for this that I found years ago, but I've long since forgotten exactly what it was & don't know if it's even still an issue.
Even if you have an ICD3, you certainly should also have a PK3, partly as a backup, but also for the programmer-to-go function which is very handy if you have more than a few boards to program.
-
I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.
I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.
Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.
Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.
I understand the justification but I genuinely wish people didn't use this approach. We have a massive problem where someone writes some code on their Cray sized workstation and doesn't understand that it has to execute in under 50ms when it hits production on something with less wumph, more load, higher concurrency and less per thread heap. The tool bloat contributes to this problem because the supporting software runs like shit on even the best of kit so you have to do the yearly upgrade treadmill. And thus disparity between reality and the development team increases.
Typical comparison:
Dev: high end i7 8 cores, 32Gb of RAM, m2 SSD.
Prod: 1/16th of an E5 Xeon core which is virtualized, 77Mb of RAM, SAS 10K disk.
-
I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.
I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.
Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.
Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.
sometimes you just have to.
a lot of accounting and government software will not work with something newer than win2k or XP (i think it has something to do with the hardware license) or with newer version of software.
some manager in politics decided that PA here is forced to use open source crap like openoffice 1.5 and no updates because of some custom plugins that were never updated by the software house. this is true nightmare, my mother is adamantine on not wanting them to upgrade her pc to a new one because on her old she is still allowed to use office 2000 and get at least some work done
my point being, you aren't always allowed to upgrade
-
Not so simple for Public Administration (PA). There is a policy they have to keep. Those in change of determining the policy seem not to be able to look at the data on how many times higher the downtime and the cost for manteinance is, compared to a windows pc
It's already a miracle they didn't force them to use older ubuntu, and boy if they tried
-
I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.
I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.
Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.
Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.
I understand the justification but I genuinely wish people didn't use this approach. We have a massive problem where someone writes some code on their Cray sized workstation and doesn't understand that it has to execute in under 50ms when it hits production on something with less wumph, more load, higher concurrency and less per thread heap. The tool bloat contributes to this problem because the supporting software runs like shit on even the best of kit so you have to do the yearly upgrade treadmill. And thus disparity between reality and the development team increases.
Typical comparison:
Dev: high end i7 8 cores, 32Gb of RAM, m2 SSD.
Prod: 1/16th of an E5 Xeon core which is virtualized, 77Mb of RAM, SAS 10K disk.
There's a major difference between using a powerful PC to write PC applications, and, what we are mostly talking about here, using it for a cross-compiling tool, where the power of the PC has no bearing on the performance of the final application, other than reducing development time.
A similar situation to the "powerful PC to develop PC apps" scenario can often be seen with websites, where they clearly have a fast low-latency connection for their own development and testing, but the actual experience on a normal connection sucks.
-
Libre and OO work like a charm now. Past verion didn't.
1.5 was total shit but they can't update to new versions because of custom plugins that won't be upgraded
Same with java 6
Same with most software they use
-
If you are writing code for one person or 10,000 people, efficient code should always be an aim, based upon pride in doing a good job. Actually more important than that is well written, well structured, well commented and well documented code. Like laying out a PCB should be considered artwork, so should writing code.
-
If you are writing code for one person or 10,000 people, efficient code should always be an aim, ...
Keep on dreaming. In the real world where time is money and deadlines are set, (almost) nobody cares.
-
Unfortunately some of us are paid to supervise a team of people who don't care and that's where it gets all :scared:
-
If you are writing code for one person or 10,000 people, efficient code should always be an aim, ...
Keep on dreaming. In the real world where time is money and deadlines are set, (almost) nobody cares.
I didn't say THE aim. I said AN aim. From what I have seen, most shoddy work is usually fuelled by laziness. Time and money are important, but I know of an idiot who runs a small business with a "whatever is cheapest" attitude. He has lost hundreds of thousands of dollars - possibly a half a million dollars or more - through false economy and not listening to his employees. Intelligent and successful people realise the importance of investment in good compilers, good tools and good people.