One way would be to use the Global Signal component in the
system group of components and use the PWRInt selection.
You use APIs to set its threshold. Would that suffice ?
PSOC LVI Setting and ISR.jpg 71.2 K
That looks like I can get by with it, although I have been hibernating at 3.3v with my PICs.
Too bad, that was a neat PIC trick that gave decent resolution with the Vref scaling for a single cell lithium device.
Turns out in a regular PSOC 4 you can get access to a Vdd Vref to feed to A/D.
But no Vref component (user accessible) is there for PROC that I could see.
You can under API control change the Vref the A/D uses, but can't get at it to
feed to the A/D for measurement.
Thanks for checking!
1st reason to switch to PSoC, but not compelling enough list yet.
I was the Freescale 8 bit specialist in New England for awhile. Also worked
I have done several designs in PSOC 1, am working on porting some stuff
to PSOC 3 / 5LP.
Making comparisons between manufacturers is tedious and difficult I have found.
Tables are a start but never tell the whole story.
What drew me to PSOC was analog and digital routeability. And more analog
resources than a couple of OpAmps or Comparators as found in other manufacturers.
And in the higher end family the DFB engine, more than just a MAC, many uses.
And DMA helped, create background processes I did not have to service. I recall I was
very enthusiastic when NEC did the V25, 20+ years ago, but abandoned it. micro coded
background processes and busses to support them. But we have PSOC now.
Tools are a consideration, I wrote code on a PDP8 to test ICs, paper tape, and worked
with Teradyne whose docs so bad I had to write test vectors to figure out how their CPU
worked. Ugh. So I like good tools, but less willing these days to work with poor hardware
and little or no configurability.
Enjoy PSOC, not perfection, but the crew keeps making regular improvements in both tools
and HW. Buts that is what our children are for, to make things better....:)
That is quite the career! I have only done a dozen or so PIC projects (but I did design and build the Lazair when I was younger and more recently the eLazair).
It is nice to know a little about that person out there in cyberland that has been helping me.
That is an awesome accomplishment. I looked at the Wiki site. You clearly had a lot
of originality and success.
I had a birthday present years ago and did a glider ride, had one great experience. Just north
of Bay Area, only downside was it was hot riding in front seat with limited air ventilation.
I tried flying it just a little, really challenging being at the tip of a spear trying to navigate.
Reminded me of when I qualified on SSN583 at the planes, flying a sub underwater is pretty
much same as flying in liquid, air. I have flown (as rider and newbee) and sky dived out of
small Cessna and always enjoyed the "feel" of real flying. Even the feel of being close to
front of commercial airliner reminded me of turns on the sub, corkscrew effect. And the
effect of turning a 5 MW reactor into a 150% back bell to stop the boat, some things one
A lake I am quite familiar with had, up until last year, a fly in every August, and all kinds of
experimental sea planes would come. I used to boat around the planes and drool.
:) I have a US record in Standard Class gliders with a 1000 mile flight. Looks like we would have a lot of experiences to share over a few beers sometime!
To summarize the thread:
On PRoCs, if the only thing you want to do is to protect your battery by going to a lower power mode at a certain voltage, you can do it without a dedicated PRoC I/O pin as Dana has shown.
BUT, if you want to send the actual battery voltage out on BLE you need to use a pin.
As a final summary here, confirmed by a MyCase:
1. There is no way, on PRoC CYBLE-022001 module, of reading battery voltage and sending it out BLE connection unless you waste an I/O (of the few exposed) and waste power thru a voltage divider to bring battery voltage to <1.024v before routing it to that exposed pin.
2. The vRef pin is NOT routed, on the module PCB, to an unexposed I/O pin. Why, this would let us read battery voltage without either waste of point #1.
3. There is no way to use the API to internally route the vRef to the analog MUX on the PRoC chip. Why not, this would ALWAYS save the wastes of Point #1?
For a chip whose life is almost always powered by battery, it sure appears difficult and wasteful to monitor that battery voltage.
The 'near' future sees only a slight improvement:
As yet unreleased module CYBLE-024008-00 has 42 pins with 25 GPIOS exposed (including vRef).
No way to dual purpose a pin, like SWD assigned pin, use reg writes
to disconnect SWD and connect to Vdd R divider (pin) for reading ?
Note the R divider would have to occur on chip thru internal ratio accurate R
network, or sw cap + integrator approach. Or external, either way power
I have the dedicated pin available (my last one). I think I'll try a 1M/220K divider and run a simple calibration routine on a known input voltage. Then save the calibration permanently each time I program one of my boards. That is maybe 4ua if it works, which nearly triples my OFF current, oh well.
I was still hoping to use your Global Signal method of generating an interrupt at 3.3v even though I should be able to monitor the voltage on my analog in pin while I have code running.
Problem is I am using a periodic WDT0 during my BLE advertising state at 1296ms rate to wake up from Deep Sleep every 50ms to take care of reading sensors (and battery volts :) and setting outputs based on sensor values, then going back to deep sleep. I don't actually have any interrupt code in the WDT0 (it wakes from deep sleep every 50 ms by just enabling the periodic WDT0) but the fact that I use WDT0 (during advertising only) is preventing me from having a Global Signal with an interrupt using WDT's for your suggestion, at least according to this build error:
Clock Model Error: (WDT interrupt generated by PSoC Creator will be overwritten by the 'LowBat_ISR' ISR handler of the 'LowBatINT' component and the user will not be able to attach his functions to the individual WDT interrupts using callbacks. Either remove the component or change the interrupt generation option to 'Implementation by user').
I am having a little trouble tracking down 'Implementation by user'.
Can you think of someway I could set this up so it will build and such that I only use Global Signal interrupt after I stop checking sensors during advertising (and thereby stop using WDT0) due to inactivity of sensors?
EDIT: What is interesting to me is that the available Global Signal method of tripping at a specific voltage, selectable from a table, implies that Cypress is actually able to read an analog value for the battery voltage using this method (no wasted pins and no wasted power). Why then can't we just have access to that value?
The architecture TRM does not describe how the LVD is implemented, but I
would posit its a comparator with a programmable reference, eg. not an A/D
process. You could chk this by filing a CASE.
Either remove the component or change the interrupt generation option to 'Implementation by user').
I think a CASE is going to be necessary to get factory to clear up if there is a placeholder
available or does one have to diddle the vector table to get a user ISR going.
Thanks that sounds feasible but more complex that if they just had the VREF going to analog MUX.
I couldn't find 'implementation by user' in either of the components properties or component datasheet.
I'll make a case on some of this after I am able to program my darn PRoC.
You are up early/late :)