If you have the right thing built then you have the toolchain ready and we can get on with building propeller-loader and OpenSpin.
Yes, I did check the target and sub-target. The rest of it I used defaults to a minimal configuration. I may have to do it over to get exactly what I want in firmware, but that's how we usually learn. Once never seems enough.
===========
Not sure what is going on with the reset. But the PropPlug is such a direct connect that these long wire issues don't come into play.
I have mention several times that there have been huge discussions on Reset problems. I might dig through some of those. But I am also getting a feeling that a 'long-distance reset' might better be served with a transistor at the Propeller board, and driving it from a transistor at the wifi router end. In other words, eliminate the sensitive nature of the Propeller Reset from being exposed to the real world.
I actually drilled a hole in my case for the 4 wires to the Propeller that directly passes over one of the antenna. Now I am considering moving the cable to the opposite side of the box and making a new hole. I also have some braided sheilding that can cover all four wires if required.
I do have a long-distance RS-422 set up that uses 3 twisted pairs to program and communicate with the Propeller and that is tested over 100 feet of Cat5 cable. It works quite well. At first, I did have trouble with cross-talk between the Tx and Rx on the ttl side, but just moved the wires away from each other.
+++++++++++
The make compile is still running. Overall, I have been running it for roughly 4 hours and using the notebook for other things. The prompt says 'make[3] -C target/linux compile', so it seems nearing the end.
Yes, I do seem to recall discussions of similar sounding reset problems. No idea where they are now.
I have thought about a transistor on the reset input, perhaps even some kind gate with hysteresis. However if a capacitor fixes it that might have to do. As I have seen done by professional digital designers many times!
In theory if make gets interrupted it will pick up from where it left off last time as if nothing had happened. That is indeed the whole point of make. It checks source files against the binary files they compile to. If the binary is older than the source, i.e. it has changed, then it rebuilds that source. Else there is nothing to do and it moves on to the next thing.
Things can go wrong if your file time stamps are messed up, like when you change the time on your computer.
Thanks for mentioning the time stamps snag. I think I survived this rather messy make run. I won't be so impulsive again. And since the process takes so long, using the faster desktop is what I should have done.
I presume you have your Brown Out pin tied to ground. Otherwise, your reset is on a Schmitt Trigger.
Brownout is very firmly welded to ground. Checked and double checked, like everything here just now, checked till I'm blue in the face. Except for that pesky LED though...
A lot of those reset circuits look familiar. A resistor and capacitor in series across the power supply with the MCU reset pin connected between them. Basic idea there seems to be delay reset until the power supply was stable. I seem to recall it was essential for some old 8 bit micros I used.
What about the Prop? Where do I find the reset timing requirements? If reset is permanently tied high does it power up properly? How fast should the power supply rise time be?
When I put the cap in my circuit I indeed have that traditional old rest circuit.
Edit: The Propeller datasheet has very little to say about reset. Kind of implying it should just work if tied high or pulled up. Indeed Propellers have seemed to work fine when used like that.
heater,
I am not sure if there are any other reset timing specs.
But back to your problem...
Part of what you are seeing seems fairly normal to me. I am more concerned as to whether there is an underlying problem and a cap on the reset may just mask this.
Do you get the same effects if you disconnect the router, but leave the reset wire attached to the prop and free the other end (you may just need to put a similar length of wire on the reset pin)?
Try a 10nF to ground (lower is preferable if you have say 1nF). Any difference?
What if you take 5V from the router to your boards power supply. Any difference?
I was a bit surprised to peek in the /openwrt/bin/ar71xx and find actually about 400 various binaries compiled for various Openwrt platforms.. I thought I was going to get just a few.
I do have the WR703N as well as the MR3020, and a lot more. Haven't yet tried to load the firmware.
I guess I can zip all these and provide them to others if they are interested.
I was a bit surprised to peek in the /openwrt/bin/ar71xx and find actually about 400 various binaries compiled for various Openwrt platforms.. I thought I was going to get just a few.
I do have the WR703N as well as the MR3020, and a lot more. Haven't yet tried to load the firmware.
I guess I can zip all these and provide them to others if they are interested.
These binaries are all 'trunk' as of yesterday which I believe is synonymous with what Openwrt refers to the Bleeding Edge. There is also a subdirectory of packages included. It seems that these have to have a coordinated compile to reflect changes that occur.
===========
I did go back into the Menuconfig and have figured out how to like compiles to one target. Moving on to figuring out how to cross-compile executables that are not part of the Openwrt opkg repositories.
I don't expect to get much done for a few days as I have to prepare for classes. I can't seem to focus on this project and get to all my teaching duties.... too much to multitask.
Ummmm.......... revisiting Openwrt, I now see that they provide the Bleeding Edge firmware that I compiled for all and everything. Unless one desires to customize the options or just desires to verify the make system is operating right, there isn't much reason to spend hours doing this. The repositories exist to do all that. (I even see an OpenWrt option to build an Allwinner A10, that's the CubieBoard1. Do I dare?)
++++++
As best I can understand, on the reset pin you have a 10K pullup to 3.3V with a 10pf cap to ground at the Propeller to stabilize the Reset. I was hoping to get away without modifying the Propeller ProtoBoard, but that seems no longer realistic.
Other circuitry would be at the wifi router to take the GPIO pin's output state to the outside world. The most central point of Reset discussion is whether that should be a High, going Low for Reset or a Low, going High for Reset with some sort of inversion (via transistor). Users were finding that RS232 cable programing of the Propeller was triggering a Reset every time their serial port was restarted... and that was an undesired consequence of configuration choices. My guess is that a HIgh, going Low for Reset remains preferred.
This isn't much to add, but I will have to think about how to get it done on my Propeller ProtoBoard. The Reset line is buried and I may have to do this at where the PropPlug meets the board.
Ideally, I suppose that the wiring should be as near as possible to the Reset pin. I suspect I could add an SMD 10pf cap that bridges the Reset button, but where to put the 10K pull-up is a bit vague at this juncture.
+++++++
So it seems that the method of cross-compile is to set aside the /openwrt directory and to build another directory just for cross-compile of executables which won't interfere with the elaborate Make processes... but the new directory borrows the target binary and maybe other tool chain elements. The bulk of the Openwrt buildroot set up will just remain there for a rainy day.
Thus, the additions of Paths to the specific compiler binaries, and so on.
I have a very limited range of cap values here but here goes:
I made myself a 1 foot "antenna" from the same insulated wire as my router connection.
1) No cap on reset - disconnecting the router at my prop-plug header on the board then touching the reset pin there with the antenna - BOOM reset.
2) 22pF cap on reset - The antenna no longer causes reset. Touching ground on the board with the multimeter probe - BOOM reset.
3) 2n2 on reset - No reset from antenna. No reset from poking with the multimeter - Great!
4) 10n on reset - As above. Great. To be expected.
The 10n test seems redundant but I didn't find the 2n2 until after doing the 10n test.
I did not take power 5v from the router. It's just fiddley enough to do that I did not want to bother just now.
By the way I moved the 100uf bulk cap to the input side of the regulator not that it makes any odds here.
OK, pretty much as I expected. The reset happens unless you put a small cap on it. 10nF will be fine. It will take longer to power up and not sure if this may impact any of the prop loaders. In a normal circuit you don't need it (ie without long aerial wires). So its not the router causing this, just a by product of the longer wire and touching it.
BTW, prior to getting the git clone from git for Openwrt, I did NOT clearly understand how git was supposed to work.
I had no idea that I should 'apt-get install git' to download source files. This feature is far less complex that downloading zip files, unzipping, and so on.
Unless one desires to customize the options or just desires to verify the make system is operating right, there isn't much reason to spend hours doing this.
Yes there is. As I explained before you need a cross compiler and all the target libraries to be able to build your own programs for OpenWRT with. Building openwrt from its sources for your target gets you that tool-chain. How else are you going to compile "helloWorld" for your router?
Currently I have a 10k pullup to 3.3v on the reset pin. There is a 2.2nF capacitor to ground. There is a 100 ohm resistor in series with the reset input line. It's something for the cap to form a low pass filter with. See the schematic I posted earlier.
The high or low or whatever reset from the router maybe an issue. For example my router flashes, very briefly, that blue LED I use for reset on boot up. So my Prop will be reset on router boot up. Not what I want. I have no idea why OpenWRT does that, I can't see it making use of the blue LED for anything else at all.
Yep, don't mess with your OpenWrt directory. Unless you actually want to hack on something in OpenWRT itself.
Just build your projects in their own directories somewhere, as I described for the loader.
I had no idea that I should 'apt-get install git' to download source files. This feature is far less complex that downloading zip files, unzipping, and so on.
git is wonderful. and github is wonderful. I hate all that messing with projects that come as a mess of files in a zip. Cough...all of OBEX.
When I make some changes to pi-propeller-load you can get them simply by changing to the pi-propeller-load directory and typing:
$ git pull
How easy is that? It only fetches things that have changed so it's very fast for large projects.
Your reset cct is fine heater. I understand what you have.
Not sure what indication they are using the blue led for before everything is running. Later we can use another GPIO if necessary, with the correct polarity too.
Not sure what indication they are using the blue led for before everything is running
Not sure. Seems to me that somewhere they are setting the direction of the GPIO for that LED to output, at which point it drives out a low which turns the LED on. Then they set the GPIO high to turn the LED off. After that I have no idea if it is used anywhere. Luci does not allow access to it although she does have a list of LEDs to control.
Because Cluso had this crazy idea about Propellers and routers and because Loopy chivied me along into exploring OpenWRT I had to build myself a Propeller board for my router.
Because I had to build a board I had to go to the electronics store to get some parts. R's and C' and a loupe and some tweezers. Yes this was going to be surface mount time.
As I was in the electronics store I noticed they happened to have a new Model B+ Raspberry Pi. So I had to buy one.
As I now had a loupe and a Raspi camera and a new Raspi and some of my first surface mount soldering that I cannot see very well I had to put all of these together.
And this is the result:
Picture taken of the 10K pull up on my new Prop board taken with a Raspi camera through a jewelers loupe.
Now the lighting is not good, and it's a bit fuzzy due to the lack of light, and a shaky hand, and the soldering is not perfect:) But it already looks a thousand times better than pictures taken with my Samasung Galaxy S which cost ten times as much.
Looks like I have a new project on hand to perfect this camera set up.
@Heater
Happy to see you are having such fun. This has been rewarding for me as well. The Linux router projects have been something that I wanted to revisit for quite awhile and I hadn't seen much until the WR703N that seemed to apply to the Propeller.
About the only thing that I am wondering is whether the pi-propeller-loader should have a software choice to select the GPIO reset as active High versus active Low. To me, it seems that some users are going to want it one way, and other users will desire it the other. Trying to assert one and only one choice is likely to just cause a big row.
And, in my own case... I will not attach an LED to the GPIO for the reset. Most likely...either it will be a diode blocking current in the opposite direction if the GPIO pulls the pin low, or it will be a NPN transistor it the GPIO pulls the pin high for a reset.
Attached is a executable of pi-propeller-load built for the mips_34kc architecture which I think you guys are using. In case compiling it is a problem.
Thanks, I am regrouping on the hardware side to liberate a GPIO for the actual use as a Reset. I may have to remove a 10k pulldown resistor that isn't much bigger than a pencil tip. Then attach a bit of 30 gage wire.
But I am thinking more about where it goes after than and where I will get my 3.3VDC and Gnd.
I guess the whole solution will be set up for an easy way to plug in and remove any interface circuit. So if it doesn't work well, I can swap it out with another build.
++++++++++++++
I do understand how I am to cross-compile executables and wanting very much to try on my own. But I am hopping from English class to English class for a few days.
==========
While it seems that all the goals we wanted have been pretty much met, there are huge advantages in being able to cross-compile one's own binaries for these little boards.
All sort of creative wifi and lan interfacing to a Propeller can be done. So I suspect things are rather open-ended.
Totally with you. You should be able to build your own stuff. I was just hoping someone could quickly try it so that I know my tool chain for those devices works as I don't have any. And also that the GPIO options work correctly. You don't even need to have a Propeller attached, the debug output will say what it is doing successfully or not.
No idea about your 3.3v supply. I kind of like that I have now converted my d-link into a giant Prop Plug, same header connections. The board gets it's own power from batteries so connecting, reconnecting and testing every is dead easy.
I can see how one would want power from the router though, in the finished item.
Comments
Yes, I did check the target and sub-target. The rest of it I used defaults to a minimal configuration. I may have to do it over to get exactly what I want in firmware, but that's how we usually learn. Once never seems enough.
===========
Not sure what is going on with the reset. But the PropPlug is such a direct connect that these long wire issues don't come into play.
I have mention several times that there have been huge discussions on Reset problems. I might dig through some of those. But I am also getting a feeling that a 'long-distance reset' might better be served with a transistor at the Propeller board, and driving it from a transistor at the wifi router end. In other words, eliminate the sensitive nature of the Propeller Reset from being exposed to the real world.
I actually drilled a hole in my case for the 4 wires to the Propeller that directly passes over one of the antenna. Now I am considering moving the cable to the opposite side of the box and making a new hole. I also have some braided sheilding that can cover all four wires if required.
I do have a long-distance RS-422 set up that uses 3 twisted pairs to program and communicate with the Propeller and that is tested over 100 feet of Cat5 cable. It works quite well. At first, I did have trouble with cross-talk between the Tx and Rx on the ttl side, but just moved the wires away from each other.
+++++++++++
The make compile is still running. Overall, I have been running it for roughly 4 hours and using the notebook for other things. The prompt says 'make[3] -C target/linux compile', so it seems nearing the end.
Yes, I do seem to recall discussions of similar sounding reset problems. No idea where they are now.
I have thought about a transistor on the reset input, perhaps even some kind gate with hysteresis. However if a capacitor fixes it that might have to do. As I have seen done by professional digital designers many times!
In theory if make gets interrupted it will pick up from where it left off last time as if nothing had happened. That is indeed the whole point of make. It checks source files against the binary files they compile to. If the binary is older than the source, i.e. it has changed, then it rebuilds that source. Else there is nothing to do and it moves on to the next thing.
Things can go wrong if your file time stamps are messed up, like when you change the time on your computer.
More later...
I presume you have your Brown Out pin tied to ground. Otherwise, your reset is on a Schmitt Trigger.
https://www.google.com/search?q=microcontroller+reset+circuit+design&client=iceweasel-a&rls=org.mozilla:en-US:unofficial&source=lnms&tbm=isch&sa=X&ei=phDdU9OCKMbq8AXm-IHACQ&ved=0CAgQ_AUoAQ&biw=1024&bih=382#q=microcontroller+reset+circuit+&rls=org.mozilla:en-US:unofficial&tbm=isch
And a Parallax Propeller thread about transitor driven resets.
http://forums.parallax.com/showthread.php/133362-Why-do-we-need-the-transistor-reset-circuit-for-the-USB-devices-(FT232RL-CP2102)
What about the Prop? Where do I find the reset timing requirements? If reset is permanently tied high does it power up properly? How fast should the power supply rise time be?
When I put the cap in my circuit I indeed have that traditional old rest circuit.
Edit: The Propeller datasheet has very little to say about reset. Kind of implying it should just work if tied high or pulled up. Indeed Propellers have seemed to work fine when used like that.
I am not sure if there are any other reset timing specs.
But back to your problem...
Part of what you are seeing seems fairly normal to me. I am more concerned as to whether there is an underlying problem and a cap on the reset may just mask this.
Do you get the same effects if you disconnect the router, but leave the reset wire attached to the prop and free the other end (you may just need to put a similar length of wire on the reset pin)?
Try a 10nF to ground (lower is preferable if you have say 1nF). Any difference?
What if you take 5V from the router to your boards power supply. Any difference?
tried to send you a PM but your mailbox is full. I will try your old email address.
I was a bit surprised to peek in the /openwrt/bin/ar71xx and find actually about 400 various binaries compiled for various Openwrt platforms.. I thought I was going to get just a few.
I do have the WR703N as well as the MR3020, and a lot more. Haven't yet tried to load the firmware.
I guess I can zip all these and provide them to others if they are interested.
I have a very limited range of cap values here but here goes:
I made myself a 1 foot "antenna" from the same insulated wire as my router connection.
1) No cap on reset - disconnecting the router at my prop-plug header on the board then touching the reset pin there with the antenna - BOOM reset.
2) 22pF cap on reset - The antenna no longer causes reset. Touching ground on the board with the multimeter probe - BOOM reset.
3) 2n2 on reset - No reset from antenna. No reset from poking with the multimeter - Great!
4) 10n on reset - As above. Great. To be expected.
The 10n test seems redundant but I didn't find the 2n2 until after doing the 10n test.
I did not take power 5v from the router. It's just fiddley enough to do that I did not want to bother just now.
By the way I moved the 100uf bulk cap to the input side of the regulator not that it makes any odds here.
These binaries are all 'trunk' as of yesterday which I believe is synonymous with what Openwrt refers to the Bleeding Edge. There is also a subdirectory of packages included. It seems that these have to have a coordinated compile to reflect changes that occur.
===========
I did go back into the Menuconfig and have figured out how to like compiles to one target. Moving on to figuring out how to cross-compile executables that are not part of the Openwrt opkg repositories.
I don't expect to get much done for a few days as I have to prepare for classes. I can't seem to focus on this project and get to all my teaching duties.... too much to multitask.
Sounds like you are all set to build your own programs for your router.
First add the OpenWRT compiler to your PATH something like: To make that path come up every time you log in add a line like that to the end of your .bashrc file.
Check your compiler at least runs:
Check out the propeller loader source code from my repo:
And build it with your cross-compiler: If that all goes OK you should then have a loader in pi-propeller-load/bin/linux for the correct architecture:
++++++
As best I can understand, on the reset pin you have a 10K pullup to 3.3V with a 10pf cap to ground at the Propeller to stabilize the Reset. I was hoping to get away without modifying the Propeller ProtoBoard, but that seems no longer realistic.
Other circuitry would be at the wifi router to take the GPIO pin's output state to the outside world. The most central point of Reset discussion is whether that should be a High, going Low for Reset or a Low, going High for Reset with some sort of inversion (via transistor). Users were finding that RS232 cable programing of the Propeller was triggering a Reset every time their serial port was restarted... and that was an undesired consequence of configuration choices. My guess is that a HIgh, going Low for Reset remains preferred.
This isn't much to add, but I will have to think about how to get it done on my Propeller ProtoBoard. The Reset line is buried and I may have to do this at where the PropPlug meets the board.
Ideally, I suppose that the wiring should be as near as possible to the Reset pin. I suspect I could add an SMD 10pf cap that bridges the Reset button, but where to put the 10K pull-up is a bit vague at this juncture.
+++++++
So it seems that the method of cross-compile is to set aside the /openwrt directory and to build another directory just for cross-compile of executables which won't interfere with the elaborate Make processes... but the new directory borrows the target binary and maybe other tool chain elements. The bulk of the Openwrt buildroot set up will just remain there for a rainy day.
Thus, the additions of Paths to the specific compiler binaries, and so on.
I had no idea that I should 'apt-get install git' to download source files. This feature is far less complex that downloading zip files, unzipping, and so on.
Currently I have a 10k pullup to 3.3v on the reset pin. There is a 2.2nF capacitor to ground. There is a 100 ohm resistor in series with the reset input line. It's something for the cap to form a low pass filter with. See the schematic I posted earlier.
The high or low or whatever reset from the router maybe an issue. For example my router flashes, very briefly, that blue LED I use for reset on boot up. So my Prop will be reset on router boot up. Not what I want. I have no idea why OpenWRT does that, I can't see it making use of the blue LED for anything else at all.
Yep, don't mess with your OpenWrt directory. Unless you actually want to hack on something in OpenWRT itself.
Just build your projects in their own directories somewhere, as I described for the loader.
When I make some changes to pi-propeller-load you can get them simply by changing to the pi-propeller-load directory and typing: How easy is that? It only fetches things that have changed so it's very fast for large projects.
Not sure what indication they are using the blue led for before everything is running. Later we can use another GPIO if necessary, with the correct polarity too.
OK thanks. 10n it will be.
I'm a bit surprised that a 1 foot antenna working against a 10k pullup has any effect. But there we go. Hmmm...
The loaders perform the following sequence to reset the Propeller:
assert_reset(); msleep(10); deassert_reset(); msleep(90);The loader can not begin to do anything until 90ms after reset is removed. The time constant of 10n and 10K ohms is 100us. That's 90 times less!I think we are far away from this cap being an issue for loading. And 100n worked here so we do seem to have a lot of leeway.
Not sure. Seems to me that somewhere they are setting the direction of the GPIO for that LED to output, at which point it drives out a low which turns the LED on. Then they set the GPIO high to turn the LED off. After that I have no idea if it is used anywhere. Luci does not allow access to it although she does have a list of LEDs to control.
Because Cluso had this crazy idea about Propellers and routers and because Loopy chivied me along into exploring OpenWRT I had to build myself a Propeller board for my router.
Because I had to build a board I had to go to the electronics store to get some parts. R's and C' and a loupe and some tweezers. Yes this was going to be surface mount time.
As I was in the electronics store I noticed they happened to have a new Model B+ Raspberry Pi. So I had to buy one.
As I now had a loupe and a Raspi camera and a new Raspi and some of my first surface mount soldering that I cannot see very well I had to put all of these together.
And this is the result:
Picture taken of the 10K pull up on my new Prop board taken with a Raspi camera through a jewelers loupe.
Now the lighting is not good, and it's a bit fuzzy due to the lack of light, and a shaky hand, and the soldering is not perfect:) But it already looks a thousand times better than pictures taken with my Samasung Galaxy S which cost ten times as much.
Looks like I have a new project on hand to perfect this camera set up.
Happy to see you are having such fun. This has been rewarding for me as well. The Linux router projects have been something that I wanted to revisit for quite awhile and I hadn't seen much until the WR703N that seemed to apply to the Propeller.
About the only thing that I am wondering is whether the pi-propeller-loader should have a software choice to select the GPIO reset as active High versus active Low. To me, it seems that some users are going to want it one way, and other users will desire it the other. Trying to assert one and only one choice is likely to just cause a big row.
And, in my own case... I will not attach an LED to the GPIO for the reset. Most likely...either it will be a diode blocking current in the opposite direction if the GPIO pulls the pin low, or it will be a NPN transistor it the GPIO pulls the pin high for a reset.
I will be tweaking the options for the loader. I did say this won't work for you and this is why. It also won'work on the Raspi with out fixing this.
I want to allow the user to specify which GPIO is used and it's polarity.
I'm thinking of extending the GPIO option so it looks like this:
$ propeller-load -Dreset=gpio,17,1
Where the 11 is the gpio number in /sys/class/gpio and the 1 means set high for reset, 0 would be set low of course.
Sound OK?
I have added the ability to specify GPIO pin and the logic level to pi-propeller-load. It uses the "-Dreset=gpio,17,1" format as I mentioned above.
If you have cloned the pi-propeller-load repository just up date it with "git pull". Build instructions as before.
I have tested it here a bit. Seems to work.
But I am thinking more about where it goes after than and where I will get my 3.3VDC and Gnd.
I guess the whole solution will be set up for an easy way to plug in and remove any interface circuit. So if it doesn't work well, I can swap it out with another build.
++++++++++++++
I do understand how I am to cross-compile executables and wanting very much to try on my own. But I am hopping from English class to English class for a few days.
==========
While it seems that all the goals we wanted have been pretty much met, there are huge advantages in being able to cross-compile one's own binaries for these little boards.
All sort of creative wifi and lan interfacing to a Propeller can be done. So I suspect things are rather open-ended.
Totally with you. You should be able to build your own stuff. I was just hoping someone could quickly try it so that I know my tool chain for those devices works as I don't have any. And also that the GPIO options work correctly. You don't even need to have a Propeller attached, the debug output will say what it is doing successfully or not.
No idea about your 3.3v supply. I kind of like that I have now converted my d-link into a giant Prop Plug, same header connections. The board gets it's own power from batteries so connecting, reconnecting and testing every is dead easy.
I can see how one would want power from the router though, in the finished item.