Loopy,
From what I have read, the serial is ttl on the MR3020 just like the WR703N. Perhaps you have the tx and rx wired the wrong way. The easiest way to check is to use the propplug and link the grounds and then connect each wire (TX first as this should be it) to the RX on the propplug (with PST or another serial program running on the pc connected to the usb propplug). You should then see the normal booting output stream. Once this works, then it is easy to connect the RX to the TX on the propplug.
If you are worried, use a series 1K resistor between the connections Tx & RX.
Don't forget it is 115,200 baud - maybe just check the writeup on the binary in case it is different but I expect it to be the same.
@Cluso
The OpenWRT entry for the MR3020 recommends Tx have a pull-up to 3.3v. with some discussion about a voltage divider of two 5.6k resistors and a cap connected to the before going to the Tx output.
On the other hand, the OpenWRT entry for the WR703N doesn't mention anything similar.
It does seem as if such a circuit my be for protection of Tx output as it reaches the outside world.
++++++++++++++
I may have a poor ground connection at where the PropPlug connects to the Propeller Protoboard, or in the cable construciton. That would explain what the wired loopback performs flawlessly, but the actual communication doesn't.
I'll keep trying. I have tried reversing the Tx and Rx and fooling with a separate ground. I did look like I got momentary success, but I am not sure. I had to revert to checking that I didn't damage any of the serial ports involved, and now am trying again.
One of the nicest outputs I have seen from a computer:
heater@debian:~$ propeller-load -P
Propeller Version 1 on /dev/ttyUSB0
Well, for some while anyway.
Why?
Well, I was up in the middle of the night building myself a Propeller circuit onto a proto board.
When the regulator circuit was done I tested it by itself. Poof the smoke came out.
This morning I replaced the regulator. Again poof, the smoke came out. (I really must get a current limited power supply).
Then I see the error of my ways. Some pads on the board under the regulator tab that I thought were not connected to anything, well, they were. I had forgotten a few changes of plan along the way.
Luckily there was one regulator left. Yay it works!
Only this thing is only good for 7 volts max input. So the smoke may come out again when I charge the 6 volt NiMh battery pack I want to power it with.
Anyway I now have a little board to connect to a router. No EEPROM, who needs one when the router can load code to RAM on start up? Running nicely at 96MHz.
heater,
Fantastic news. And yes, no eeprom required.
For the regulator, just put a couple of 1N4001-1N4004 diodes in series or a bridge. Each of those will drop 0-6-0.7V.
I love the phone chargers - 5V @ 500mA or 1A are great power supplies for projects these days.
And so, Heater has now completed the original Milestone Two -- Tx and Rx with a Reset from GPIO programming the Propeller via a wireless router link.
That pretty much asserts the two milestones solved.
+++++++++++++++++++++++++++++++++++++++++++++++++
Congrats.
May we have some more details... How did you get the GPIO working -- wiring and software solutions?
And how did you manage not having the Serial Console interferring with programming?
It seems I came down with a summer cold, so I just slept most of yesterday after determining everything in my set up was working right. I may get back to it all later today.
I am still interested in getting my own complete RS232 without using the USB port.
Finally, I have my Tx and Rx working with Tachyon Forth on /dev/ttyATH0. The struggle is over.
Now I need your mentoring to get the GPIO to Reset working. I will proceed to build an interface, but I am not sure how you modified code.
I am extremely happy with this as it leaves the USB port available for all sorts of other uses -- mass storage, a USB to printer, a 3G/4G modem, or a USB powered bridge to multiple devices.
~~~~~~~~~~~~~~~~~~~~~~~
It appears that I had two problems working together -- bad soldering and reversed construction.
A. The header I soldered into the MR3020 suffered from a cold solder joint on the Vss and maybe the Vdd as well. So the Tx and Rx worked nicely in a loop-back, but not reliably when connected to the Propeller Protoboard.
B. I need to reverse the Tx and Rx. The configuration that work straight through with the USB2SER was not appropriate -- needed a cross over.
++++++++
Apparently the cold solder joint was not so bad. The USB2SER worked with it when connected directly to the MR3020. I did seem to have some success early when reversing the Tx and Rx, but was very tired and confused. So I went into 'get some rest, double check everything, and clean up problems' mode
I had noticed that the cable was only delivering 3.01VDC between Vss and Vdd. It now delivers a nice 3.30VDC.
I continue to have the 3.3VDC provide a pullup to Tx at the MR3020. It may or may not be possible to eliminate this.. but I will stay with this as it works fine.
______________ happy, happy...
I have now installed a 90 degree 4 pin header and drilled a hole in the side of the case for a cable to go through. These measures will allow me to close up the case and have an interface to a Proeller Protoboard 24/7.
root@OpenWrt:/tmp# ./propeller-load -Dreset=gpio -p /dev/ttyS0 -r dlink-test.binary
Propeller Version 1 on /dev/ttyS0
Loading dlink-test.binary to hub memory
28 bytes sent
Verifying RAM ... OK
Sorry I was a bit misleading in my previous post, that "Propeller Version 1 on /dev/ttyUSB0" was actually me getting my hand made Prop board working for the first time connected to a PC via PropPlug.
The above is from my D-LINK connected to the Prop over the console UART. Really, honest, no joke this time:)
Note:
1) This propeller-load has a new option to allow use of GPIO as a Propeller reset. "-Dreset=gpio"
This is currently hard wired for my GPIO 11, the blue LED. The LED flashes satisfyingly when programming but it also has a bad habit of flashing, sending a Prop reset, when the router is rebooted.
2) I select the port manually with "-p/dev/ttyS0"
3) I Simply disabled console on the UART as described on the openwrt.org pages.
TODO:
a) Get this code into github.
b) Add some option to select which GPIO pin. I'm thinking of doing it like this: "-Dreset=gpio,11"
c) Build it for your routers if you like.
d) This only supports simple binaries as produced by Spin so far. I need to get all the features for C executables working.
I though about adding some diodes to drop the voltage. A bridge would be nice as it's a bit haphazard which way my power connector gets plugged in! But I hate to throw away volts when powering from a battery. Isn't there an LDO regulator that can tolerate more than 7 volts? I might just wing it, charge the battery and see if the reg blows:)
Loopy,
May we have some more details... How did you get the GPIO working -- wiring and software solutions?
As far as wiring goes:
I have direct connections from tx/rx on the D-Link UART to tx/rx on the Propeller. They may actually be reversed I'm not sure any more.
I have a direct connection from the pin on the blue LED on the D-LINK to reset on the Propeller. Just happens that when the LED is off that pin is pulled up to 3.3v. When the LED is on it get's pulled down to 0.65 volts, low enough to reset the Prop.
The router ground is of course connected to my Propeller ground.
I basically have four wires coming out of the router that end in a PropPlug style connector.
For the software:
This is a long story....
The propeller-loader comes from the loader supplied as part of the propgcc sources. I had previously hacked this around so that it used a GPIO for reset when used with the UART on a Raspberry Pi. Some of those changes made it back into the upstream propgcc source repository.
I have hacked this around a bit more to build it for the routers.
Actually building it just now is a pain. In summary:
a) Fetch the entire propgcc source code from it's repo.
b) Build propgcc for you PC, say Debian.
c) Build the loader, which requires propgcc, for the router!
Hopefully this can be streamlined a bit when I get the new changes back into propgcc.
And how did you manage not having the Serial Console interferring with programming?
I can be patient at this point. It has been a merry chase to keep up with Heater up to this point.
I knew Heater had been dealing with the GPIO to reset on the Raspberry Pi previously and appreciate him generously sharing this info ... especially after all the gripes I've made about the R-Pi. Thanks again. and again.
I intend to take an NPN transistor, emitter to ground, collector to the Propeller reset, and the base to the GPIO through a current limiting resistor somewhere. I don't really desire to have another flashing LED or to borrow one.. though that is a bit economical.
My GPIO numbers are likely to not be the same, so it may be time for me to actually compile a binary. That's okay with me.
+++++++++++
Status to date.
Vdd is actually 3.32VDC, not the previously reported 3.30VDC.
Tx and Rx are working nicely with Tachyon Forth. I changed to 57600 8n1 because I wanted to verify that Minicom would actually change the baud rate to something other than the default of 115200 8n1. It seems that all of Minicom functions may work -- more than most user will want.
Propeller-load still works nicely on /dev/ttyUSB0. I am not going to try the /dev/ttyATH0 until I have a GPIO to reset solution in place in hardware and software.
To Do:
a. Get a direct wifi solution working correctly.
So far I have made a mess of directly using LuCi and SSH via wifi on my MR3020, so all the contact with the Propeller for loading binaries and for using Tachyon have been through LAN.
I need to be able to log in to SSID=DogHouse and deploy both SSH and LuCi. So far I can't seem to identify the blockage. I am using the configuration that I have previously posted.
I would like to disconnect the LAN cable entirely and have Wifi be the only means of communication to the Propeller and only means of downloading the binary.
b. Build the GPIO to Reset interface.
This should be quite easy. We discussed the alternative previously and I have just been holding off until I was sure the Tx and Rx were fine.
c. Leaving everything on for 24 hour burn in.. just to be sure my build is now stable.
d. Locate and read the original propeller-load C code in order to have some idea of what is involved in modifying it.
With regard a UART and GPIO as a Propeller reset signal, the Raspi is just one of thousands of SoCs that can do that. The code for the loader in propgcc identifies this feature as as raspi specific. I have to make it more general.
Why do you want that NPN transistor in between your router and your Propeller? If the two are in close proximity it is hardly necessary. It serves to invert the signal which would mean adding another configuration option to the loader to cater for that. If the two are not in close proximity I'd be thinking about opto isolating the thing. And the serial lines.
I will make the GPIO number a user option somehow.
Just for completeness I had to solder a LED to pin 1 of the Propeller connected to my router.
I mean, you are not there yet if you can flash a LED, right?
So here we go, top to bottom:
heater@debian:~$ cat dlink-test.spin
CON
_xinfreq = 6_000_000
_clkmode = xtal1 + pll16x
PUB LedOn
dira[0] := 1 ' Set P0 to output
repeat
outa[0] := 1 ' Set P0 high
waitcnt(clkfreq / 2 + cnt)
outa[0] := 0 ' Set P0 low
waitcnt(clkfreq / 2 + cnt)
heater@debian:~$ openspin -b dlink-test.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Oct 21 2013
Compiling...
dlink-test.spin
Done.
Program size is 60 bytes
heater@debian:~$ scp dlink-test.binary root@192.168.2.1:/tmp
root@192.168.2.1's password:
dlink-test.binary 100% 60 0.1KB/s 00:00
heater@debian:~$ ssh root@192.168.2.1
root@192.168.2.1's password:
BusyBox v1.22.1 (2014-07-19 03:31:09 EEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
BARRIER BREAKER (Bleeding Edge, r41737)
-----------------------------------------------------
* 1/2 oz Galliano Pour all ingredients into
* 4 oz cold Coffee an irish coffee mug filled
* 1 1/2 oz Dark Rum with crushed ice. Stir.
* 2 tsp. Creme de Cacao
-----------------------------------------------------
root@OpenWrt:~# cd /tmp/
root@OpenWrt:/tmp# ./propeller-load -Dreset=gpio -p /dev/ttyS0 -r -v dlink-test.binary
Propeller Version 1 on /dev/ttyS0
Loading dlink-test.binary to hub memory
60 bytes sent
Verifying RAM ... OK
For some reason this did not work the first hundred times I tried it. I was beginning to think openspin or propeller-load had some issue with "wrong-endian" processors, not an unknown happening in cross-platform code.
OK this is weird. I found out why I though this was not working...
Initially I had no LED. I was checking for the pin going up and down with a multi-meter. Nothing was showing...
Now I have the LED I see it flashes, the programming works.
But when I put the ground of the multimeter onto the ground of my board or the router, poof it resets the Prop.
So of course I never saw anything happening without the LED.
My Propeller board is battery powered. The router has the normal wall-wart.
heater,
An LDO regulator is still going to waste the volts because they are not switchers. I think when you charge the LiPo you will get ~7.2V which is probably ok with your reg if it says 7V but maybe not if it says 6V which is common. There are LDOs with higher V.
Not sure about your grounding problem. Will have to digest later today.
You have truly made great progress. I just haven't had the time yet.
Loopy,
If you use a transistor you will require a 10K or more pulldown to keep the transistor off. But as heater said, the proploader will now need to invert the reset.
GTG. I will try and get on during the day to check in.
@Cluso
Yes, I was thinking a pull-down resistor in the base would be needed. Since the two GPIO I am looking at already have 10K pull-down resistors attached, I failed to mention them.
I am beginning to ponder the idea of not modifying the existing propeller-loader code, which works beautifully and instead writing a serial driver of some sort to go in /dev, say ttyXXX0 for 'experimental' or ttyPAR0 for 'Parallax'.
It may be simpler to go with Heater's modified propeller-loader just because it is already evolved, but I am curious.
Sure, the LDO will drop volts and being linear will waste energy in doing so. So the diode(s) make no difference by way of efficiency.
It was the voltage head room I was thinking about. What happens when I want to run this board of different batteries or 5v from USB.
This reg is spec'ed ay 7v max so I'll risk it as it is and look out for some higher voltage ones. I'm sure one of the ones I blew was good for 15 volts. If only I could remember what it was now...
Should we have a pull up and a cap to ground on the reset or something? I had this kind of problem with my last proto board creation, it would reset when the fridge in the house started up!
Loopy,
I thought about making a custom driver for this situation way back when I started with the Raspberry Pi version.
Thing is you have to provide that driver for every possible architecture and kernel version, or hope your users can compile it from source. The kernel will not load modules built against the wrong kernel version. You need to provide instructions to install it, to get it loaded into the kernel, to configure it. It's like that USB serial driver for Windows problem but a thousand times worse.
Such a driver would make sense if it's features, GPIO as DTR/RTS, were generally useful and in demand, then it would eventually end up in the main line kernel and everyone would have it.
On balance I think we are as well to use the nice easy, portable, user space interface (/sys) that the kernel developers have provided for us. Everyone has that already.
As for "...not modifying the existing propeller-loader code...", most of the code I made for this has been in the upstream propgcc sources already for a long time. These recent changes are very minor and hopefully will find their way into propgcc, then everyone will have that.
Sure, the LDO will drop volts and being linear will waste energy in doing so. So the diode(s) make no difference by way of efficiency.
It was the voltage head room I was thinking about. What happens when I want to run this board of different batteries or 5v from USB.
This is where you need the diode to be on the battery side.
What sort of reg are you using? PN and case style. Are you also running the router from this? If you are just powering the prop from this supply, it might be easier to bring the 5V from the router (or 3V3 and a 10uF tantalum on the prop power side).
If you are powering the router also, then from what I recall, the router could use up to 350mA plus say 50mA for the prop gives 400mA. Now, if you have 7.2V (fully charged LiPo) and you need to drop to 3v3 that is 7.2-3.3 = 3.9V @ 400mA = 1.56W which is probably OK in a TO220 case without heatsink for your cold location.
This reg is spec'ed ay 7v max so I'll risk it as it is and look out for some higher voltage ones. I'm sure one of the ones I blew was good for 15 volts. If only I could remember what it was now...
Should we have a pull up and a cap to ground on the reset or something? I had this kind of problem with my last proto board creation, it would reset when the fridge in the house started up!
If there is a longish wire (to pickup noise) then a 10K pullup is advisable. A cap to ground should not be necessary unless there is a lot of noise. Then only a low value 1nF because this will slow the reset rise time. It will not do anything if you have it connected directly to the AR9331 GPIO unless you put a serial resistor in the line.
For my prop designs I now put in a 10K pullup using a 4x10K resnet smt (reset, sda, scl, wp for eeprom)
Loopy,
I thought about making a custom driver for this situation way back when I started with the Raspberry Pi version.
Thing is you have to provide that driver for every possible architecture and kernel version, or hope your users can compile it from source. The kernel will not load modules built against the wrong kernel version. You need to provide instructions to install it, to get it loaded into the kernel, to configure it. It's like that USB serial driver for Windows problem but a thousand times worse.
Such a driver would make sense if it's features, GPIO as DTR/RTS, were generally useful and in demand, then it would eventually end up in the main line kernel and everyone would have it.
On balance I think we are as well to use the nice easy, portable, user space interface (/sys) that the kernel developers have provided for us. Everyone has that already.
As for "...not modifying the existing propeller-loader code...", most of the code I made for this has been in the upstream propgcc sources already for a long time. These recent changes are very minor and hopefully will find their way into propgcc, then everyone will have that.
@Heater
Thanks... trying to sift thru GIT hub to comprehend what's what. This is one of my weaker skill sets.
@Cluso
I have purchased a few boost and buck switcher boards that are very inexpensive. These devices are rated at something like 92% efficency, whereas the linear regulators are something around 70%.
LDO linear regulators consume significantly extra power when operating in their LDO region. As far as I can figure, the LDO feature was intended to primarily provide constant voltage in automotive settings.. where there are sudden shifts in load. They are not really a good choice to squeeze extra power out of a battery or to operate in the LDO 100% of the time.
And so, Heater argues that you might as well have a diode dump a bit of voltage when a small adjustment in voltage is required. It will likely waste less than a linear LDO.
+++++++++
I haven't gotten too much into the low power aspect of using these devices yet. But i do have a 12VDC gel cell with trickle charger set up that drops the voltage down to 5VDC via a switcher. That seems like an eventual good fit.
You could even trickle charge from solar panels if you wish and the market pretty much provides for 13.5-13.8VDC trickle chargers in solar panels. It is an easy fit. If you desire to save money on solar panels and such, a 6VDC gel cell with trickle charger could work with the switcher regulator better than an LDO linear device.
+++++++++
I do NOT think the router will use 350-400ma unless you hang something on the USB port 24/7 (One of the best reasons to develop the Tx and Rx direct to the Propeller.) What I read seemed to indicate that without powering an attached USB device, you will likely have less power demand... and maybe much less during quiescent periods.
There are remarks at OpenWrt of 0.5 to 0.6 watts at 5 volts. Would this be peak demand? 100 to 120ma.
This is where you need the diode to be on the battery side.
Err..where else would I put the diode(s)?
What I have is:
BATTERY----REGULATOR
Propeller
This is fine until the battery voltage goes over 7v when fully charged exceeding the regulator's max input. So I take your suggestion as being:
BATTERY----DIODE----REGULATOR
Propeller
The voltage drop across the diode fixes that issue but now as my battery (which could actually be some other lower voltage battery or a USB supply) voltage gets lower I'm going to run out of headroom for the regulator sooner.
So the diodes(s) fix the immediate issue and make the thing idiot proof against polarity reversal but limits what I can do with the board in future.
No I don't run the router from this. The router still has it's wall-wart. I'm keeping my options open. This Prop board may acquire an EEPROM and be standalone at some point. And I like the idea of the router just looking like a PropPlug so I don't want to bring power over from there.
OK in a TO220 case without heatsink for your cold location
Chuckle...for the past week it has been 30C indoors and my IR thermometer reads 40C everywhere on our balcony! This looks set to continue next week...
Oh yes, I have 30cm of wire carrying the reset. A pull up sound like a good idea.
LDO linear regulators consume significantly extra power when operating in their LDO region.
Nonsense. A linear regulator, LDO or otherwise, is basically a variable resistor that just happens to adopt the resistance value required to drop the input voltage to the required output voltage at the current required by the load.
In the process the regulator burns off energy. W = IV and all that.
Clearly if the input voltage is lowered down to the minimum required for regulation, which just happens to be less for an LDO, then the energy burn rate in the regulator, IV, is also at a minimum.
As that minimum voltage drop V for an LDO is less, then IV is less and the total system is more efficient down there.
I have no idea if there was a primary motivation for making LDOs but clearly they can help suck the last bits of juice out of batteries rather than stopping working before the battery capacity is used.
...have a diode dump a bit of voltage when a small adjustment in voltage is required. It will likely waste less than a linear LDO
Nonsense. All that does is move some of the voltage drop, and hence energy burn, from the LDO to the diode. The energy wasted i.e. efficiency of the whole system is the same.
[QUOTE=Loopy Byteloose;1281607@Cluso
I have purchased a few boost and buck switcher boards that are very inexpensive. These devices are rated at something like 92% efficency, whereas the linear regulators are something around 70%.
LDO linear regulators consume significantly extra power when operating in their LDO region. As far as I can figure, the LDO feature was intended to primarily provide constant voltage in automotive settings.. where there are sudden shifts in load. They are not really a good choice to squeeze extra power out of a battery or to operate in the LDO 100% of the time.
And so, Heater argues that you might as well have a diode dump a bit of voltage when a small adjustment in voltage is required. It will likely waste less than a linear LDO.
[/quote]
LDOs are low dropout regulators. That means they will regulate down to a smaller differential from input to output. They also often waste less quiescent current. They are ideally suited to battery situations. But LDOs can vary significantly in how much minimum voltage they will drop.
+++++++++
I haven't gotten too much into the low power aspect of using these devices yet. But i do have a 12VDC gel cell with trickle charger set up that drops the voltage down to 5VDC via a switcher. That seems like an eventual good fit.
You could even trickle charge from solar panels if you wish and the market pretty much provides for 13.5-13.8VDC trickle chargers in solar panels. It is an easy fit. If you desire to save money on solar panels and such, a 6VDC gel cell with trickle charger could work with the switcher regulator better than an LDO linear device.
+++++++++
I do NOT think the router will use 350-400ma unless you hang something on the USB port 24/7 (One of the best reasons to develop the Tx and Rx direct to the Propeller.) What I read seemed to indicate that without powering an attached USB device, you will likely have less power demand... and maybe much less during quiescent periods.
There are remarks at OpenWrt of 0.5 to 0.6 watts at 5 volts. Would this be peak demand? 100 to 120ma.
I have seen the chipsets for AR9331 quoted as 350mA when transmitting WiFi. This is where the power is being used I think.
This is fine until the battery voltage goes over 7v when fully charged exceeding the regulator's max input. So I take your suggestion as being:
BATTERY----DIODE----REGULATOR
Propeller
The voltage drop across the diode fixes that issue but now as my battery (which could actually be some other lower voltage battery or a USB supply) voltage gets lower I'm going to run out of headroom for the regulator sooner.
Yes, you will. But if your 7.2V LiPo gets below say 4.5V (LDO + Diode)
So the diodes(s) fix the immediate issue and make the thing idiot proof against polarity reversal but limits what I can do with the board in future.
No I don't run the router from this. The router still has it's wall-wart. I'm keeping my options open. This Prop board may acquire an EEPROM and be standalone at some point. And I like the idea of the router just looking like a PropPlug so I don't want to bring power over from there.
Nonsense. A linear regulator, LDO or otherwise, is basically a variable resistor that just happens to adopt the resistance value required to drop the input voltage to the required output voltage at the current required by the load.
In the process the regulator burns off energy. W = IV and all that.
Clearly if the input voltage is lowered down to the minimum required for regulation, which just happens to be less for an LDO, then the energy burn rate in the regulator, IV, is also at a minimum.
As that minimum voltage drop V for an LDO is less, then IV is less and the total system is more efficient down there.
I have no idea if there was a primary motivation for making LDOs but clearly they can help suck the last bits of juice out of batteries rather than stopping working before the battery capacity is used.
Nonsense. All that does is move some of the voltage drop, and hence energy burn, from the LDO to the diode. The energy wasted i.e. efficiency of the whole system is the same.
Yep, that's correct.
It means that with lower currents and lower input voltages, the power dissipation is significantly less, as well as lower operating current, means smaller packages can be used with/without smaller heatsinks.
Nonsense. A linear regulator, LDO or otherwise, is basically a variable resistor that just happens to adopt the resistance value required to drop the input voltage to the required output voltage at the current required by the load.
In the process the regulator burns off energy. W = IV and all that.
Clearly if the input voltage is lowered down to the minimum required for regulation, which just happens to be less for an LDO, then the energy burn rate in the regulator, IV, is also at a minimum.
As that minimum voltage drop V for an LDO is less, then IV is less and the total system is more efficient down there.
I have no idea if there was a primary motivation for making LDOs but clearly they can help suck the last bits of juice out of batteries rather than stopping working before the battery capacity is used.
Nonsense. All that does is move some of the voltage drop, and hence energy burn, from the LDO to the diode. The energy wasted i.e. efficiency of the whole system is the same.
It may all be nonsense to you, but when one reads the curves in the PDFs for specific LDO regulators, the problem becomes clear.... quiescent curve may go up 200-300%.
If you desire to claim that the device is merely a variable resistor, go right ahead. But it seems obvious that something else is actually in use.
Take a look at the LM2940 chart 17, where the quiescent current can jump from 40ma to 140ma in the LDO region for a full 1 amp load. Or from 20ma to 45ma for a 500ma load.
Of course, it you use a 1 amp device for 100ma load, you might get a much more reasonable curve. But I'd rather use a smaller extremely low quiescent linear regulator in a 250ma or less context and conserve more battery power.
Linear my Aspic.
LDO regulators are excellent for automotive applications where starting the car, honking the horn, or turning on the head lamps may otherwise cause the microcontroller to reset due to a sudden brown-out transient.
They might be used with non-rechargible batteries, but the newer NiMH and Li-Ion cells actually need to cut out at a particular voltage to avoid damage from excessive discharge. So something more thought out than LDO needs to be considered.
For instance 3.7V Li-Ion shouldn't discharge below 3.0v, so having a 7.4VDC Li-Ion with an 5VDC LDO regulator may actually do serious harm to the cell, where as a 7805 might just quit prior to damage.
But having looked at all this nonsense, I have simply gone back to Lead acid... which seems to ignore abuses of all sorts, and using switching regulators to optimize power. NiCad remain another battery relatively insensitive to excessive discharge. I do admit that my Lead acid solutions are not mobile though.
heater,
What OpenWRT cpu are you compiling for? Is it a Ralink MT7620N?
A new router Vonets Mini300 has just arrived. It is based on the Mediatek MT7620N (plus RAM and FLash). Has 1 Ethernet, WiFi and microUSB for power. Its quite a bit smaller than the WR703N box. It runs OpenWRT so I am interested to see if it is the same CPU/Router as yours. The MT7620A is an FPGA pkg with up to 256MB DDR2 RAM.
It may all be nonsense to you, but when one reads the curves in the PDFs for specific LDO regulators, the problem becomes clear.... quiescent curve may go up 200-300%.
If you desire to claim that the device is merely a variable resistor, go right ahead. But it seems obvious that something else is actually in use.
Take a look at the LM2940 chart 17, where the quiescent current can jump from 40ma to 140ma in the LDO region for a full 1 amp load. Or from 20ma to 45ma for a 500ma load.
Of course, it you use a 1 amp device for 100ma load, you might get a much more reasonable curve. But I'd rather use a smaller extremely low quiescent linear regulator in a 250ma or less context and conserve more battery power.
Linear my Aspic.
LDO regulators are excellent for automotive applications where starting the car, honking the horn, or turning on the head lamps may otherwise cause the microcontroller to reset due to a sudden brown-out transient.
They might be used with non-rechargible batteries, but the newer NiMH and Li-Ion cells actually need to cut out at a particular voltage to avoid damage from excessive discharge. So something more thought out than LDO needs to be considered.
For instance 3.7V Li-Ion shouldn't discharge below 3.0v, so having a 7.4VDC Li-Ion with an 5VDC LDO regulator may actually do serious harm to the cell, where as a 7805 might just quit prior to damage.
But having looked at all this nonsense, I have simply gone back to Lead acid... which seems to ignore abuses of all sorts, and using switching regulators to optimize power. NiCad remain another battery relatively insensitive to excessive discharge. I do admit that my Lead acid solutions are not mobile though.
Actually Loopy, both regulators will continue to pass power as the voltage drops below the threshold. They just go out of regulation, so they don't protect the battery from over-discharging at all.
Actually Loopy, both regulators will continue to pass power as the voltage drops below the threshold. They just go out of regulation, so they don't protect the battery from over-discharging at all.
I had suspected that, but the LDO would hit the battery with greater impact when it reaches lower voltage. Obviously a cutoff circuit is needed.
I do have some 4 pin 3.3VDC linear regulators where the 4th pin is an enable/disable that can be taylored by a voltage divider or a zener to shut off the regulator before the battery is threatened with over-discharge damage. These kind of regulators are available on the open market, but most people only consider the 3 pin devices without shut off.
I personally think the Ni-Mh and Li-Ion are great for devices that yo-yo between charged and discharged, like a cellular phone or a touchpad computer; but not really easy to deploy for many DIY projects.
Solar charging might be a lot easier with a Lead acid cell if you desire a device on a boat.
My whole wifi Propeller setup is a stationary remote, so Lead acid is fine. It sits at an AC mains outlet.
I just want to get rid of the CAT5 or RS422 cable stretched across the room and beyond. But one does have to ventilate the battery box to prevent hydrogen building up. At first I was using Tupperware containers that were tight... not a good idea.
+++++++++
I am spending the day trying to figure out how to compile pi-propeller-load for the AR7xxx processors. Heater obviously knows far more about handling GPIO in Linux on SOCs that I do. This project has been very informative.
I am extremely happy with the MR3020, so I am not looking for an even smaller device with more resources.
Comments
From what I have read, the serial is ttl on the MR3020 just like the WR703N. Perhaps you have the tx and rx wired the wrong way. The easiest way to check is to use the propplug and link the grounds and then connect each wire (TX first as this should be it) to the RX on the propplug (with PST or another serial program running on the pc connected to the usb propplug). You should then see the normal booting output stream. Once this works, then it is easy to connect the RX to the TX on the propplug.
If you are worried, use a series 1K resistor between the connections Tx & RX.
Don't forget it is 115,200 baud - maybe just check the writeup on the binary in case it is different but I expect it to be the same.
The OpenWRT entry for the MR3020 recommends Tx have a pull-up to 3.3v. with some discussion about a voltage divider of two 5.6k resistors and a cap connected to the before going to the Tx output.
On the other hand, the OpenWRT entry for the WR703N doesn't mention anything similar.
It does seem as if such a circuit my be for protection of Tx output as it reaches the outside world.
++++++++++++++
I may have a poor ground connection at where the PropPlug connects to the Propeller Protoboard, or in the cable construciton. That would explain what the wired loopback performs flawlessly, but the actual communication doesn't.
I'll keep trying. I have tried reversing the Tx and Rx and fooling with a separate ground. I did look like I got momentary success, but I am not sure. I had to revert to checking that I didn't damage any of the serial ports involved, and now am trying again.
Why?
Well, I was up in the middle of the night building myself a Propeller circuit onto a proto board.
When the regulator circuit was done I tested it by itself. Poof the smoke came out.
This morning I replaced the regulator. Again poof, the smoke came out. (I really must get a current limited power supply).
Then I see the error of my ways. Some pads on the board under the regulator tab that I thought were not connected to anything, well, they were. I had forgotten a few changes of plan along the way.
Luckily there was one regulator left. Yay it works!
Only this thing is only good for 7 volts max input. So the smoke may come out again when I charge the 6 volt NiMh battery pack I want to power it with.
Anyway I now have a little board to connect to a router. No EEPROM, who needs one when the router can load code to RAM on start up? Running nicely at 96MHz.
That all might have to wait for another day...
Fantastic news. And yes, no eeprom required.
For the regulator, just put a couple of 1N4001-1N4004 diodes in series or a bridge. Each of those will drop 0-6-0.7V.
I love the phone chargers - 5V @ 500mA or 1A are great power supplies for projects these days.
That pretty much asserts the two milestones solved.
+++++++++++++++++++++++++++++++++++++++++++++++++
Congrats.
May we have some more details... How did you get the GPIO working -- wiring and software solutions?
And how did you manage not having the Serial Console interferring with programming?
It seems I came down with a summer cold, so I just slept most of yesterday after determining everything in my set up was working right. I may get back to it all later today.
I am still interested in getting my own complete RS232 without using the USB port.
Finally, I have my Tx and Rx working with Tachyon Forth on /dev/ttyATH0. The struggle is over.
Now I need your mentoring to get the GPIO to Reset working. I will proceed to build an interface, but I am not sure how you modified code.
I am extremely happy with this as it leaves the USB port available for all sorts of other uses -- mass storage, a USB to printer, a 3G/4G modem, or a USB powered bridge to multiple devices.
~~~~~~~~~~~~~~~~~~~~~~~
It appears that I had two problems working together -- bad soldering and reversed construction.
A. The header I soldered into the MR3020 suffered from a cold solder joint on the Vss and maybe the Vdd as well. So the Tx and Rx worked nicely in a loop-back, but not reliably when connected to the Propeller Protoboard.
B. I need to reverse the Tx and Rx. The configuration that work straight through with the USB2SER was not appropriate -- needed a cross over.
++++++++
Apparently the cold solder joint was not so bad. The USB2SER worked with it when connected directly to the MR3020. I did seem to have some success early when reversing the Tx and Rx, but was very tired and confused. So I went into 'get some rest, double check everything, and clean up problems' mode
I had noticed that the cable was only delivering 3.01VDC between Vss and Vdd. It now delivers a nice 3.30VDC.
I continue to have the 3.3VDC provide a pullup to Tx at the MR3020. It may or may not be possible to eliminate this.. but I will stay with this as it works fine.
______________ happy, happy...
I have now installed a 90 degree 4 pin header and drilled a hole in the side of the case for a cable to go through. These measures will allow me to close up the case and have an interface to a Proeller Protoboard 24/7.
I can program a Prop from a router:
Sorry I was a bit misleading in my previous post, that "Propeller Version 1 on /dev/ttyUSB0" was actually me getting my hand made Prop board working for the first time connected to a PC via PropPlug.
The above is from my D-LINK connected to the Prop over the console UART. Really, honest, no joke this time:)
Note:
1) This propeller-load has a new option to allow use of GPIO as a Propeller reset. "-Dreset=gpio"
This is currently hard wired for my GPIO 11, the blue LED. The LED flashes satisfyingly when programming but it also has a bad habit of flashing, sending a Prop reset, when the router is rebooted.
2) I select the port manually with "-p/dev/ttyS0"
3) I Simply disabled console on the UART as described on the openwrt.org pages.
TODO:
a) Get this code into github.
b) Add some option to select which GPIO pin. I'm thinking of doing it like this: "-Dreset=gpio,11"
c) Build it for your routers if you like.
d) This only supports simple binaries as produced by Spin so far. I need to get all the features for C executables working.
I though about adding some diodes to drop the voltage. A bridge would be nice as it's a bit haphazard which way my power connector gets plugged in! But I hate to throw away volts when powering from a battery. Isn't there an LDO regulator that can tolerate more than 7 volts? I might just wing it, charge the battery and see if the reg blows:)
Loopy, As far as wiring goes:
I have direct connections from tx/rx on the D-Link UART to tx/rx on the Propeller. They may actually be reversed I'm not sure any more.
I have a direct connection from the pin on the blue LED on the D-LINK to reset on the Propeller. Just happens that when the LED is off that pin is pulled up to 3.3v. When the LED is on it get's pulled down to 0.65 volts, low enough to reset the Prop.
The router ground is of course connected to my Propeller ground.
I basically have four wires coming out of the router that end in a PropPlug style connector.
For the software:
This is a long story....
The propeller-loader comes from the loader supplied as part of the propgcc sources. I had previously hacked this around so that it used a GPIO for reset when used with the UART on a Raspberry Pi. Some of those changes made it back into the upstream propgcc source repository.
I have hacked this around a bit more to build it for the routers.
Actually building it just now is a pain. In summary:
a) Fetch the entire propgcc source code from it's repo.
b) Build propgcc for you PC, say Debian.
c) Build the loader, which requires propgcc, for the router!
Hopefully this can be streamlined a bit when I get the new changes back into propgcc.
Followed the instructions here: http://wiki.openwrt.org/doc/recipes/terminate.console.on.serial (First method)
I knew Heater had been dealing with the GPIO to reset on the Raspberry Pi previously and appreciate him generously sharing this info ... especially after all the gripes I've made about the R-Pi. Thanks again. and again.
I intend to take an NPN transistor, emitter to ground, collector to the Propeller reset, and the base to the GPIO through a current limiting resistor somewhere. I don't really desire to have another flashing LED or to borrow one.. though that is a bit economical.
My GPIO numbers are likely to not be the same, so it may be time for me to actually compile a binary. That's okay with me.
+++++++++++
Status to date.
Vdd is actually 3.32VDC, not the previously reported 3.30VDC.
Tx and Rx are working nicely with Tachyon Forth. I changed to 57600 8n1 because I wanted to verify that Minicom would actually change the baud rate to something other than the default of 115200 8n1. It seems that all of Minicom functions may work -- more than most user will want.
Propeller-load still works nicely on /dev/ttyUSB0. I am not going to try the /dev/ttyATH0 until I have a GPIO to reset solution in place in hardware and software.
To Do:
a. Get a direct wifi solution working correctly.
So far I have made a mess of directly using LuCi and SSH via wifi on my MR3020, so all the contact with the Propeller for loading binaries and for using Tachyon have been through LAN.
I need to be able to log in to SSID=DogHouse and deploy both SSH and LuCi. So far I can't seem to identify the blockage. I am using the configuration that I have previously posted.
I would like to disconnect the LAN cable entirely and have Wifi be the only means of communication to the Propeller and only means of downloading the binary.
b. Build the GPIO to Reset interface.
This should be quite easy. We discussed the alternative previously and I have just been holding off until I was sure the Tx and Rx were fine.
c. Leaving everything on for 24 hour burn in.. just to be sure my build is now stable.
d. Locate and read the original propeller-load C code in order to have some idea of what is involved in modifying it.
With regard a UART and GPIO as a Propeller reset signal, the Raspi is just one of thousands of SoCs that can do that. The code for the loader in propgcc identifies this feature as as raspi specific. I have to make it more general.
Why do you want that NPN transistor in between your router and your Propeller? If the two are in close proximity it is hardly necessary. It serves to invert the signal which would mean adding another configuration option to the loader to cater for that. If the two are not in close proximity I'd be thinking about opto isolating the thing. And the serial lines.
I will make the GPIO number a user option somehow.
This might take some time...
Just for completeness I had to solder a LED to pin 1 of the Propeller connected to my router.
I mean, you are not there yet if you can flash a LED, right?
So here we go, top to bottom:
heater@debian:~$ cat dlink-test.spin CON _xinfreq = 6_000_000 _clkmode = xtal1 + pll16x PUB LedOn dira[0] := 1 ' Set P0 to output repeat outa[0] := 1 ' Set P0 high waitcnt(clkfreq / 2 + cnt) outa[0] := 0 ' Set P0 low waitcnt(clkfreq / 2 + cnt) heater@debian:~$ openspin -b dlink-test.spin Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor. Compiled on Oct 21 2013 Compiling... dlink-test.spin Done. Program size is 60 bytes heater@debian:~$ scp dlink-test.binary root@192.168.2.1:/tmp root@192.168.2.1's password: dlink-test.binary 100% 60 0.1KB/s 00:00 heater@debian:~$ ssh root@192.168.2.1 root@192.168.2.1's password: BusyBox v1.22.1 (2014-07-19 03:31:09 EEST) built-in shell (ash) Enter 'help' for a list of built-in commands. _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M ----------------------------------------------------- BARRIER BREAKER (Bleeding Edge, r41737) ----------------------------------------------------- * 1/2 oz Galliano Pour all ingredients into * 4 oz cold Coffee an irish coffee mug filled * 1 1/2 oz Dark Rum with crushed ice. Stir. * 2 tsp. Creme de Cacao ----------------------------------------------------- root@OpenWrt:~# cd /tmp/ root@OpenWrt:/tmp# ./propeller-load -Dreset=gpio -p /dev/ttyS0 -r -v dlink-test.binary Propeller Version 1 on /dev/ttyS0 Loading dlink-test.binary to hub memory 60 bytes sent Verifying RAM ... OKFor some reason this did not work the first hundred times I tried it. I was beginning to think openspin or propeller-load had some issue with "wrong-endian" processors, not an unknown happening in cross-platform code.But yay, the LED flashes.
Initially I had no LED. I was checking for the pin going up and down with a multi-meter. Nothing was showing...
Now I have the LED I see it flashes, the programming works.
But when I put the ground of the multimeter onto the ground of my board or the router, poof it resets the Prop.
So of course I never saw anything happening without the LED.
My Propeller board is battery powered. The router has the normal wall-wart.
What to do?
An LDO regulator is still going to waste the volts because they are not switchers. I think when you charge the LiPo you will get ~7.2V which is probably ok with your reg if it says 7V but maybe not if it says 6V which is common. There are LDOs with higher V.
Not sure about your grounding problem. Will have to digest later today.
You have truly made great progress. I just haven't had the time yet.
Loopy,
If you use a transistor you will require a 10K or more pulldown to keep the transistor off. But as heater said, the proploader will now need to invert the reset.
GTG. I will try and get on during the day to check in.
Yes, I was thinking a pull-down resistor in the base would be needed. Since the two GPIO I am looking at already have 10K pull-down resistors attached, I failed to mention them.
I am beginning to ponder the idea of not modifying the existing propeller-loader code, which works beautifully and instead writing a serial driver of some sort to go in /dev, say ttyXXX0 for 'experimental' or ttyPAR0 for 'Parallax'.
It may be simpler to go with Heater's modified propeller-loader just because it is already evolved, but I am curious.
Sure, the LDO will drop volts and being linear will waste energy in doing so. So the diode(s) make no difference by way of efficiency.
It was the voltage head room I was thinking about. What happens when I want to run this board of different batteries or 5v from USB.
This reg is spec'ed ay 7v max so I'll risk it as it is and look out for some higher voltage ones. I'm sure one of the ones I blew was good for 15 volts. If only I could remember what it was now...
Should we have a pull up and a cap to ground on the reset or something? I had this kind of problem with my last proto board creation, it would reset when the fridge in the house started up!
Loopy,
I thought about making a custom driver for this situation way back when I started with the Raspberry Pi version.
Thing is you have to provide that driver for every possible architecture and kernel version, or hope your users can compile it from source. The kernel will not load modules built against the wrong kernel version. You need to provide instructions to install it, to get it loaded into the kernel, to configure it. It's like that USB serial driver for Windows problem but a thousand times worse.
Such a driver would make sense if it's features, GPIO as DTR/RTS, were generally useful and in demand, then it would eventually end up in the main line kernel and everyone would have it.
On balance I think we are as well to use the nice easy, portable, user space interface (/sys) that the kernel developers have provided for us. Everyone has that already.
As for "...not modifying the existing propeller-loader code...", most of the code I made for this has been in the upstream propgcc sources already for a long time. These recent changes are very minor and hopefully will find their way into propgcc, then everyone will have that.
What sort of reg are you using? PN and case style. Are you also running the router from this? If you are just powering the prop from this supply, it might be easier to bring the 5V from the router (or 3V3 and a 10uF tantalum on the prop power side).
If you are powering the router also, then from what I recall, the router could use up to 350mA plus say 50mA for the prop gives 400mA. Now, if you have 7.2V (fully charged LiPo) and you need to drop to 3v3 that is 7.2-3.3 = 3.9V @ 400mA = 1.56W which is probably OK in a TO220 case without heatsink for your cold location. If there is a longish wire (to pickup noise) then a 10K pullup is advisable. A cap to ground should not be necessary unless there is a lot of noise. Then only a low value 1nF because this will slow the reset rise time. It will not do anything if you have it connected directly to the AR9331 GPIO unless you put a serial resistor in the line.
For my prop designs I now put in a 10K pullup using a 4x10K resnet smt (reset, sda, scl, wp for eeprom)
I added some build instructions for OpenWRT in the file BUILD-OPENWRT.txt there.
Thanks... trying to sift thru GIT hub to comprehend what's what. This is one of my weaker skill sets.
@Cluso
I have purchased a few boost and buck switcher boards that are very inexpensive. These devices are rated at something like 92% efficency, whereas the linear regulators are something around 70%.
LDO linear regulators consume significantly extra power when operating in their LDO region. As far as I can figure, the LDO feature was intended to primarily provide constant voltage in automotive settings.. where there are sudden shifts in load. They are not really a good choice to squeeze extra power out of a battery or to operate in the LDO 100% of the time.
And so, Heater argues that you might as well have a diode dump a bit of voltage when a small adjustment in voltage is required. It will likely waste less than a linear LDO.
+++++++++
I haven't gotten too much into the low power aspect of using these devices yet. But i do have a 12VDC gel cell with trickle charger set up that drops the voltage down to 5VDC via a switcher. That seems like an eventual good fit.
You could even trickle charge from solar panels if you wish and the market pretty much provides for 13.5-13.8VDC trickle chargers in solar panels. It is an easy fit. If you desire to save money on solar panels and such, a 6VDC gel cell with trickle charger could work with the switcher regulator better than an LDO linear device.
+++++++++
I do NOT think the router will use 350-400ma unless you hang something on the USB port 24/7 (One of the best reasons to develop the Tx and Rx direct to the Propeller.) What I read seemed to indicate that without powering an attached USB device, you will likely have less power demand... and maybe much less during quiescent periods.
There are remarks at OpenWrt of 0.5 to 0.6 watts at 5 volts. Would this be peak demand? 100 to 120ma.
What I have is:
BATTERY----REGULATOR
Propeller
This is fine until the battery voltage goes over 7v when fully charged exceeding the regulator's max input. So I take your suggestion as being:
BATTERY----DIODE----REGULATOR
Propeller
The voltage drop across the diode fixes that issue but now as my battery (which could actually be some other lower voltage battery or a USB supply) voltage gets lower I'm going to run out of headroom for the regulator sooner.
So the diodes(s) fix the immediate issue and make the thing idiot proof against polarity reversal but limits what I can do with the board in future.
Decisions, decisions...
Anyway. The regulator is an EZ1084CT 3.3 like so: http://www.classiccmp.org/rtellason/chipdata/ez1084ct.pdf. The last in my old collection.
No I don't run the router from this. The router still has it's wall-wart. I'm keeping my options open. This Prop board may acquire an EEPROM and be standalone at some point. And I like the idea of the router just looking like a PropPlug so I don't want to bring power over from there. Chuckle...for the past week it has been 30C indoors and my IR thermometer reads 40C everywhere on our balcony! This looks set to continue next week...
Oh yes, I have 30cm of wire carrying the reset. A pull up sound like a good idea.
In the process the regulator burns off energy. W = IV and all that.
Clearly if the input voltage is lowered down to the minimum required for regulation, which just happens to be less for an LDO, then the energy burn rate in the regulator, IV, is also at a minimum.
As that minimum voltage drop V for an LDO is less, then IV is less and the total system is more efficient down there.
I have no idea if there was a primary motivation for making LDOs but clearly they can help suck the last bits of juice out of batteries rather than stopping working before the battery capacity is used. Nonsense. All that does is move some of the voltage drop, and hence energy burn, from the LDO to the diode. The energy wasted i.e. efficiency of the whole system is the same.
I have purchased a few boost and buck switcher boards that are very inexpensive. These devices are rated at something like 92% efficency, whereas the linear regulators are something around 70%.
LDO linear regulators consume significantly extra power when operating in their LDO region. As far as I can figure, the LDO feature was intended to primarily provide constant voltage in automotive settings.. where there are sudden shifts in load. They are not really a good choice to squeeze extra power out of a battery or to operate in the LDO 100% of the time.
And so, Heater argues that you might as well have a diode dump a bit of voltage when a small adjustment in voltage is required. It will likely waste less than a linear LDO.
[/quote]
LDOs are low dropout regulators. That means they will regulate down to a smaller differential from input to output. They also often waste less quiescent current. They are ideally suited to battery situations. But LDOs can vary significantly in how much minimum voltage they will drop.
I use this part when I have a high input voltage and require 5V and < 500mA out... R-78E5.0-0.5 5V 28V 0.5A
http://www.digikey.com/product-search/en?lang=en&site=us&keywords=R-78E5.0-0.5&x=0&y=0
Its a switcher in a largish similar TO220 package.
I have seen the chipsets for AR9331 quoted as 350mA when transmitting WiFi. This is where the power is being used I think.
Perhaps this http://www.digikey.com/product-detail/en/MCP1702-3302E%2FTO/MCP1702-3302E%2FTO-ND/1098463
would be a better alternative since the prop will not use a lot. Oh well, cannot be right all the time. Its cold here (3C overnight) but that wont last long. Definitely a good idea.
It means that with lower currents and lower input voltages, the power dissipation is significantly less, as well as lower operating current, means smaller packages can be used with/without smaller heatsinks.
Actually what is a reasonable voltage to let a 5 cell 1600mAh NiMh battery discharge down to?
BTW While 10K pullup on reset may not be your problem, its a better solution.
It may all be nonsense to you, but when one reads the curves in the PDFs for specific LDO regulators, the problem becomes clear.... quiescent curve may go up 200-300%.
If you desire to claim that the device is merely a variable resistor, go right ahead. But it seems obvious that something else is actually in use.
https://www.futurlec.com/Linear/LM2940CT-5.shtml
Take a look at the LM2940 chart 17, where the quiescent current can jump from 40ma to 140ma in the LDO region for a full 1 amp load. Or from 20ma to 45ma for a 500ma load.
Of course, it you use a 1 amp device for 100ma load, you might get a much more reasonable curve. But I'd rather use a smaller extremely low quiescent linear regulator in a 250ma or less context and conserve more battery power.
Linear my Aspic.
LDO regulators are excellent for automotive applications where starting the car, honking the horn, or turning on the head lamps may otherwise cause the microcontroller to reset due to a sudden brown-out transient.
They might be used with non-rechargible batteries, but the newer NiMH and Li-Ion cells actually need to cut out at a particular voltage to avoid damage from excessive discharge. So something more thought out than LDO needs to be considered.
For instance 3.7V Li-Ion shouldn't discharge below 3.0v, so having a 7.4VDC Li-Ion with an 5VDC LDO regulator may actually do serious harm to the cell, where as a 7805 might just quit prior to damage.
But having looked at all this nonsense, I have simply gone back to Lead acid... which seems to ignore abuses of all sorts, and using switching regulators to optimize power. NiCad remain another battery relatively insensitive to excessive discharge. I do admit that my Lead acid solutions are not mobile though.
What OpenWRT cpu are you compiling for? Is it a Ralink MT7620N?
A new router Vonets Mini300 has just arrived. It is based on the Mediatek MT7620N (plus RAM and FLash). Has 1 Ethernet, WiFi and microUSB for power. Its quite a bit smaller than the WR703N box. It runs OpenWRT so I am interested to see if it is the same CPU/Router as yours. The MT7620A is an FPGA pkg with up to 256MB DDR2 RAM.
I had suspected that, but the LDO would hit the battery with greater impact when it reaches lower voltage. Obviously a cutoff circuit is needed.
I do have some 4 pin 3.3VDC linear regulators where the 4th pin is an enable/disable that can be taylored by a voltage divider or a zener to shut off the regulator before the battery is threatened with over-discharge damage. These kind of regulators are available on the open market, but most people only consider the 3 pin devices without shut off.
I personally think the Ni-Mh and Li-Ion are great for devices that yo-yo between charged and discharged, like a cellular phone or a touchpad computer; but not really easy to deploy for many DIY projects.
Solar charging might be a lot easier with a Lead acid cell if you desire a device on a boat.
My whole wifi Propeller setup is a stationary remote, so Lead acid is fine. It sits at an AC mains outlet.
I just want to get rid of the CAT5 or RS422 cable stretched across the room and beyond. But one does have to ventilate the battery box to prevent hydrogen building up. At first I was using Tupperware containers that were tight... not a good idea.
+++++++++
I am spending the day trying to figure out how to compile pi-propeller-load for the AR7xxx processors. Heater obviously knows far more about handling GPIO in Linux on SOCs that I do. This project has been very informative.
I am extremely happy with the MR3020, so I am not looking for an even smaller device with more resources.