Hi,
When I start a PIC project, I have an idea of what I want, and choose a PIC, read the D/S and start.

Each of my projects has changed beyond any planning, to something much more complicated.

Is this how any complicated projects start, or is there a way of getting it almost right at the beginning?

The D/S get me confused, as things unfold, so I have to go back and look up 'that' section again and again, where sections pop out, only to be the wrong section.

Am I alone?
Camerart.

 

I usually ensure as best as possible the Pic has the modules I need for the task at hand. So far have been lucky, with one recent exception.
I started out with a selection and then found that I needed to look at the features of very current versions, of which I only just became aware of, in this case one where the dedicated I/O pin could be switched out during run time.
In this case it was the ability to use three different outputs in sequence for PWM control.
This also meant having to switch into MPLABX in order to program these features.
C'est la vie

 

I usually ensure as best as possible the Pic has the modules I need for the task at hand. So far have been lucky, with one recent exception.
I started out with a selection and then found that I needed to look at the features of very current versions, of which I only just became aware of, in this case one where the dedicated I/O pin could be switched out during run time.
In this case it was the ability to use three different outputs in sequence for PWM control.
This also meant having to switch into MPLABX in order to program these features.
C'est la vie

Hi M,
I recall you saying it was for CNC machines, so I pesume there's an input or other peripherals.
When choosing the PIC, dod you use Microchip/maps?

If 'say' you had a couple of peripherals, you would have a couple of D/S plus one for the PIC, so how do you work down 3x D/S, and not miss any flags, enables etc.
C

 

In the case I quoted it was not for CNC in this instance.
Once zero'd in on a selection, the data sheet/manual is used as a reference, plus Picmicro on-line help instruction for the specific module, the PPS feature in this current instance.
I rarely use the Micro/maps though.

 

In the case I quoted it was not for CNC in this instance.
Once zero'd in on a selection, the data sheet/manual is used as a reference, plus Picmicro on-line help instruction for the specific module, the PPS feature in this current instance.
I rarely use the Micro/maps though.

Hi M,
The Pic micro help looks interesting, fif a bit advanced
C

 

is there a way of getting it almost right at the beginning?

Better planning.

 

One solution is to download the datasheets, user manuals, development kit, etc. on to an iPad, tablet, or another computer and have this easily accessible, or have multiple screens on your computer.

The STM32F407 MCU reference manual is over 1700 pages long.

 

One solution is to download the datasheets, user manuals, development kit, etc. on to an iPad, tablet, or another computer and have this easily accessible, or have multiple screens on your computer.

The STM32F407 MCU reference manual is over 1700 pages long.

Hi MrC,
I did a lesser version of that.
Were you able to down all of the lists, so you only did it a minimum of times?
I have to constantly keep looking time after time, which is confusing, and the reason for this question.
C

 

Better planning.

Hi D,
This is what I did, but I had to repeatedly do it, so your version of better planning must be different from mine.

I want to know how to better plan.
C

 

I generally start with the most capable PIC of a footprint I think I need with all of the peripherals available. Then I start designing. The code and PCB. Once I get close to the end of my conceptual design of the code and see that everything will fit my PCB and space, then I would start looking at the Microchip website for parametric searches of chips that included less memory, didn't have the unnecessary peripherals in hopes of finding a cheaper chip. Sometimes, the exact minimum chip I need is not available (stocked) or it's made in such low volume that the price is actually higher than some other similar chips made in much higher volumes. Not everything related to pricing makes sense on the first glance when it comes to PICs but, knee you consider the volume efficiencies of specific chips, it make sense why a more capable chip may be cheaper.

 

Hi D,
This is what I did, but I had to repeatedly do it, so your version of better planning must be different from mine.

I want to know how to better plan.
C

"Better planning" can also be iterative with minimal effort at each iteration. It can take a very long time to memorize the 770-page manual MrC handed out, you may be better off making your first effort and iterating towards improvement on subsequent designs to approach "good enough" in a shorter time. Words like "better" are relative and usually situationally meaningless. Stick with your own process unless you uncover a convincingly different path.

 

I generally start with the most capable PIC of a footprint I think I need with all of the peripherals available. Then I start designing. The code and PCB. Once I get close to the end of my conceptual design of the code and see that everything will fit my PCB and space, then I would start looking at the Microchip website for parametric searches of chips that included less memory, didn't have the unnecessary peripherals in hopes of finding a cheaper chip. Sometimes, the exact minimum chip I need is not available (stocked) or it's made in such low volume that the price is actually higher than some other similar chips made in much higher volumes. Not everything related to pricing makes sense on the first glance when it comes to PICs but, knee you consider the volume efficiencies of specific chips, it make sense why a more capable chip may be cheaper.

Hi Mr S,
Good.
When designing the CODE, how do you 'scrape' all of the necessary registers, enables flags etc and avoid going round again and again?
C

 

Hi D,
This is what I did, but I had to repeatedly do it, so your version of better planning must be different from mine.

I want to know how to better plan.
C

There's not algorithm for good planning, but there are some common things that can help.

First, you need to clearly define what the problem is that you are trying to solve. Don't just have some vague notions of what you kinda would like to do. Get very specific. Also get very specific about what constitutes a successful solution to the problem. If you want to make an oscillator that outputs a 5 V square wave wave at 1 kHz, decide what the minimum and maximum voltages would be that would be "close enough" to 5 V to be considered good. The same for frequency. The same for duty cycle. There are other parameters that you might consider putting limits on, such as the rise and fall times.

