which uC brand should I use ?

[Thunderchild]

ok well without having fights and insulting each other, (oh and why isn't there a pic subcategory above ?) I'm looking for an alternative to pic's I'm told that atmel AVR uC's run 4 times the code at the same clk speed but I'm also after simplicity so I'm after a faster (read more efficient) uC but that also has good support

 

[Nigel Goodwin]

There isn't a PIC sub-category because the main microcontroller one is mostly PIC - to some extent AVR's run faster than low end PIC's - but it's not as simple as that, because low end PIC's instructions almost all run in one cycle.

You need to decide what you want and why - understanding that faster doesn't mean 'more efficeient' would be a start

PIC's have by far the greatest support, but AVR is probably quite sufficient - but are you familiar with either?, or any other processor? - you can do most jobs with most processors, stick with the one you know.

 

[Thunderchild]

I have ground knowledge of pic's, I know that in my application I need to use the PWM output and i need it as low frequency as possible so need a low clock speed, but then I want the uC to carry out other tasks as well so need it to carry out as many instructions between each PWM pulse as possible

 

[HarveyH42]

I search the web, and got part numbers for several brands of chips, doing project similar to what I had in mind (types of gadgets), downloaded the data sheets, read and compared. I never learned to program in 'C', so it was the Assembly Language instruction set, which was my focus. Most chips have similar features and functions. I chose AVR, and have no regrets. Around 130 instructions, 32 working registers, most instructions in on cycle. PIC had 36 instructions and only one register, instruction executed in one cycle, but you need use several instructions to often to deal with the single register. Was just my opinion, as I was looking to program in Assembly, and AVR looked best to me. If you program in a compiled language, like 'C', it doesn't matter, and you can get a faster chip, or more memory if needed. Most all microcontrollers are much faster than you will actually need for most projects, and need delay loops.

It all really comes down to a personal preference, most all will hand whatever task you have in mind. I doubt the difference are all the significant, just something to argue about. Depends on your budget, if you can afford it, try other chips. They all function about the same. I used Nigel's tutorials to learn how to hook stuff up to the I/O pins, since data sheets don't go into much detail, and I've never used a PIC...

 

[BeeBop]

I have ground knowledge of pic's, I know that in my application I need to use the PWM output and i need it as low frequency as possible so need a low clock speed, but then I want the uC to carry out other tasks as well so need it to carry out as many instructions between each PWM pulse as possible

You will run into the same problems on any micro; it is your algorithm which needs the effort.
Why is it you think you need a slow clock speed to do low frequency PWM? Is it because it is a very low power consumption circuit? By the sounds of it you are using blocking delays which just waste cycles, are you? You need to switch to delays which don't block other things from happening while they execute. Look into state machines. I think 3v0 has some tutorials on doing this:

3v0's Tutorials

look at "Learn how to do Cooperative Multitasking from the ground up."

 

[Thunderchild]

You will run into the same problems on any micro; it is your algorithm which needs the effort.
Why is it you think you need a slow clock speed to do low frequency PWM?

The minimum speed of the PWM output as well as the maximum speed is tied to the clock speed, I need a PWM frequency of about 250 Hz, this can only be obtained at no more than 4 MHz 245 Hz being the absolute minimum, if I increase the speed so that more stuff can be done by the uC I will have to increase the PWM frequency with it.

I am not creating any delays or anything but want to make sure that firstly the ADC runs as fast as possible because it has to take two measurements on two different channels for the calculations to be carried out, and then carry out the calculations that the duty cycle of the PWM is dependant on, idealy I would like to ajust each and every PWM cycle as the environment variable change.

My conclusion is that I will dedicate 1 uC to the actual core function of measuring and ajusting and any other features like readouts of values will be done by a second uC, that way I get to keep the low clock speed for the core functions and and run all the fancy stuff off the other uC.

Of course a further development would be to use one uC to generate the PWM output based on readings taken by a faster uC which could just send a "flag" to the one genrating the PWM to tell it wether to increase or decrease the duty cycle.

 

[BeeBop]

OK you are using the HW PWM, but at 250 Hz you have 4 mS between times you have to change your output state for PWM, so there is a lot of time to take both readings and do your calculations if you were doing a software PWM. You could still do all of this on a simple PIC, and there should be no trouble doing it, even at 4 MHz (you have 4000 cycles to do what ever you have to between changing your PWM pin state,) however you could run the thing at 20 MHz and have way more cycles.

I am not creating any delays or anything but want to make sure that firstly the ADC runs as fast as possible because it has to take two measurements on two different channels for the calculations to be carried out, and then carry out the calculations that the duty cycle of the PWM is dependant on, idealy I would like to ajust each and every PWM cycle as the environment variable change.

Still, the idea of multi processors is interesting, so please keep us informed of your progress.

 

[Thunderchild]

well I had heard of software PWM but I'm no code geek and want to have it simple and powerful. This is a power controller for a vehicle so the essential functions are taking the readings and control the duty cycle of the PWM output, the secondry functions were to send the values read by the ADC to a display that is external to the project for diagnostic purposes,

I have completed stage one which is the core control function, once that is working I'll consider the display functions as a second stage (I have room on the board for another uC and related circuitry) I was thinking of having them run indipendantly so the second uC would use it's own ADC to take readings, but as a third stage development I could have the second highspeed uC taking ADC readings and doing all the calculations and simply sending a 0 or 1 to the first to tell it to increase or decrease the dutycycle of the PWM, the advantage being mostly hypothetical but the ADC on the faster uC would operate faster and so the values read on the 2 and possibly 3 channels would be for practical purposes taken simultaneously, plus it means that there is a less complec PCB because it means 1 track going between the pics instead of both pic's being connected to the 2 or 3 sources and only one pic loading the sample lines,

 

[Nigel Goodwin]

well I had heard of software PWM but I'm no code geek and want to have it simple and powerful. This is a power controller for a vehicle so the essential functions are taking the readings and control the duty cycle of the PWM output, the secondry functions were to send the values read by the ADC to a display that is external to the project for diagnostic purposes,

Why are you wanting 250Hz? - what's wrong with been higher?.

You might check my PIC PWM 'tutorial'?.

 

[Thunderchild]

I'm controlling the field coil of a dynamo, the original reg runs it at 75-150 Hz, after some simulation in electronics workbench I have discovered that the higher the frequency the higher the voltage of the kickback spike, I don't have a huge issue with that but I don't know what effects different frequencies will have on the operation of the dynamo so would rather start out being in the position to start with what is pretty much the original frequency and then maybe experimenting

I'm also using basic as I got absolutly no where with assembler and I'd rather run the risk of a bit of inneficient code here and there rather than not be using uC's at all. I can use snippets of assembler in the basic compiler though

 

[Nigel Goodwin]

I'm controlling the field coil of a dynamo, the original reg runs it at 75-150 Hz, after some simulation in electronics workbench I have discovered that the higher the frequency the higher the voltage of the kickback spike, I don't have a huge issue with that but I don't know what effects different frequencies will have on the operation of the dynamo so would rather start out being in the position to start with what is pretty much the original frequency and then maybe experimenting

I'm also using basic as I got absolutly no where with assembler and I'd rather run the risk of a bit of inneficient code here and there rather than not be using uC's at all. I can use snippets of assembler in the basic compiler though

Check out my PWM tutorial then, basically all it does is setup the PWM module (and then run a simple looped demo) - you could easily copy that in BASIC. Altering the duty cycle is just a matter of writing to one register.

 

[Thunderchild]

so you are using the hardware PWM module ? I have already established that at 4 MHz the minimum is 245 Hz and therefore at 8 MHz the minimum is 490 Hz, the issue is a hardware limitation, the only way around it is to use a higher clock and software PWM but that may be a bit over my head at the moment. I have come up with the novel solution of using one low end pic to just produce the PWM output and another midrange pic to do all the ADC conversions and other fancy stuff I may dream up in the mean time, at that point I may be interested in some sort of interpic communication method like RS232 as I may be sending info to a third external pic

 

[Nigel Goodwin]

so you are using the hardware PWM module ? I have already established that at 4 MHz the minimum is 245 Hz and therefore at 8 MHz the minimum is 490 Hz, the issue is a hardware limitation, the only way around it is to use a higher clock and software PWM but that may be a bit over my head at the moment.

So?, both those frequencies would be perfectly fine - you're making life difficult for yourself for absolutely no reason.

 

[Thunderchild]

So?, both those frequencies would be perfectly fine - you're making life difficult for yourself for absolutely no reason.

thos frequencies are fine at 4 and 8 MHz, if I decided to run at 20 MHz or use another pic running at 40 MHz the PWM frequency would have to increase proportionately, I was aiming to have low frequency PWM output but also enough cycles between pulses to carry out all the calculations

 

[Nigel Goodwin]

thos frequencies are fine at 4 and 8 MHz, if I decided to run at 20 MHz or use another pic running at 40 MHz the PWM frequency would have to increase proportionately, I was aiming to have low frequency PWM output but also enough cycles between pulses to carry out all the calculations

At 20MHz it would be fine as well - as I said you're worrying unduly.

And don't worry about 'calculation time' you're dealing with the real world, which runs EXTREMELY slowly, you've got all the time in the world to do your calculations, even at 'only' 4MHz.

 

[Thunderchild]

bear in mind that the "real world" is an engine running at 1000-7000 rpm, with a non loaded engine (ie someone reving it in their drive) acceleration rates can be high, and I'm running at 245 Hz so things can change in 4 ms (I am uncertain also of how quikly new values take effect in the PWM module - maybe a cyle late ?), although things seem to be coping ok, the PWM control operates in steps so if I need to lower it quikly due to suden acceleration it can only happen in steps by running through the cycle over and over, my previous prototype ran at 8 MHz and we found this to be better than 4 MHz but I was ajusting the PWM steps one at a time, I am now considering 8-10 steps at a time to increase effective responsiveness.

I know I'm possibly being over cautious by this will be managing the entire electrical generating system of the vehicle and will eventually (once road tested) be put into cars running rallies in hot weather on the continient far away from my assistance if things go wrong. I don't really need a person in a car worth 0.25-1 million pounds 2000 miles away with a fried electrical system due to my poor design.

are you saying that you PWM module is software ? I have tried lowering the PWM frequency with higher clocks and the compiler will just not accept it, something to do with the fact that the counters in the PWM module will only count down and therefore reduce the clock speed by a maximum amount

 

[Nigel Goodwin]

bear in mind that the "real world" is an engine running at 1000-7000 rpm, with a non loaded engine (ie someone reving it in their drive) acceleration rates can be high, and I'm running at 245 Hz so things can change in 4 ms (I am uncertain also of how quikly new values take effect in the PWM module - maybe a cyle late ?), although things seem to be coping ok, the PWM control operates in steps so if I need to lower it quikly due to suden acceleration it can only happen in steps by running through the cycle over and over, my previous prototype ran at 8 MHz and we found this to be better than 4 MHz but I was ajusting the PWM steps one at a time, I am now considering 8-10 steps at a time to increase effective responsiveness.

rpm is VERY slow in microcontroller terms - anything you measure in minutes is incredibly slow. But even more important, the rpm of the engine isn't relevent anyway, it's how fast the controlled system responds (which is slow, and no reason for it to be at all quick).

The higher the PWM rate, the faster it can respond - I'm bemused at why you're introducing limitations and restrictions and aiming for a random slower speed for no reason?.

I know I'm possibly being over cautious by this will be managing the entire electrical generating system of the vehicle and will eventually (once road tested) be put into cars running rallies in hot weather on the continient far away from my assistance if things go wrong. I don't really need a person in a car worth 0.25-1 million pounds 2000 miles away with a fried electrical system due to my poor design.

are you saying that you PWM module is software ? I have tried lowering the PWM frequency with higher clocks and the compiler will just not accept it, something to do with the fact that the counters in the PWM module will only count down and therefore reduce the clock speed by a maximum amount

No, my PWM tutorial uses the hardware, as you really need to be doing - it's dead simple, reliable, and easy to use.

You're making far more of this than it is - mechanical relays manage it perfectly well - it's a VERY non-critical application, and a micro-controller is massive over-kill (not that the fun of using a micro-controller for it isn't worth doing).

 

[Thunderchild]

yes I'm using the hardware PWM channel, and yes the higher the PWM frequency the faster it responds. I am concerned with changing the frequency though as I don't know if the dynamo will "like it" I just know it is a hefty coil and probably prefers the 100ish Hz control signal, if 500-1000 is ok then that makes life simpler. I'm considering temperature compensation to help it manage in the winter by pumping a bit more current out as it's colder so should cope and thats where I start to neet to know that the ADC can take multiple measurements fast enough and do all the calculations that will produce the next duty cycle value (my friend takes his dynamo off in the winter and replaces it with an alternator - hence my many posts related to this project as I've had time to consider all angles and possibilities)

 

[Nigel Goodwin]

yes I'm using the hardware PWM channel, and yes the higher the PWM frequency the faster it responds. I am concerned with changing the frequency though as I don't know if the dynamo will "like it" I just know it is a hefty coil and probably prefers the 100ish Hz control signal, if 500-1000 is ok then that makes life simpler. I'm considering temperature compensation to help it manage in the winter by pumping a bit more current out as it's colder so should cope and thats where I start to neet to know that the ADC can take multiple measurements fast enough and do all the calculations that will produce the next duty cycle value (my friend takes his dynamo off in the winter and replaces it with an alternator - hence my many posts related to this project as I've had time to consider all angles and possibilities)

Try it and see - but I'm even more bemused why anyone would run an alternator in the winter, and them bother putting a crappy dynamo back on in the summer?.

I don't see how you can 'squeeze' a little more power out of a dynamo - controlling the field coil can only DECREASE the power, not increase it.

There also seems little point in PWM'ing it to try and give real time control, when 'burst fire' control (as used in the original) works perfectly fine.

 

[Thunderchild]

Try it and see - but I'm even more bemused why anyone would run an alternator in the winter, and them bother putting a crappy dynamo back on in the summer?.

I don't see how you can 'squeeze' a little more power out of a dynamo - controlling the field coil can only DECREASE the power, not increase it.

There also seems little point in PWM'ing it to try and give real time control, when 'burst fire' control (as used in the original) works perfectly fine.

well some people are mad over authenticity when it comes to older cars

Controlling the field coil will not decrease the power, the dynamo needs regulating at all times or you can end up with 40 volts (I managed 18 before pulling the plug on it and it looked eager to keep rising) , I can set the current limit in the software and it will run to that, so if I have a temp sensor and related algorithm to increse the amperage figure when the weather is cold I can allow more power to be generated in winter but keep it to normal levels in the summer so as to not burn anything out.

I suppose I could just replicate the "burst fire" control of the original and run at a high clock speed, at the end of the day it still results in a crude PWM but with a drift in frequency, in his case this was 70-150 Hz hence my choice of frequency. in any case once built I can use both versions of control, thats the beauty of the uC method I get to play with variables without unsoldering stuff all the time, or redesigning the whole project.

as it happens i got a more steady regulation than the original reg, so I did something right