Rapid Prototyping with 16/32 bits MCU

Hello,

In Matlab 2010 32bits Vista and the Blockset 2010a V3.2B, I got a new issue never see before with the toolbox 2007 version on the output compares.
So I tried with OC1 and OC2, in the simplified model attached and first the signal frequency is not very stable, and mostly with the settings:

'Max/channel' at : 2.5e-005 , the pulse signal period is 20ms so 50Hhz rather than 40KHz and 25uS

and for :

'Max/channel' at : 0.001 , the pulse signal period is 1.1ms so close but not good.

Any idea ?

I tested something and the problem is linked with the idle mode. When the idle is disable the OC work fine, the frequency are good and stable. So it could be a wake up time issue on the OC interrupt.


About consumption :

Lubin, what is for you the good way to use the idle ? Do you advice to not use some peripheral in idle mode for example ? For me the idle put down the core when all calculus are done and there is still some time before a peripheral interrupt or a base timer restart the loop code. On this way all peripherals have to continue to work and the core wouldn’t lost anything when it’s wake up… But maybe I’m wrong ?

I’m interested by going in sleep mode too. But something easy I don’t want (for the moment) a wake up on interrupt, WDT or other IC. I just want to go in sleep mode when the battery is low to avoid deep discharge. I think to use the C call function to go in sleep mode when the battery level in under a threshold so the wake up will be on a reset (new battery) . Do you have a ready or easier way to do it? I think it’s a common problem for people using rechargeable battery mostly Li-ion and Li-Po. How did you do on your fly project ? What about latter add just a new block to go on sleep mode and no wake up parameter, the instructions seem the same for most Pic

This is the way it is supposed to works. Nothing get lost while activating idle mode. However, developing without idle mode is advise, and then test should be done with power save mode (idle activated) activated.
A specific peripheral (its name is Low Voltage Detection (LVD)) but it is not implemented yet on the blockset.
The problem that may appears with solution you propose: going into sleep mode using C call: All peripheral are configured to works, or Wake up the core, during the sleep mode. Thus, you will not get a very long sleep. Anyway, if reconfiguring bits in peripheral to make them not workable during sleep, dans also disabling all interrupts, it may be possible to get a deep sleep mode.


For Li-ion or Li-Po power cells, the best practice is to use a small circuit close to the battery that cut off battery power when voltage is lower than a predetermined threshold. Difficulties may appear when motor are driven from theses Li-Po/Li-ion cellules as a current peak may appears at motors start that may activate the cut-off circuit (this one is re-enabled automatically as soon as battery is charged, even for very short time (1s) ) . This way makes battery well protected but you must beware of current drain by rapid motor consign changes (an interesting constraint for control model) . If only electronics is driven, there should be no problems.

During prototyping process, I usually get my Li-Po / Li-ion cells getting fat. Reason is either I draw too much current when cells drives motors. On electronics parts, the drop down of Li-po cells is very fast ad end of charge. Thus, the microcontroller stop working quite suddenly thus, I disconnect my li-po as soon as I see it.
Of course, that is not the way to do for commercial products…

Lubin