Every time I hear about your mini/mainframe my stomach churns, what a shame.
On the bright side perhaps today you have more computing power than that big old machine under your camera lens. And it still has a serial port!
Me to
I designed and sold boards (2* Z8 micros and an Xilinx FPGA) that plugged into the bus and added up to 16 serial ports per board. One of my customers had 128 serial ports with 100's of terminals scattered throughout Oz connecting via stat muxes and 9600 baud leased lines.
That Vonets looks really tiny and sweet. Hope you can get OpenWRT up on it.
I am communicating with Vonets about having them built with 64MB RAM & 16MB FLASH..... Shhhh
Meanwhile I've been to Partco and blown my entire months pocket money on components to replenish my parts bucket a bit.
What I'd like to do is get my Prop/router system back to the state where it was resetting the Prop whenever I touched the multimeter to it's ground or pulled the plug on my soldering iron. Then proceed with whatever advice you have about decoupling and such.
Today's component haul includes:
All the caps and resistors you recommended, and a few others. The tants and resistors are all SMD, 100's of them. I decided it was time to catch up with 1980's technology! The electrolytics are all low ESR.
A selection of 3.3v regulators. I'm curious to try and measure their quiescent currents and see if any of them perform as Loopy suggests at low input voltages and if that is really an issue.
A graphical LCD panel. 128 x 64 in blue. My router/Prop needs a status display does it not?
A new model B+ Raspberry Pi. Sorry Loopy. Not relevant here except they do run OpenWRT. I can now recycle one of my old Pis for OpenWRT experiments.
A bunch of misc. other stuff including a neat jewelers loupe with a built in white LED. Great toy. And the sharpest tweazers I have ever seen.
Seems to me it would be just as easy to weld surface mount resistors and caps between the holes on the proto board I've got as using through hole resistors. I hope the 0805 size fits nicely.
WOW. SMT are easy with the right tools and a bit of practice. If I had known you were going smt I probably could have helped as I have a good source here. I am now mainly using 0603s.
Yes, your 0805s should fit between 0.1" pads.
Would you like to post a pic of your setup. Probably you should just grab the 3v3 from the router for the prop (or 5V and a 3V3 reg).
I find the jewellers loupe is a must, especially with my failing eyes, even with my glasses. If you need to read pns on chips go out into the sun to read - much easier.
One thing I cannot seem to find anymore is a steady hand
Have I mentioned I have a professional oven?
I am communicating with Vonets about having them built with 64MB RAM & 16MB FLASH..... Shhhh
Really? How did you manage that? Perhaps you could bend their ears with the idea of supplying their MINI300s with OpenWRT installed or at least making it very easy to install and that they should make themselves known on openwrt.org. The world would love them and they would shift a few more units.
A few weeks back I bought some LED strips. You know, 16 white SMD LEDs and 4 SMD resistors on a foot long PCB. Only these were "kits". Partco was selling of a bunch of unpopulated PCBs and packets of LEDs with them. For two euro a pop I had to buy a bunch. To my surprise soldering those up was really easy. Even with my poor eyesight, shaky hand and clunky old Weller soldering iron. So SMD it is for me now. As long as I don't need a microscope. I now have the urge to design a masterpiece and get some boards made.
I should really have bought all these Cs and Rs from digikey or some place. Would have been a lot cheaper. But I want then now!
I'll try and get some pictures. It's not easy with the crappy camera on my phone. Needs a lot of light and a steady hand. The lens is so scratched it's foggy all the time.
I might bring 5v over from the router. As I said I quite like having a PropPlug style connection and battery power for the Prop. But as an experiment...
Amazing, here I am sitting in a darkened room at night and with my new funky loupe with its super bright built in LED I can at least read the values on the 0803 resistors!
Those 0803 are a perfect fit between the holes on my board. And my new super pointy tweezers can get them there easily.
Now I want a camera that can snap what I see through that loupe...
I am communicating with Vonets about having them built with 64MB RAM & 16MB FLASH..... Shhhh
Hmmm..... this might be an interesting project to crowd source. My impression is that the gnomes of ShenZhen would be more than happy to re-purpose something if you have ready cash to buy 10,000 units.
Vonets seems to be a ShenZhen brand. The case is made, so is the board. Employees pretty much have learned the production run.
Just make sure that you have an OpenWrt page on how to and what to do with one. I guess you would have to become one of their 'developers'.
Tomorrow is my weekend.. then I can get back to fooling with my MR3020. I may even buy a second one.
++++++++++++++++++++++++++
Here is a link to a 'linear voltage regulator with Enable'. Ideal for NiMH and LiIon cells as you can have it automatically shut down when a low voltage is presented (using a couple of resistors as a voltage divider on the enable pin). I guess you might have a potentiometer on the Enable/Inhibit pin to get the exact setting you need, regardless of product variations.
Available in 3.3v, 5.0v, and adjustable. I am sure there are others out there
That's a nice regulator you have found there Loopy. With it's cut out, high input voltage tolerance, reverse input protection and low quiescent current.
Interestingly it's drop out voltage for 3.3v output is 1.3v. Which does not see so low by comparison to the output voltage. For 1.8v the drop out is 2.7v!
It's quiescent is a nice low 10ma at a half amp load. Not as good as some though. A 130uA for a 1ma load. But 130uA quiescent is more than a sleeping Propeller (I think) which might waste power if you want to build a real low power Propeller circuit.
Details, details, you have gotten me diverted into looking at all kinds of details. Before you mentioned the possibility of low efficiency in the drop out region I was quite happy to weld any old regulator in there that did not actually oscillate!
At first I got into the idea of using comparator chips and an input pin to deal with a low voltage cutout, but this seems more useful in many instance. The only real problem is to determine a reliable cut off Voltage and to have the means to properly set it.
OK Cluso, here are pics of the top and bottom of my little hand wired Prop board that is connected to my d-link.
Sorry they are really bad, the camera on my old Galaxy S is pretty useless.
Note the almost complete absence of bulk capacitance. On the battery side we have 100nF and on the 3.3v side of the reg only 10uF!!. There are two 100nF caps across the Prop power pins.
The white wires are my Prop Plug style link to the d-link. Those wires are about a foot long. Only Tx, Rx, reset and GND. There is 100 ohms in series with the reset line on the board and reset has a 10K pull up. Spot the 0803 SMD resistors.
I have removed the capacitor from reset to ground for now.
That board is a top plate for a Raspberry Pi but as I now have a new Model B+ Pi I this has become redundant so wound up as my d-link test board. The thing would easily fit in the air space in the d-link box if need be.
Anyway. The issue is that touching the ground on that board or the d-link wih a multi-meter probe causes the Propeller to reset. Or pulling the plug on my soldering iron.
Puling out the Prop Plug connection to the d-link is OK but plugging it back in causes a reset.
With the 100nF on reset it gave the appearance of being solid.
What to do?
Edit: You can just about see that is 6 meg xtal. We are running at 96MHz.
openspin does actually run and compile Spin to binaries on my d-link under OpenWRT!
root@OpenWrt:/tmp# ./openspin dlink-test.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.70 Compiled on Jul 30 2014 13:23:00
Compiling...
dlink-test.spin
Done.
Program size is 60 bytes
root@OpenWrt:/tmp# ls -l dlink-test.binary
-rw-r--r-- 1 root root 60 Aug 1 10:22 dlink-test.binary
root@OpenWrt:/tmp# md5sum dlink-test.binary
39b2938680541ad82594698ac5a21652 dlink-test.binary
That md5sum of the binary is the same as produced by openspin on the PC so everything is working so far.
To get this working one has to find the libstdc++ library for OpenWRT. It is not included in the box out of the box, err...if you see what I mean, at least not for my d-link. Luckily there was one built when I built the OpenWRT firmware image from sources:
So, the prop can be the terminal (with kbd + video attached), edit and compile, then download which will reset the prop and download the code. As I said, WOW!
It may be just another Linux box but in the past I have had a lot of trouble building software for strange architectures and OS installations, such as.
1) Data alignment issues. Not all processors like 16, 32, 64 bit types stored at addresses that are not 16,32, 64 bit aligned. Intel x86 does not care so many authors don't bother to check if they have problems like that.
2) bigendian vs little endian issues. Again most code is developed on x86 and authors don't take care their code works on other opposite endian machines.
3) Libraries. OpenWRT uses uclibc rather than the normal GCC standard C library. That has caused issues in the past. Different library versions have been known to be incompatible. And so on. Luckily these programs don't use any weird libraries that OpenWRT does not have at all.
4) Creating the required cross compiler tool chains has been a royal pain sometimes.
And so on...
I give full credit, top marks, to our Propeller tool builders. They made very cross platform friendly code with nice and easy build systems. There were a couple of alignment issues in openspin that showed up when I was cross-compiling it with Emscripten, in order to translate it into JavaScript to run in the browser, but Roy fixed those soon enough.
I do like the Prop as a terminal to the router idea. Have to take care that when you edit, compile and then download it still works as a terminal!
This link seems to clearly help me with installing the tool chain to cross-compile the MR3020 (and likely the R703N) in Debian.
I gave up Ubuntu and Mint awhile back. This may be handy for some users. I found that Mint seemed to lack a good example for a MIPS cross-compile, but my searches may have been flawed. As usual, there is always something in Ubuntu.
Getting very near to creating a binary for pi-propeller-load. And maybe more, as Heater keeps moving ahead.
+++++++++++++++
The Kaohsiung Gas Fire.
Yes I live in Kaohsiung and we had a large explosion and gas fire last night. It wasn't my neighborhood. I did pick it live up on the late night news, but the government seemed to just be letting it burn out at that point.
We had a similar event about a decade or so. Kaohsiung is the center of a major petro-chemical industry that produces about one-third of the world's plastic. We also have a major shipping port and major steel industry. Altogether it is a big city at about 1.2 million.
So much for clear... Trying the above mentioned link didn't work. I have no idea how to get a MIPS device to cross-compile in Debian Wheezy.
I tried, but it wanted to load older, unsupported versions of GCC and G++. And I was reluctant to try to reach back into older repositories as I don't want another broken Apt-get.
I did find a document in the Synaptic Package Manager - installation-guide-mips and have even located the directory where it all is and looked at the html.
Get some stuff you need for building anything much, not just OpenWRT:
$ sudo apt-get update
$ sudo apt-get upgrade # N.B. They did not say do this but I always do before
# I start anything major like this
$ sudo apt-get install git-core build-essential
Get the subversion source code management system:
$ sudo apt-get install subversion
Get the openwrt source code from the their git repository:
$ git clone git://git.openwrt.org/openwrt.git
Get the "feeds" (I still have no idea what the "feeds" are):
$ cd openwrt
$ ./scripts/feeds update -a
$ ./scripts/feeds install -a
Do some preparation of the toolchain build system:
$ make defconfig
$ make prereq
Configure which architecture you want to compile everything for, and a billion other options:
$ make menuconfig
I have no idea why they instruct one to install subversion as the don't seem to use it. These instructions used the git source code management system. Still it's good to have for when you want to fetch the propeller-loader sources.
I did not use sudo as I don't have it set up here. I did all this as root.
Now, The make menuconfig step will present a textual menu system that you can navigate to set all the billions of options that are available. I only set two things there that specify the architecture of the d-link. All the defalts for everything seemed good to go.
When you get to that menu screen report back progress:)
Edit: What I describe here gets you the very latest "bleeding edge" source code. As that is under development it may well be broken at any given time so when we finally get a firmware image it may have problems. But we are pushing frontiers here right?
Good enough.
It was just that the OpenWrt preamble to Buildroot explains how special and modified the cross-compiler is. So I thought it best to go outside of it for something independent to merely compile pi-propeller-load.
Actually, I am relieved that this will work well.
You may think that I am doing anything but keeping it simple; but that is what I am attempting to do.
+++++++++++++
I really hope that you understand that I am NOT trying to compile OpenWrt firmware. I am trying to compile pi-propeller-load as a binary.
++++++++++
My Debian doesn't have sudo either. And I am happier without it. That isn't a problem.
I really hope that you understand that I am NOT trying to compile OpenWrt firmware. I am trying to compile pi-propeller-load as a binary.
Yes I do but:
1) In order to compile a program for your router you need a cross compiler for your router. You also need all the libraries, in their correct versions, and other dependencies that exist on your target router.
2) In order to rebuild the complete router firmware you need a cross compiler for your router
You see where this is going...?
The procedure I laid out above will not only build the router firmware it will also build the cross-compiler and other tools required to rebuild the router firmware!
So basically, when it's done you have every thing you need. Even if you never use the firmware binary it produced. The guys putting this together have solved all the nightmarish problems of setting up a cross compile tool chain for us. Love'em.
Now. The steps I listed get the latest development version or the firmware and the tool chain used to build it, so when you get to the check point I indicated, we will perhaps take a little step backwards to get the sources for the same version that is actually on your router. That way we won't have any compatibility problems. I did not do that, I just used the new firmware version it generated.
After that we do the build itself. This will take some hours to complete.
I'm glad to see you are online just now. Saw the news http://www.bbc.com/news/world-asia-28594693 earlier today and thought - I know someone who lives there. Good to hear you are ok
I'm glad to see you are online just now. Saw the news http://www.bbc.com/news/world-asia-28594693 earlier today and thought - I know someone who lives there. Good to hear you are ok
The news today has certainly been odd. I initially thought this was a gas main rupture, but it appears that gas got into the sewers and ran through a series of explosions over quite a lot of territory. About 25 people killed, and 250 in hospital with cars and motorcycles actually blown up on to roof tops. Plus a lot of fire trucks seem to have ended up falling into the collapse of the sewers due to the explosion.
I can only think of Mexico City sewer explosions being anything like this. The English language newspapers run a day later than the Chinese, so I have only looked at the pictures in the Chinese papers and picked up a little on Taiwan TV.
I have no idea what the source of the gas was. It was in a district near to Kaohsiung's refineries, so it could have been a pipeline leak. Or it could be methane build up due to a design flaw in Kaohsiung's sewer which is relatively new. I haven't gone over to see the area, but there are several blocks of damage.
Things have come to a grinding halt in the router-propeller testing department around here.
I decided to change the regulator on my board having discovered that one of my new ones is the correct foot print for the location on the board where it is supposed to go.
So now, it all works, prop power supply and ground are good, decoupling is in place, current consumption is as expected, propeller-loader loads my LED flashing program successfully. Only one problem. The LED does not flash On removing the LED I see the pin does not output highs and lows, it's just reading about 1v like all the other unused pins.
Guys I think my mind is slipping away from me. Or there is some weird stuff going on here.
Having spent some time rebuilding my Propeller board it did not work. As noted in my last post. Clearly I had made a mistake and had to fix it. Nothing helped, everything checked out but my LED did not flash.
In the cold light of day I had an idea, try loading my Gadget Gangster board from the router. Basically just to check the LED flasher binary actually worked. It did not!
Hmmm...OK then I load the program to the GG via my PropPlug from a PC. It works!
Hmmm...OK then I load the program to my troublesome new board via my PropPlug from my PC. It works!
WTF? My new board was working all the time!
After much swapping of GG vs router and PC vs router it turns out that I really cannot program a Prop with prop-loader from my router any more. Not a GG or my new board.
Now the weird stuff:
1) propeller-load on the router reports that a Propeller was found on /dev/ttyS0 and loading completed successfully "Verifying RAM ... OK". But the program does not run.
2) propeller-loader on the router now cant' find a serial port or connected Propeller when I use -P or -Q options. That used to work. And it contradicts what it says when doing the load!
This run around makes me think Murphy has put some ACID in my tea again....
Hmmm... I guess you see now why I am going so slow. These odd roadblocks are tiring.
Good News... I have installed OpenWrt BuildRoot and am read to compile the pi-propeller-load.
There were a few side tracks. I had to back-track to make my /openwrt directory not available as SuperUser and I have 3 items that I have to locate - ncurses, libz, and awk. There is a big spreadsheet in the OpenWrt page that tells you what you use for Debian, Fedora, OS X, and other Linux distros. Fortunately I had seen that.
More to come later.........
Meanwhile try the mushrooms... some will make you tall, others will make you small.
Having convinced myself that my new board is all wired up correctly and does actually work attention turned back to the router, the prop-loader on it and that serial connection.
Turned out that after power cycling the router every thing works again!
I have no explanation for this, I changed nothing in the wiring, the software is all the same. WTF?
Perhaps, possibly, maybe, something funny happened with the routers UART. You see, thinking about it now I recall that at some point I managed to make a brief short circuit between something and that serial connection. It gave me a little panic as I saw the blue LED on the router make a little flash when it had no reason to. But everything seemed OK so I continued. Maybe that little short knocked the routers UART into some odd state that was reset by the power cycle?
But then how come the prop-loader claimed to be programming successfully?
Clutching at straws here. For now I just have to leave this as an unsolved mystery and move on. Let's see if it ever comes back.
Tired? I'm murderous. The mushrooms are an attractive option just now. Only I found out decades ago that mushrooms and soldering irons mix together in some very strange, interesting but somewhat unproductive ways...
Edit: Sorry I talked of a short to the routers UART. But it must have been the GPIO used for reset. That is what drives the blue LED. I should certainly not be driving the rest output and hence lighting the LED and fighting with the GPIO. But I checked the reset line levels were OK and the LED did flash when programming. So it's still a mystery anyway.
Ugh... yet another flower child. When I lived in Eugene, Oregon; I actually drank beer with Ken Kesey's brother-in-law upon occasion. That was long long ago.. Ken is no longer amongst the living.
Not here to encourge a return of the bad old daze of substance abuses.
And I have actually located under my /openwrt directory, the sub-directory /openwrt/staging_dir ...so I am at about Step 3 of a 7 or more step process.
I am aware of what a PATH environment variable is, but can't quite get the drift of the instructions. Apparently you have gone through all this and had good results.
Let me know what you think I should do next. In the meantime, I will try running a MAKE that should produce a complete MR3020 firmware image. Up to now, I've been using Attitude_Adjustment v12.09 as it was deemed stable. But it appears I have loaded the source for something more evolved... Bleeding Edge.
(I actually have some doubts about anything named Bleeding Edge.)
Ever so slowly I am grasping more and more of what OpenWrt does and why.
Oh my God, you will never believe it. It was the LED. It was the frikkin LED. The LED is dead.
Here is the sorry tale:
1) Whilst rebuilding the board with the new regulator I had to remove and reposition the LED. It was kind of big and in the way.
2) When testing the board the LED did not flash.
3) When probing the pin 1 on the Prop I saw no sign of life. I removed the LED in case of shorts. Still no life on the pin.
4) BUT, that's because I had removed the capacitor on the reset pin so when touching the circuit with the multimeter probes the Prop resets itself. That old issue.
5) After rebooting the router I probed the Prop pin a bit differently, first placing the probes on the board then programming it. This way no spurious reset occurs and the pin wiggles! Yay.
6) As everything was now working it was time to replace the LED. But I decided to find a new smaller one. Sure enough it flashed. At this point we start to think rebooting the router had fixed things.
7) During a visit to the supermarket it occurred to me to test that big old LED. Sure enough it is dead! Something bad happened to it as I was unsoldering and resoldering it. Too much heat perhaps.
So now I have to offer my apologies for posting up this long winded tale of bumbling hardware incompetence. It's amazing how these things can have you chasing geese all around the forest!
About that old spurious rest problem. Now that everything is back to working and I have no capacitor on the reset pin the reset problem persists.
By the way I now have a 330nF tantalum on the regulator input and 33uF tantalum on the output as per the reg's data sheet. There is 100uF electrolytic across the power rails near the Propeller. The new MC33269 regulator is great, much smaller, good for 20v input and only 4ma quiescent.
Now, I noticed that my Gadget Gangster board also resets when connected to my router and touched with a multimeter probe. It's not just my board!
What to do?
Am I likely to see anything interesting with a scope? Not that I have one here but there is a brand new 20MHz CRT scope in the office when I get back on Monday. My boss just had to buy the last analogue scope in the store. It's never been used.
heater, the 100uF cap should be on the input to the reg, not the output - yes i know you are powering with a vattery so probably not doing much unless you have wires of a few inches +. Its normal practice.
As i said, i am not surprised reset occurs when you touch the reset pin - its a high impedance input and the lead will be like an aerial. it could be static induced too. if you want to prove it, try a 1M cap from the lead and touch the reset with the other end of the resistor and most likely it wont reset.
This is basically how capacitive sensing works - ie touch pads.
Well, I have actually been running Make for OpenWrt... but I am not sure which release. I downloaded it earlier today so it just might be the latest.
Now that I have gotten Make going, I can see that this is a necessary step in the process toward cross-compiling separate executables, such as pi-propeller-load.
It all starts out with compiling all the bits of the tool chain from source for the target device. That stuff is needed.
So far, I have done by best to ruin this run of make.
A. I started it at Starbucks on my notebook (Rule One - Never compile Linux on a portable computer -- broke this one)
B. I was worried about wasting batteries, so I turned off the wifi (Rule Two - Never disconnect your service to the web while compiling OpenWrt)
C. I ran out of battery power before I got through it all (Rule Three - Never turn off you computer in the middle of a Make run)
Nonetheless, it seems that OpenWrt has created a rather bullet-proof Build-root, and Linux is more stable than ever.
I got home, and restarted the Make process with the computer on AC power and it is just starting over with the last item of the Make process being redone. It hasn't griped very much about the disconnects, just suggesting I run a check before going ahead.
+++++++++++
I do have to admit that I should have done all this on my 'other computer' -- the Quad 64bit that is supposed to compile faster and is an actual desktop. That still is the wisest way to do a Linux compile (on your best and fastest computer).
But I got the notion in my head that Linux on a wifi router was not going to be anywhere near as formal and compiling a Linux binary for a real desktop. That is just not true. In fact, it may actually be a bit more demanding to do an OpenWrt binary as there are so many different hardware platforms that it seems all the code is kept in source.. nothing can be shared in some sort of joint repository.
_____________
And so, I am learning. And I am finding it deeply rewarding to actually compile a Linux Kernel .. finally.
I have read about how to do so. Thought about it. But this is the first time really through it all. I did some cross-compile for my CubieBoard, but that was actually the boot loader binary -- not the whole Linux OS.
By the way I now have a 330nF tantalum on the regulator input and 33uF tantalum on the output as per the reg's data sheet. There is 100uF electrolytic across the power rails near the Propeller. The new MC33269 regulator is great, much smaller, good for 20v input and only 4ma quiescent.
Now, I noticed that my Gadget Gangster board also resets when connected to my router and touched with a multimeter probe. It's not just my board!
Regulators vary in how much capacitance they desire and where. The only problem that I have seen is that a backflow of current through the regulator might damage in (certainly does with the 7805) and having the cap on the Vout being larger than the one on the Vin creates a potential hazard.
100uf on the Vout side without a diode by-passing the regulator at shut off could do some damage.
========
I wonder if I am going to have similar frustrations with the Reset. Maybe adding a stronger pull-up at the Propeller Reset pin might resolve the 'long wire' problem.
++++++++++
I did purchase a second MR3020 for myself, so I can load the new firmware, verify it is working, and compare with Attitude_Adjustment v.12.09.
Point taken about the 100uF on the reg input not output. What was I thinking?
I'm not following you about the reset line...
I have a 10K pullup on the Propeller reset pin. Is this really such a high impedance as to allow the antenna effects you describe? Without knowing any better my gut says no.
Secondly I'm not talking about touching the reset line, anywhere along its path.
This reset happens when I have the router connected to the board and I touch a multi-meter probe to ground on the board or on the router. In this situation the Propeller reset pin is connected to it's 10K pullup and via 100 ohms to a blue LED and GPIO pin on the router. Via a foot of hookup wire.
The only way I can rationalize this is to think that either the ground is bouncing up or the reset line is bouncing down briefly and triggering a reset. These two things are equivalent as far as the Propeller knows.
Further no matter if this an antenna effect, as you say, or a ground/reset bounce one way to kill it is to short high frequencies to ground with that little cap on the reset pin.
However you indicated that was not a good solution and that I was missing something else here.
So still at the, "what to do?" stage.
@Loopy,
Sounds like you have made good progress.
When you did the "make menuconfig" did you go in there and set the "target" option? And the "subtarget" option if there is one?
If your "make" step completed you should be able to see a firmware package file for your router somewhere. It should have the same name as the binary you fetched from OpenWRT.org and flashed your router with in the first place.
Can you do a $ find -name "*.bin" in your openwrt directory and check what you have got? If it is not there you have the wrong target options set.
If you have the right thing built then you have the toolchain ready and we can get on with building propeller-loader and OpenSpin.
Comments
I designed and sold boards (2* Z8 micros and an Xilinx FPGA) that plugged into the bus and added up to 16 serial ports per board. One of my customers had 128 serial ports with 100's of terminals scattered throughout Oz connecting via stat muxes and 9600 baud leased lines. I am communicating with Vonets about having them built with 64MB RAM & 16MB FLASH..... Shhhh
Yes, your 0805s should fit between 0.1" pads.
Would you like to post a pic of your setup. Probably you should just grab the 3v3 from the router for the prop (or 5V and a 3V3 reg).
I find the jewellers loupe is a must, especially with my failing eyes, even with my glasses. If you need to read pns on chips go out into the sun to read - much easier.
One thing I cannot seem to find anymore is a steady hand
Have I mentioned I have a professional oven?
A few weeks back I bought some LED strips. You know, 16 white SMD LEDs and 4 SMD resistors on a foot long PCB. Only these were "kits". Partco was selling of a bunch of unpopulated PCBs and packets of LEDs with them. For two euro a pop I had to buy a bunch. To my surprise soldering those up was really easy. Even with my poor eyesight, shaky hand and clunky old Weller soldering iron. So SMD it is for me now. As long as I don't need a microscope. I now have the urge to design a masterpiece and get some boards made.
I should really have bought all these Cs and Rs from digikey or some place. Would have been a lot cheaper. But I want then now!
I'll try and get some pictures. It's not easy with the crappy camera on my phone. Needs a lot of light and a steady hand. The lens is so scratched it's foggy all the time.
I might bring 5v over from the router. As I said I quite like having a PropPlug style connection and battery power for the Prop. But as an experiment...
Those 0803 are a perfect fit between the holes on my board. And my new super pointy tweezers can get them there easily.
Now I want a camera that can snap what I see through that loupe...
Hmmm..... this might be an interesting project to crowd source. My impression is that the gnomes of ShenZhen would be more than happy to re-purpose something if you have ready cash to buy 10,000 units.
Vonets seems to be a ShenZhen brand. The case is made, so is the board. Employees pretty much have learned the production run.
Just make sure that you have an OpenWrt page on how to and what to do with one. I guess you would have to become one of their 'developers'.
Tomorrow is my weekend.. then I can get back to fooling with my MR3020. I may even buy a second one.
++++++++++++++++++++++++++
Here is a link to a 'linear voltage regulator with Enable'. Ideal for NiMH and LiIon cells as you can have it automatically shut down when a low voltage is presented (using a couple of resistors as a voltage divider on the enable pin). I guess you might have a potentiometer on the Enable/Inhibit pin to get the exact setting you need, regardless of product variations.
Available in 3.3v, 5.0v, and adjustable. I am sure there are others out there
http://www.onsemi.com/pub_link/Collateral/NCV4276-D.PDF
Interestingly it's drop out voltage for 3.3v output is 1.3v. Which does not see so low by comparison to the output voltage. For 1.8v the drop out is 2.7v!
It's quiescent is a nice low 10ma at a half amp load. Not as good as some though. A 130uA for a 1ma load. But 130uA quiescent is more than a sleeping Propeller (I think) which might waste power if you want to build a real low power Propeller circuit.
Details, details, you have gotten me diverted into looking at all kinds of details. Before you mentioned the possibility of low efficiency in the drop out region I was quite happy to weld any old regulator in there that did not actually oscillate!
http://www.onsemi.com/pub_link/Collateral/AND8239-D.PDF
At first I got into the idea of using comparator chips and an input pin to deal with a low voltage cutout, but this seems more useful in many instance. The only real problem is to determine a reliable cut off Voltage and to have the means to properly set it.
Sorry they are really bad, the camera on my old Galaxy S is pretty useless.
Note the almost complete absence of bulk capacitance. On the battery side we have 100nF and on the 3.3v side of the reg only 10uF!!. There are two 100nF caps across the Prop power pins.
The white wires are my Prop Plug style link to the d-link. Those wires are about a foot long. Only Tx, Rx, reset and GND. There is 100 ohms in series with the reset line on the board and reset has a 10K pull up. Spot the 0803 SMD resistors.
I have removed the capacitor from reset to ground for now.
That board is a top plate for a Raspberry Pi but as I now have a new Model B+ Pi I this has become redundant so wound up as my d-link test board. The thing would easily fit in the air space in the d-link box if need be.
Anyway. The issue is that touching the ground on that board or the d-link wih a multi-meter probe causes the Propeller to reset. Or pulling the plug on my soldering iron.
Puling out the Prop Plug connection to the d-link is OK but plugging it back in causes a reset.
With the 100nF on reset it gave the appearance of being solid.
What to do?
Edit: You can just about see that is 6 meg xtal. We are running at 96MHz.
openspin does actually run and compile Spin to binaries on my d-link under OpenWRT! That md5sum of the binary is the same as produced by openspin on the PC so everything is working so far.
To get this working one has to find the libstdc++ library for OpenWRT. It is not included in the box out of the box, err...if you see what I mean, at least not for my d-link. Luckily there was one built when I built the OpenWRT firmware image from sources:
openwrt/staging_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/lib/libstdc++.so.6.0.19
I simply scp'ed that down to the routers /tmp directory and created a symbolic link to it from the routers /lib directory:
My d-link is now a Propeller Spin development machine!
Mind you, it's Linux and a MIPs cpu.
So, the prop can be the terminal (with kbd + video attached), edit and compile, then download which will reset the prop and download the code. As I said, WOW!
Actually I'm surprised at how easily it went.
It may be just another Linux box but in the past I have had a lot of trouble building software for strange architectures and OS installations, such as.
1) Data alignment issues. Not all processors like 16, 32, 64 bit types stored at addresses that are not 16,32, 64 bit aligned. Intel x86 does not care so many authors don't bother to check if they have problems like that.
2) bigendian vs little endian issues. Again most code is developed on x86 and authors don't take care their code works on other opposite endian machines.
3) Libraries. OpenWRT uses uclibc rather than the normal GCC standard C library. That has caused issues in the past. Different library versions have been known to be incompatible. And so on. Luckily these programs don't use any weird libraries that OpenWRT does not have at all.
4) Creating the required cross compiler tool chains has been a royal pain sometimes.
And so on...
I give full credit, top marks, to our Propeller tool builders. They made very cross platform friendly code with nice and easy build systems. There were a couple of alignment issues in openspin that showed up when I was cross-compiling it with Emscripten, in order to translate it into JavaScript to run in the browser, but Roy fixed those soon enough.
I do like the Prop as a terminal to the router idea. Have to take care that when you edit, compile and then download it still works as a terminal!
I gave up Ubuntu and Mint awhile back. This may be handy for some users. I found that Mint seemed to lack a good example for a MIPS cross-compile, but my searches may have been flawed. As usual, there is always something in Ubuntu.
http://moozing.wordpress.com/2011/04/05/cross-compile-in-debian/
Getting very near to creating a binary for pi-propeller-load. And maybe more, as Heater keeps moving ahead.
+++++++++++++++
The Kaohsiung Gas Fire.
Yes I live in Kaohsiung and we had a large explosion and gas fire last night. It wasn't my neighborhood. I did pick it live up on the late night news, but the government seemed to just be letting it burn out at that point.
We had a similar event about a decade or so. Kaohsiung is the center of a major petro-chemical industry that produces about one-third of the world's plastic. We also have a major shipping port and major steel industry. Altogether it is a big city at about 1.2 million.
I tried, but it wanted to load older, unsupported versions of GCC and G++. And I was reluctant to try to reach back into older repositories as I don't want another broken Apt-get.
I did find a document in the Synaptic Package Manager - installation-guide-mips and have even located the directory where it all is and looked at the html.
But that is NOT about cross-compilers
You are running all around the shop again. If I remember correctly all the steps I took to build openwrt on Debian are spelled out here:
http://wiki.openwrt.org/doc/howto/buildroot.exigence
In short:
Get some stuff you need for building anything much, not just OpenWRT: $ sudo apt-get update $ sudo apt-get upgrade # N.B. They did not say do this but I always do before # I start anything major like this $ sudo apt-get install git-core build-essential Get the subversion source code management system: $ sudo apt-get install subversion Get the openwrt source code from the their git repository: $ git clone git://git.openwrt.org/openwrt.git Get the "feeds" (I still have no idea what the "feeds" are): $ cd openwrt $ ./scripts/feeds update -a $ ./scripts/feeds install -a Do some preparation of the toolchain build system: $ make defconfig $ make prereq Configure which architecture you want to compile everything for, and a billion other options: $ make menuconfigI have no idea why they instruct one to install subversion as the don't seem to use it. These instructions used the git source code management system. Still it's good to have for when you want to fetch the propeller-loader sources.I did not use sudo as I don't have it set up here. I did all this as root.
Now, The make menuconfig step will present a textual menu system that you can navigate to set all the billions of options that are available. I only set two things there that specify the architecture of the d-link. All the defalts for everything seemed good to go.
When you get to that menu screen report back progress:)
Edit: What I describe here gets you the very latest "bleeding edge" source code. As that is under development it may well be broken at any given time so when we finally get a firmware image it may have problems. But we are pushing frontiers here right?
It was just that the OpenWrt preamble to Buildroot explains how special and modified the cross-compiler is. So I thought it best to go outside of it for something independent to merely compile pi-propeller-load.
Actually, I am relieved that this will work well.
You may think that I am doing anything but keeping it simple; but that is what I am attempting to do.
+++++++++++++
I really hope that you understand that I am NOT trying to compile OpenWrt firmware. I am trying to compile pi-propeller-load as a binary.
++++++++++
My Debian doesn't have sudo either. And I am happier without it. That isn't a problem.
1) In order to compile a program for your router you need a cross compiler for your router. You also need all the libraries, in their correct versions, and other dependencies that exist on your target router.
2) In order to rebuild the complete router firmware you need a cross compiler for your router
You see where this is going...?
The procedure I laid out above will not only build the router firmware it will also build the cross-compiler and other tools required to rebuild the router firmware!
So basically, when it's done you have every thing you need. Even if you never use the firmware binary it produced. The guys putting this together have solved all the nightmarish problems of setting up a cross compile tool chain for us. Love'em.
Now. The steps I listed get the latest development version or the firmware and the tool chain used to build it, so when you get to the check point I indicated, we will perhaps take a little step backwards to get the sources for the same version that is actually on your router. That way we won't have any compatibility problems. I did not do that, I just used the new firmware version it generated.
After that we do the build itself. This will take some hours to complete.
Trust in OpenWrt and their efforts to keep up with the merry chase.
I'm glad to see you are online just now. Saw the news http://www.bbc.com/news/world-asia-28594693 earlier today and thought - I know someone who lives there. Good to hear you are ok
The news today has certainly been odd. I initially thought this was a gas main rupture, but it appears that gas got into the sewers and ran through a series of explosions over quite a lot of territory. About 25 people killed, and 250 in hospital with cars and motorcycles actually blown up on to roof tops. Plus a lot of fire trucks seem to have ended up falling into the collapse of the sewers due to the explosion.
I can only think of Mexico City sewer explosions being anything like this. The English language newspapers run a day later than the Chinese, so I have only looked at the pictures in the Chinese papers and picked up a little on Taiwan TV.
I have no idea what the source of the gas was. It was in a district near to Kaohsiung's refineries, so it could have been a pipeline leak. Or it could be methane build up due to a design flaw in Kaohsiung's sewer which is relatively new. I haven't gone over to see the area, but there are several blocks of damage.
I decided to change the regulator on my board having discovered that one of my new ones is the correct foot print for the location on the board where it is supposed to go.
So now, it all works, prop power supply and ground are good, decoupling is in place, current consumption is as expected, propeller-loader loads my LED flashing program successfully. Only one problem. The LED does not flash
Disaster. I need some sleep....
Having spent some time rebuilding my Propeller board it did not work. As noted in my last post. Clearly I had made a mistake and had to fix it. Nothing helped, everything checked out but my LED did not flash.
In the cold light of day I had an idea, try loading my Gadget Gangster board from the router. Basically just to check the LED flasher binary actually worked. It did not!
Hmmm...OK then I load the program to the GG via my PropPlug from a PC. It works!
Hmmm...OK then I load the program to my troublesome new board via my PropPlug from my PC. It works!
WTF? My new board was working all the time!
After much swapping of GG vs router and PC vs router it turns out that I really cannot program a Prop with prop-loader from my router any more. Not a GG or my new board.
Now the weird stuff:
1) propeller-load on the router reports that a Propeller was found on /dev/ttyS0 and loading completed successfully "Verifying RAM ... OK". But the program does not run.
2) propeller-loader on the router now cant' find a serial port or connected Propeller when I use -P or -Q options. That used to work. And it contradicts what it says when doing the load!
This run around makes me think Murphy has put some ACID in my tea again....
Good News... I have installed OpenWrt BuildRoot and am read to compile the pi-propeller-load.
There were a few side tracks. I had to back-track to make my /openwrt directory not available as SuperUser and I have 3 items that I have to locate - ncurses, libz, and awk. There is a big spreadsheet in the OpenWrt page that tells you what you use for Debian, Fedora, OS X, and other Linux distros. Fortunately I had seen that.
More to come later.........
Meanwhile try the mushrooms... some will make you tall, others will make you small.
Having convinced myself that my new board is all wired up correctly and does actually work attention turned back to the router, the prop-loader on it and that serial connection.
Turned out that after power cycling the router every thing works again!
I have no explanation for this, I changed nothing in the wiring, the software is all the same. WTF?
Perhaps, possibly, maybe, something funny happened with the routers UART. You see, thinking about it now I recall that at some point I managed to make a brief short circuit between something and that serial connection. It gave me a little panic as I saw the blue LED on the router make a little flash when it had no reason to. But everything seemed OK so I continued. Maybe that little short knocked the routers UART into some odd state that was reset by the power cycle?
But then how come the prop-loader claimed to be programming successfully?
Clutching at straws here. For now I just have to leave this as an unsolved mystery and move on. Let's see if it ever comes back.
Tired? I'm murderous. The mushrooms are an attractive option just now. Only I found out decades ago that mushrooms and soldering irons mix together in some very strange, interesting but somewhat unproductive ways...
Edit: Sorry I talked of a short to the routers UART. But it must have been the GPIO used for reset. That is what drives the blue LED. I should certainly not be driving the rest output and hence lighting the LED and fighting with the GPIO. But I checked the reset line levels were OK and the LED did flash when programming. So it's still a mystery anyway.
Not here to encourge a return of the bad old daze of substance abuses.
_______________
Okay, I did get OpenWrt BuildRoot installed and have moved on to this rather cryptic page.
http://wiki.openwrt.org/doc/devel/crosscompile
And I have actually located under my /openwrt directory, the sub-directory /openwrt/staging_dir ...so I am at about Step 3 of a 7 or more step process.
I am aware of what a PATH environment variable is, but can't quite get the drift of the instructions. Apparently you have gone through all this and had good results.
Let me know what you think I should do next. In the meantime, I will try running a MAKE that should produce a complete MR3020 firmware image. Up to now, I've been using Attitude_Adjustment v12.09 as it was deemed stable. But it appears I have loaded the source for something more evolved... Bleeding Edge.
(I actually have some doubts about anything named Bleeding Edge.)
Ever so slowly I am grasping more and more of what OpenWrt does and why.
loopy, i saw yesterday that the new release called B... B... is up to rc2. perhaps its worth trying this.
Oh my God, you will never believe it. It was the LED. It was the frikkin LED. The LED is dead.
Here is the sorry tale:
1) Whilst rebuilding the board with the new regulator I had to remove and reposition the LED. It was kind of big and in the way.
2) When testing the board the LED did not flash.
3) When probing the pin 1 on the Prop I saw no sign of life. I removed the LED in case of shorts. Still no life on the pin.
4) BUT, that's because I had removed the capacitor on the reset pin so when touching the circuit with the multimeter probes the Prop resets itself. That old issue.
5) After rebooting the router I probed the Prop pin a bit differently, first placing the probes on the board then programming it. This way no spurious reset occurs and the pin wiggles! Yay.
6) As everything was now working it was time to replace the LED. But I decided to find a new smaller one. Sure enough it flashed. At this point we start to think rebooting the router had fixed things.
7) During a visit to the supermarket it occurred to me to test that big old LED. Sure enough it is dead! Something bad happened to it as I was unsoldering and resoldering it. Too much heat perhaps.
So now I have to offer my apologies for posting up this long winded tale of bumbling hardware incompetence. It's amazing how these things can have you chasing geese all around the forest!
About that old spurious rest problem. Now that everything is back to working and I have no capacitor on the reset pin the reset problem persists.
By the way I now have a 330nF tantalum on the regulator input and 33uF tantalum on the output as per the reg's data sheet. There is 100uF electrolytic across the power rails near the Propeller. The new MC33269 regulator is great, much smaller, good for 20v input and only 4ma quiescent.
Now, I noticed that my Gadget Gangster board also resets when connected to my router and touched with a multimeter probe. It's not just my board!
What to do?
Am I likely to see anything interesting with a scope? Not that I have one here but there is a brand new 20MHz CRT scope in the office when I get back on Monday. My boss just had to buy the last analogue scope in the store. It's never been used.
As i said, i am not surprised reset occurs when you touch the reset pin - its a high impedance input and the lead will be like an aerial. it could be static induced too. if you want to prove it, try a 1M cap from the lead and touch the reset with the other end of the resistor and most likely it wont reset.
This is basically how capacitive sensing works - ie touch pads.
Now that I have gotten Make going, I can see that this is a necessary step in the process toward cross-compiling separate executables, such as pi-propeller-load.
It all starts out with compiling all the bits of the tool chain from source for the target device. That stuff is needed.
So far, I have done by best to ruin this run of make.
A. I started it at Starbucks on my notebook (Rule One - Never compile Linux on a portable computer -- broke this one)
B. I was worried about wasting batteries, so I turned off the wifi (Rule Two - Never disconnect your service to the web while compiling OpenWrt)
C. I ran out of battery power before I got through it all (Rule Three - Never turn off you computer in the middle of a Make run)
Nonetheless, it seems that OpenWrt has created a rather bullet-proof Build-root, and Linux is more stable than ever.
I got home, and restarted the Make process with the computer on AC power and it is just starting over with the last item of the Make process being redone. It hasn't griped very much about the disconnects, just suggesting I run a check before going ahead.
+++++++++++
I do have to admit that I should have done all this on my 'other computer' -- the Quad 64bit that is supposed to compile faster and is an actual desktop. That still is the wisest way to do a Linux compile (on your best and fastest computer).
But I got the notion in my head that Linux on a wifi router was not going to be anywhere near as formal and compiling a Linux binary for a real desktop. That is just not true. In fact, it may actually be a bit more demanding to do an OpenWrt binary as there are so many different hardware platforms that it seems all the code is kept in source.. nothing can be shared in some sort of joint repository.
_____________
And so, I am learning. And I am finding it deeply rewarding to actually compile a Linux Kernel .. finally.
I have read about how to do so. Thought about it. But this is the first time really through it all. I did some cross-compile for my CubieBoard, but that was actually the boot loader binary -- not the whole Linux OS.
Regulators vary in how much capacitance they desire and where. The only problem that I have seen is that a backflow of current through the regulator might damage in (certainly does with the 7805) and having the cap on the Vout being larger than the one on the Vin creates a potential hazard.
100uf on the Vout side without a diode by-passing the regulator at shut off could do some damage.
========
I wonder if I am going to have similar frustrations with the Reset. Maybe adding a stronger pull-up at the Propeller Reset pin might resolve the 'long wire' problem.
++++++++++
I did purchase a second MR3020 for myself, so I can load the new firmware, verify it is working, and compare with Attitude_Adjustment v.12.09.
Point taken about the 100uF on the reg input not output. What was I thinking?
I'm not following you about the reset line...
I have a 10K pullup on the Propeller reset pin. Is this really such a high impedance as to allow the antenna effects you describe? Without knowing any better my gut says no.
Secondly I'm not talking about touching the reset line, anywhere along its path.
This reset happens when I have the router connected to the board and I touch a multi-meter probe to ground on the board or on the router. In this situation the Propeller reset pin is connected to it's 10K pullup and via 100 ohms to a blue LED and GPIO pin on the router. Via a foot of hookup wire.
The only way I can rationalize this is to think that either the ground is bouncing up or the reset line is bouncing down briefly and triggering a reset. These two things are equivalent as far as the Propeller knows.
Further no matter if this an antenna effect, as you say, or a ground/reset bounce one way to kill it is to short high frequencies to ground with that little cap on the reset pin.
However you indicated that was not a good solution and that I was missing something else here.
So still at the, "what to do?" stage.
@Loopy,
Sounds like you have made good progress.
When you did the "make menuconfig" did you go in there and set the "target" option? And the "subtarget" option if there is one?
If your "make" step completed you should be able to see a firmware package file for your router somewhere. It should have the same name as the binary you fetched from OpenWRT.org and flashed your router with in the first place.
Can you do a $ find -name "*.bin" in your openwrt directory and check what you have got? If it is not there you have the wrong target options set.
If you have the right thing built then you have the toolchain ready and we can get on with building propeller-loader and OpenSpin.