Here I sit alone at home in Timbuktu...what is the hell is these guys
talking about...I just wanted to run this thing in the brand new software I
got and this test project was downloaded with it?
Should I swear him? Agg lets just leave it.
This was my introduction to Microchip...and I am convinced it is the same
for all.
So...
Suggestion / Question 1:
Why is version control and standards control not
implemented? Microchip information is all over the show and what makes it
more frustrating is all the versions has no indication of what belongs where
- so for one starting out with Microchip, I promise you, more than 80% just
give up.
Keep every series in its own, Every version to its own, and every PIC
series to its own. And the engine for production on its own.
Why? Because I nearly gave up...the only thing that kept me
going is the big big dream I have and my inexplicable commitment to the PIC.
Strange hey.
Suggestion / Question 2:
I can't help but to ask the question: Is the C standard more important
then the Microchip "customer strategy " for their chip sets, especially considering
going into production?
Example: Instead
of having these PIC common headers that continuously call a series of obscure
header and defines / ndefines, and I realise it is driven by some good
intention. Come up with a plan to manage these "standards changes" better.
My suggestion (because I prefer simplicity):- Have a library
of EACH CHIP (all the possible headers) - separate not decided by some code
when this is true then do this...Come on a beginner knows nothing. Forget
about the path thing ...please!
My plan of simplicity was:- I kept the header in the project
file - I could do this with C18...then XC8 struck and I still don't know how
to manage the headers. Just had to go with the flow...until further notice,
Suggestion/ Question 3:
Have a production procedure available. Like a plan or procedure of
actions to ensure when the PIC will always be successful out there in the
market.
I realise that programmers have their own world to work in and they can
and have all the time and resources available to confirm they comply with
the the standards and optimisations and who knows what. Don't confuse this
with design...I am referring to good programming practice FOR THE PIC only.
A good example: You know why I gave up on Assembly? Soon as I saw Bank x,
Bank y - I don't want to reinvent the wheel. I just want to program the PIC
according to my needs and the PIC and program must look after itself in
terms of efficiency ad reliability.
As an entrepreneur - I would feel much more comfortable to use ONLY
Microchip as the resource centre on the basics on how to do things...with
the expectation that this method would be in compliance with the code...the
principle is to ensure I do the code as was tested in the factory...as a
chipset user I don't have the time or the resources to quibble about the
code and its good practice.
So please have a place that says - Please Even though I know the manual
is there
Please man,
Keep every series in its own, Every version to its own, and every Pic
series to its own. And the engine for production on its own.
It makes it complicated ...I am sure in real life even for Microchip to
follow what exactly goes on between different versions of hardware and
software.
I am also sure if one writes a program for a certain chip set having a
other versions managed by virtue of defines and n defines adds risk to any
project.
Look I know - because I have been observing this for a while now - the
attitude for the learned ones in the Microchip is to justify what is going
on...but I am sharing as a fresh - none programmer -this method makes the learning
process extremely difficult ...so much so I am sure many simply
gives up and moves on. That is a great pity because I have come to choose
Microchip as the most suited chipset for my products and I am sure having
to "move on" because of "some corporate decision" to manage resource and
information :seemingly haphazardly is the cause
of failure,...that is painful.
As I type this, you know what is the biggest challenge: What is the
"detailed: correct way to start, manage and finalise a chip set to ready for
production. 18months I spent on learning the chip, C programming and I have
not come across a "principle of best practice" for a microchip chipset.
Fair all the info is there...how to manage a watch dog timer its there
...but if you don't know ...you don't know...it would be great to learn the
chipsets on the premise of "good program principles" but there is no such
path.
I appreciate an intention to leave it in the programmers hands as
flexible as possible...Would it not be nice to have a procedure for those
who just want to use the product for what it is and if one chooses to do things
differently then it is ones prerogative.