Then think of all the ways that things might unfold in addition to how you would like them to happen. Using that oscillator example again, what if that 12 V power supply you are using ends up being 13 V, or 11 V? Are you willing to accept whatever impact that has on your circuit's performance, or do you need to perhaps add a regulator to get a good, solid, stable 9 V supply for your circuit.

What kind of load is your circuit going to see?

Do you need it to behave if the output is shorted to either the positive or the negative rail?

Envision as many adverse scenarios as you can and then decide which ones you need to take into account. It's perfectly okay to decide that you aren't going to worry about what happens if the output is shorted to the negative supply, as long as you really are willing to accept the consequences of what happens if it happens.

Decide what features you MUST have and what features you WANT to have. Once that is done, beware of feature creep.

Then decompose the problem into small enough pieces that you have a fair degree of confidence that you know how to solve each of them and sketch out what those solutions require. That will help you decide what resources your PIC needs to have. You will likely, at some point, need to brainstorm other approaches to some of the problems to figure out a way to solve them using the resources available.

 

Hi Mr S,
Good.
When designing the CODE, how do you 'scrape' all of the necessary registers, enables flags etc and avoid going round again and again?
C

They are pretty similar on all pics. The ADC setup is pretty much the same (except for resolution), interrupts are the same, etc. the pin assignments for GPIO and Lat registers are all the same as well (some have fewer or more ports and specific pins available on each port but, mostly the same concept. I don't get too worried that I have all of them, just handle the ones I need for the specific project.

 

Is this how any complicated projects start, or is there a way of getting it almost right at the beginning?

For any controller project you need to know exactly what the processing and hardware requirements are to breakdown complicated issues to solvable unit block solutions you can pick from chip specifications, and then add a large fudge factor for a first prototype. Then, you need to think about hardware, software testing requirements like test-points, led diag indicators, unit test routines, etc ... It's an endless process because you will likely never know at the beginning exactly what the final processing and hardware solutions are for a complex problem. It takes experience that you will only learns from screwing-up the first few times.

Complicated = not simple, but ultimately knowable.
Complex = not simple and never fully knowable.

 

There are also sites such as PicList for source code library's, also a few good books out there on procedures and routines that can be a adapted.

 

Hi All,
Ok.
I can see from the replies, that many of the issues I've had can be minimised by taking a bit more time before starting, and I can tell that you've all had plenty of experience.
I think that buying the later components, will perhaps have better specifications, where older ones, may have more information to search for, and there's a balance of latest v cost.
My weaknesses have been programming, and thanks to these forums, I've been able to move forward, also reading D/S that I'm much better at, but still find difficult.
Anyway, thanks all, a big help
C

 

Hi C,
I mostly use a modular block approach to designing a new product/project.

Pre-Study the Input requirements and the required Output requirements.

You have to clearly understand the ‘purpose’ of the project.

Sketch out a block diagram of the Input, Processing and Output hardware blocks. [not a Flow Chart at this point]

Design and create a prototype of the Output block, debug the output block by emulating the expected processing block input/output data.
This test data can be PC software generated, based on the stated expected input data [which I prefer] or a hardware rig.

Once you have the output working as required, then you can start on the Input block design, again creating a prototype and an emulator to generate the expected data/inputs.

For the processing block, draw a Flow chart, from which you can create a working/debug prototype.

This block may include an MCU, which means writing test/debug programs.

So, basically start with the output block, this block then can be used to test/debug the Input and Processing blocks.

As an example, consider your current Servo problem, which should have been debugged as an Output block, stand-alone module.

Also, stick to the required design specification, don't add 'bells and whistles' as you go.
E

 

Hi C,
I mostly use a modular block approach to designing a new product/project.

Pre-Study the Input requirements and the required Output requirements.

You have to clearly understand the ‘purpose’ of the project.

Sketch out a block diagram of the Input, Processing and Output hardware blocks. [not a Flow Chart at this point]

Design and create a prototype of the Output block, debug the output block by emulating the expected processing block input/output data.
This test data can be PC software generated, based on the stated expected input data [which I prefer] or a hardware rig.

Once you have the output working as required, then you can start on the Input block design, again creating a prototype and an emulator to generate the expected data/inputs.

For the processing block, draw a Flow chart, from which you can create a working/debug prototype.

This block may include an MCU, which means writing test/debug programs.

So, basically start with the output block, this block then can be used to test/debug the Input and Processing blocks.

As an example, consider your current Servo problem, which should have been debugged as an Output block, stand-alone module.

Also, stick to the required design specification, don't add 'bells and whistles' as you go.
E

Hi E,
I've never mastered flow charts, but I know what you mean, and I try to do it as best as I can.

Regarding bells and whistles, the project that you're helping me with, has grown over the years, but that's because I learnt, that a newly discovered 'bell' was so good, that I had to add it into the project, and the problem is that I keep learning about new 'whistles'
Cheers, C

 

In a career lasting half a century I never came up short of microprocessor resources requiring a panic redesign. One time a supplier failed to fulfill a delivery contract for 1000 pieces with 26 week delivery time and told us to pound sand because they were servicing their German customers. We did do a redesign which actually benefitted us in the long run.

Maybe I was lucky or maybe I was just good enough to never wind up a day late or a dollar short.