- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am short on available pins using the PRoC BLE module.
Is there a way to monitor my battery supply voltage without using an analog input pin like I can do on my PIC projects.
I see there is a 1.024 internal reference but do not see an obvious way to read it with respect to VDDD. Is there a way?
On my PIC projects I can do this so that, if I assume the reference is exactly 1.024, and if I get a reading of it with respect to VDDD, it is a simple matter to calculate current battery voltage and no pin is lost doing this.
If there is, is there a way to double scale the Vref before I read it with respect to VDDD?
Thanks,
Dale
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Thanks,
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for checking!
1st reason to switch to PSoC, but not compelling enough list yet.
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was the Freescale 8 bit specialist in New England for awhile. Also worked
with uChip.
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....:)
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dana,
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.
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
never forgets.
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.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
🙂 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
gets dissipated.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Thanks,
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dana,
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?
Thanks,
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 🙂
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The early/late thing is a sickness of a brain fried by hi tech....:)
Early due to father a lobsterman, on the boat out of the harbor at sunrise.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dale,
I don't know if you've found a resolution to this:
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'.
I came across that error (and subsequently this thread) today and after some hunting about discovered the hint is the "clock model error" part, if you go into your .cydwr file -> clocks tabs -> edit clocks down the bottom RHS you'll see an option to set the Timer (WDT) ISR to "User provided".
Cheers
Anthony