@Heater
I think the opkg update problem is directly related to your NOT using Attitude Adjustment 12.09.
In simple, Openwrt cannot provide repositories for all and everything that people might generate in a custom compile.
Happy to see that the Barrier Breaker repository is working for you. But not sure how stable that might be.
++++++
The easy solution is to load a firmware image that has a repository supported by Openwrt.
The alternative is compile your own set of repository binaries, and Openwrt does support that option. But I suspect you will find it all rather tedious. And you will have to redirect opkg to your custom repository.
Why not let OpenWrt do all the developmental work of providing a stable repository?
Yes, indeed. I'm sure that package problem does not exist in the stable 12.09 release.
Poking around at http://downloads.openwrt.org/ I'm amazed by the huge number of packages there are. However it looks like something has changed in the recent snapshots and the opkg.conf file no longer points to a place with a Packages.gz. I don't know if this is part of some ongoing rearrangement of the repositories or something that just got broken. Still trying to follow what they are up to there. I can see the sources here of course and for sure they are not right.
The easy solution may well to be to use an actual stable release. Part of the reason I did not is that the OpenWRT hardware support page indicates that a custom build is required for my D-LINK. My hunch was that the documentation is old and whatever the required customization was is now in the latest code base. And so it was, it worked without any hacking.And so here I am with the cutting edge sources just begging to be built for the MR3020, the Raspberry Pi and whatever else turns up here.
The alternative is compile your own set of repository binaries...
Funny you should say that...Guess what I have been up to last night?
Well, no I'm not about to try and build all the packages but at least one can set an option in "make menuconfig" that gets it to include luci in the image. Mind you, if their build system works then building all the packages would not be tedious, just set it running and whenever it's done it's done.
Why not let OpenWrt do all the developmental work of providing a stable repository?
Because.
That's just not fun. Standing on solid ground is OK but does not have the thrill of standing on the edge of a cliff. Standing on the edge gives one a great view.
Somebody has to test this stuff and report bugs. Might as well be me sometimes. It's about as much as I can do by way of returning something to the thousands of people who put billions of hours into making all the open source software we use everyday.
I do like the idea that if you are using open source software you can build it yourself. So why not? That is kind of the point is it not?
That's why my home machines run Jessie instead of Wheezy. It's why I'm endlessly rebuilding propgcc, SimpleIDE, the open source Spin compiler etc etc.
It's about wanting to be part of a happening rather than just watching it from outside.
Okay, live dangerously. But accept the drama and set backs that offers.
I take a more conservative approach these days. It is obvious that OpenWrt provides a bare bones installation in Attitude Adjustment with the stable repositories. For a lot of users, that alone is a huge learning curve.
OpenWrt also provides the second, more ambitious path for anyone that wants to participate as a developer and maybe hack any entirely new devices. While you seem to enjoy that, I get rather lost in it. Nonetheless, I have learned much by doing the one compile run I did, and will do more at a leisurely pace.
In sum, just think of this as TWO separate ways to participate in OpenWrt. And you are taking the one that expects more experience. While I am taking the newbie's route.
++++++++++
Meanwhile, back in Attitude Adjustment 12.09 land,
I have been trying to do a few sanity checks before getting into downloading a binary with pi-propeller-loader.
A. Verify my GPIO29 is working (It does, but at 2.71V, adding a 10K pullup is not quite right)
B. Determine if I can still reach Forth via Rx/Tx with the GPIO as Reset attached. (Not yet)
=========
Sadly, problems have arose.
It seems that the Openwrt default for GPIO29 even without the pull down resistor is LOW. That means that as long as the Reset is attached in that context, the Propeller is in a suspended reset condition.
To eliminate that condition I have been manually entering the following:
echo 29 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio29/direction
echo 1 > /sys/class/gpio/gpio29/value
But I see yet another item in the /sys/class/gpio/gpio29..........
which is active_low and it is defaulted to 0.
I am not sure where that comes into play or if it can wisely be ignored.
When I do try a serial connect through /dev/ttyATH0 in Minicom, I am not reaching the Propeller in Tachyon Forth --- which was working fine before.
+++++++++++
I am not exactly sure what the issues are here. I have tried the GPIO29 wired without a 10K pullup and wired with a 10K pullup. But now my conventional RS232 is not working.
I have yet to go into the inittab and shut out the systems activity on /dev/ttyATH0 and that is 115200 baud while my Tachyon iis 57600 baud. So there might be collision activity.
I will keep trying to sort out what is what. But I need to confirm Tx, Rx, and Reset are all working and coordinated before bothering with attempting a pi-propeller-load, don't I?
+++++++++++
Of course I am a bit concerned that you pi-propeller-load might not take into account the Openwrt defaulting the GPIO to a low output as the standard state. You may have presumed that the 10K pullup would be starting with a pin that is not actively pulling LOW.
So, I am struggling to get back the services I previously resolved as good, and am not sure why.
Okay, live dangerously. But accept the drama and set backs that offers.
Naturally.
Mind you, I'm not much into actual danger. Having software not working on my hobby projects can be a nice challenge but sky diving, for example, is probably off my list of things to do, base jumping is right out:)
Most open source projects allow multiple paths of entry. From "here the deb package just go install it", to "here is the source just build it", to "we don't have that feature yet would you like to write it?". Although some projects are quite fussy about who they except patches from, might just be one guy doing his own thing who does not care what you want to add or fix.
About that reset from GPIO:
Ideally when the router is powered up nothing is done with the GPIO you want to use. It stays low, hopefully in it's default state of being an input. We will presume there is a pull up on the Props reset pin somewhere. Cycling the routers power should then never cause a Prop reset.
Of course we don't know what any particular router does with any particular GPIO. For example my reset GPIO drives a blue LED. That LED is flashed very briefly at start up. I have no idea why or where that is happening in the OpenWRT code. Certainly I can't control that LED from Luci or uci.
At some point one would have to track this down an change it in OpenWRT somewhere.
I have not played with any "active_low" or any other tricks you can do with /sys/class/gpio. So far I have not had the need to.
pi-propeller-load sets the GPIO to HIGH before setting direction to "out" when it is started. Of course it leaves the GPIO HIGH on exit. So reset should only be happening in a controlled manner when it actually programs the Prop. Of course pi-propeller-load cannot help you with any reset waggling problems before you run it!
(N.B. "HIGH" in the above could well be "LOW" if you use the reset option to reverse the sense of reset).
Yep, you need to be sure that tx/rx and your GPIO pin are working. You should be able to chat to a Prop running Forth or whatever and make a Propeller reset manually. Then pi-propeller-load has a chance of actually working.
1) pi-propeller-load leaves the GPIO pin exported when it's done. Originally it unexported the GPIO but that causes any access of the GPIO later to not work on my D-LINK for some odd reason.
2) pi-propeller-load leaves the GPIO pin as an output when it's done. Driving out whatever NOT RESET is for you.
I think this is reasonable. Why would we ever want to unexport our reset pin? And we do nee to be not causing another reset on exit.
HI,
Well, after pulling everything apart and checking continuity and voltages... Dumbo discovered that the battery powering the Propeller had got too low.
Okay, I do understand the the pi-propeller-load will leave the Propeller Reset High after downloading.
A. Can I do another download, or will that block a second attempt?
B. Can I run an independent GPIO export before download so that I can just use the Propeller's serial port with interfering with the pi-propeller-download?
I will keep trying. It seems as though I am much closer.
You can load the Propeller as many times as you like. I have sometimes done many downloads in quick succession just to check it was some how reliable.
You can use the GPIO how you like before and after a download. In fact I have a little script that exports the GPIO, sets the direction and does an output so that I can issue a propeller reset whenever I like.
Okay,
I have gotten all the hardware working and varified.
I can bring up Forth via a serial terminal with the GPIO Reset is connected (without a 10K pullup).
So I am just muddling through transfering files over to the MR3020 and running pi-propeller-load. I have the atfty client on the MR3020. I just need to get the server going on my notebook.
I have been operating without SSH as Dropbear seems to need additional configuration to be able to have access both from the LAN plug and the wifi.
So I presume that SCP isn't active until I activate SSH.
Looking for an alternative FTP client and daemon pair, I came across atftp and atftpd in the opkg listings.
In truth, this is getting a bit much... so I might just start up SSH and work with whatever I get. I used SCP previously and it works fine.
Tried to use wget locally, but I seem to not understand how to do so.
I don't understand the problems you are having with SSH.
It has always just worked for me, on these routers, on my PC's, on servers we manage, on other embedded systems.
Mostly the only configuration change I make is whether to allow log in as root or not. In the case of these routers I have not changed anything in ssh configuration.
As soon as you have telnet access to your box you should set a root password and from then on use ssh. As it says in the OpenWRT documentation.
Out of the box I get ssh access from the LAN and the WAN. Only today I was logging into my D-LINK at home form our office over the internet.
As a bonus you get to use scp.
Messing with ftp clients and servers is just making your life more complex and less secure.
When I evoke SSH via Dropbear, I can no longer reach my MR3020 for the Terminal use via wifi. I have to log in via LAN only. So the whole wireless Propeller programmer scheme becomes moot.
It seems I have to learn to configure Dropbear for a second wifi login path.
++++++++++
Additionally, I had high hopes to use the MR3020 as a stand-alone wifi Propeller Programmer. But when I disconnect it from the LAN, the wifi ignores me even without SSH being active.
+++++++++
As so......
I am pretty sure I can verify that your pi-propeller-loader will perform as required.
But that doesn't complete the project. I have several big obstacles to getting a nifty stand-alone wifi Propeller Programmer.
This is all very strange. As I just said normally things "just work". Certainly I have never seen that logging in over ssh on one interface disables some other interface. That is just weird.
However as you are having problems I started playing with ssh into the MR3020 here. I discovered an odd thing:
Firstly my current setup:
1) A d-link connected to the internet.
2) My PC connected to the d-link's lan via WIFI
3) The MR3020 connected to the d-link's lan via WIFI
4) My PC connected to the MR3020 via ethernet.
Now:
a) I can ssh into the d-link from the lan side or from the internet (wan)
b) I could ssh into the MR3020 from its lan side, my PC.
c) BUT I could NOT ssh in from its wan side, from the d-link.
How come? I don't know. I thought there must be some firewall rule in the d-link that allows ssh access on the wan side. Or conversely some firewall rule on the MR3020 that blocks ssh on the lan.
I could not find such rules. I pulled all the /etc/config files out of both boxes and compared them. I could not see any relevant difference!
The solution:
On a hunch, using Luci on the MR3020 I added a firewall rule specifically to allow ssh on the wan (I don't have such a rule on the d-link but let's see.)
BINGO it works! Now I can ssh from any box to any other box in my PC-MR3202-DLINK triangle over any of their wan or lan interfaces!
In Luci it's a case of going to "Network->Firewall->Traffic rules" just add a new rule under "Open ports on router".
The relevant firewall rule that Luci creates in /etc/config/firewall looks like this:
config rule
option enabled '1'
option target 'ACCEPT'
option src 'wan'
option proto 'tcp'
option dest_port '22'
option name 'ssh'
Now I have to figure out why my dlink allows ssh on wan even without such a rule!
Bottom lines are:
You should not have to mess with dropbear configuration.
One can certainly use the MR3020 as a stand-alone wifi Propeller Programmer.
But when I disconnect it from the LAN, the wifi ignores me even without SSH being active.
This smells bad. It has happened to me in the past that when I think I'm talking to something over WIFI, for example, I am actually talking to it over ethernet. Then when I think everything is configured nicely I yank out the ethernet cable. BOOM no more communication.
Even when all the interfaces are up and running nicely and all the configs looked OK the packets end up getting routed a different way. Or more subtly they go out over the correct interface a replies come back on a different one.
At this stage if I was you I would blow all that away and install OpenWRT again. Out of the box the the ethernet side works. Just configure WIFI as a "station" and get it to connect to your WIFI router on the internet (I presume you have one). Follow the instructions for that on OpenWRT http://wiki.openwrt.org/doc/recipes/routedclient
N.B. I only did the first part of those instructions for "Using MASQUERADE". This means I can only ssh into the MR3020 over WIFI from my d-link. It is not visible to my PC over WIFI. It's on a different subnet so the routing does not work.
For that one has to continue with the next section "Using routing". I have not done this and perhaps never will. I can access my MR3020 over ethernet when required and it can access the internet via WIFI.
At this point...
I am just focusing on getting your pi-propeller-load tested.
Then I can deal with the other issues.
So far, I have had no luck using 'sta' mode. I am using 'ap'.
Obviously, there is a lot I don't understand about routers and wifi. But that is why I am exploring OpenWrt. I just have these other items that work toward a goal of an independent Wifi Propeller Programmer and Interface.
At least we can verify your software is 'user ready'..
Just managed to get the lid of the MR3020. What a struggle, three kitchen knives and half a thumb later I'm in. Amazingly the lid may still be usable:)
Now about that serial port....Can I assume it is on the P1 connector?
For some reason none of the images for this on OpenWRT.org are showing up in my browsers today.
Just managed to get the lid of the MR3020. What a struggle, three kitchen knives and half a thumb later I'm in. Amazingly the lid may still be usable:)
Now about that serial port....Can I assume it is on the P1 connector?
For some reason none of the images for this on OpenWRT.org are showing up in my browsers today.
HI,
Yes, you can use Pins 30 and 31 on the Propeller directly to the MR3020 Tx and Rx as all are 3.3V ttl. But I did include a 10K pullup at the MR3020 to Tx. Openwrt suggested this.
I have migrated to SSH so that I can use SCP for file transfers. The 'atftp' and 'atftpd' is a distraction. More importantly, by waiting until after I settled on my configuration to start Dropbear, I have both wifi and LAN access.
Openwrt pushes on to enter a password right away. Once Dropbear is in place, configuration changes may be the source of being shut out.
++++++++++
I did rebuild my bench setup to have everything on AC mains. The MR3020 and Propeller were left running overnight to see how stable the Tx, the Rx, and especially the Reset were. I left the GPIO29 in a High.
But somewhere along the way, the GPIO29 was dumped and no longer in /sys/class/gpio/ I am a bit unsure if I inadvertently reset the MR3020 or what. This will require more careful investigation.
I am NOT using a 10K pullup or capacitor on the GPIO29 at this time. It seems that there is an internal pullup in the Proeller that is driving the High to about 3.1volts. The GPIO209 unconnected will only drive 2.71v in High.
+++++++++
Meanwhile, I have to just transfer my files via SCP and run a pi-propeller-load to test the set up. I will be back a bit later today with results.
Success... finally, the download reports being complete.
I used -Dreset=gpio,29,0
But, it seems that the /dev/ttyATH0 serial port is not released after programing... so I was forced to reboot the MR3020 after programming the Propeller in order to reuse /dev/ttyATH0 via Minicom to the Propeller.
Conclusions.
A. The pi-propeller-load_mips34kc binary is working properly to download a binary to EEPROM
B. It seems that after using, the /dev/ttyATH0 serial port remains attached and not available. So it is necessary to reboot the MR3020 to use /dev/ttyATH0 for a serial terminal.
C. The reboot process dumps the GPIO29 configuration and that resets the Propeller
So we do have a working pi-propeller-download, but reviving communications with the Propeller after a download seem to require resetting the MR3020 and reconfiguration of the GPIO29. (Until GPIO29 is reconfigured HIGH, the Propeller may be doing spurious resets.
____
NOTE - My GPIO29 does NOT have a 10K pullup to 3.3v. But I found that even with such, the pin would read 0.6V if not specifically configured Export/Out/High.
I can insert the 10K pullup and run further tests, but it seems as if the defaults in the OpenWrt firmware are pulling GPIO29 low on reboot.
And regarding /dev/ttyATH0 not being released...
I have had similar problems using SER2USB on other Linux systems. One doesn't have to always reboot the system, but the alternative is to go in as system administrator and release the serial port. I am not quite clear on how to do that or whether doing so is worth the trouble. I can easy include a script to bring GPIO29 back to export/out/high.
root@OpenWrt:/tmp# ./propeller-load-mips_34kc -p /dev/ttyATH0 -Dreset=gpio,29,1 -r dlink-test.binary
Using GPIO pin 29 as Propeller reset (HIGH).
error: no propeller chip on port '/dev/ttyATH0'
root@OpenWrt:/tmp# ./propeller-load-mips_34kc -p /dev/ttyATH0 -Dreset=gpio,29,0 -r dlink-test.binary
Using GPIO pin 29 as Propeller reset (LOW).
error: no propeller chip on port '/dev/ttyATH0'
Do actually leave GPIO 29 high and low (or is it the other way around?) I have checked with my meter.
Still trying to find the fine wire to attach to there.
B. I hope you use a 90 degree four pin header as it will allow you to later close up the box.
OR even better use a FIVE pin 90 degree header and bend one pin straight for the GPIO wire. The other four go into the holes on the board.
C. I really think you may only see about 2.70 volts as your logic high regardless of how carefull your construction. There is some indication that this board i/o outputs only 2.8, but I have no direct verification.
D. My GPIO is direct -- no 10K pullup and no 100p capacitor at this time. (I constructed so I can insert these if need arises.)
+++++++++++
I am finding the 2.70 volt GPIO High is adequate and drives a Reset to the Propeller while the Propeller remains stable as long as the GPIO remains High.
And yes, I am sure these are ROHS lead-free boards with higher temperature solder.
The -t should get you a terminal running at the specified baud rate. Then you should see your Forth chirping up.
Ah, this seems handy. But I a bit uncertain. I have to use Minicom (in the MR3020) as the Terminal software. I will try another binary load a bit later and see if that stops all the reboot nonsense.
Mine is actually 2.71V. I left the other resistor intact, so I have only the one GPIO29. There is no relationship of the R15 and R17 to the actual GPIO numbering.
The GPIO may provide only 2.7V, but does seem to tolerate 3.3V for input purposes.
If you want both GPIO attached to your header, a SIX pin 90 degree header is optimal. The 4 pins that go into the holes in the board hold the header steady. And you then have the means to plug whatever you desire into the GPIO i/o without soldering or risk of damage.
CAT5 wire is also small diameter, but very stiff. You could try a bit of that.
Okay, it seems that all of Heater's software compiles for the WR703N and MR3020 are working. And the GPIO is accessible.
So now I have got my Propeller running in Tachyon and have toggled 4 LEDs on with the MR3020 connected. I will let this run overnight to see if the GPIO Reset is stable for long durations.
Later I will try to get the MR3020 configured to operate without the LAN connected as an independent programmer and serial interface. It may just be that changing to 'STA' on the wifi will do that. But I really want to make sure that I have a stable Reset first.
2) Installed it from the "reflash firmware" button in Luci. Good news: it worked fine.
3) Set up WIFI and installed Luci. Good news: The latest openwrt source code fixed the opkg update problem, they now fetch many Package.tgz files instead of one as specifid in /etcopkg.conf:
Seems there was some rorganizing going on that was not in the opkg.conf I pulled earlier.
4) Tried to install the packages required for the 3g dongle as per these instructions http://wiki.openwrt.org/doc/recipes/3gdongle Bad news: That fails because the file system is now full.
5) OK Try to uninstall Luci to make room for the 3G dongle packages. Bad news that fails because the file system is full !!! WTF?
6) Bad news because now I'm stuck cannot install cannot uninstall. I'm worried that the flash "firmware button" in luci will no longer work because the file system is full.
I guess I will try and delete a bunch of files manually and try the firmware reflash to get back to normal again. Tomorrow....
Comments
I think the opkg update problem is directly related to your NOT using Attitude Adjustment 12.09.
In simple, Openwrt cannot provide repositories for all and everything that people might generate in a custom compile.
Happy to see that the Barrier Breaker repository is working for you. But not sure how stable that might be.
++++++
The easy solution is to load a firmware image that has a repository supported by Openwrt.
The alternative is compile your own set of repository binaries, and Openwrt does support that option. But I suspect you will find it all rather tedious. And you will have to redirect opkg to your custom repository.
Why not let OpenWrt do all the developmental work of providing a stable repository?
Yes, indeed. I'm sure that package problem does not exist in the stable 12.09 release.
Poking around at http://downloads.openwrt.org/ I'm amazed by the huge number of packages there are. However it looks like something has changed in the recent snapshots and the opkg.conf file no longer points to a place with a Packages.gz. I don't know if this is part of some ongoing rearrangement of the repositories or something that just got broken. Still trying to follow what they are up to there. I can see the sources here of course and for sure they are not right.
The easy solution may well to be to use an actual stable release. Part of the reason I did not is that the OpenWRT hardware support page indicates that a custom build is required for my D-LINK. My hunch was that the documentation is old and whatever the required customization was is now in the latest code base. And so it was, it worked without any hacking.And so here I am with the cutting edge sources just begging to be built for the MR3020, the Raspberry Pi and whatever else turns up here. Funny you should say that...Guess what I have been up to last night?
Well, no I'm not about to try and build all the packages but at least one can set an option in "make menuconfig" that gets it to include luci in the image. Mind you, if their build system works then building all the packages would not be tedious, just set it running and whenever it's done it's done. Because.
That's just not fun. Standing on solid ground is OK but does not have the thrill of standing on the edge of a cliff. Standing on the edge gives one a great view.
Somebody has to test this stuff and report bugs. Might as well be me sometimes. It's about as much as I can do by way of returning something to the thousands of people who put billions of hours into making all the open source software we use everyday.
I do like the idea that if you are using open source software you can build it yourself. So why not? That is kind of the point is it not?
That's why my home machines run Jessie instead of Wheezy. It's why I'm endlessly rebuilding propgcc, SimpleIDE, the open source Spin compiler etc etc.
It's about wanting to be part of a happening rather than just watching it from outside.
I take a more conservative approach these days. It is obvious that OpenWrt provides a bare bones installation in Attitude Adjustment with the stable repositories. For a lot of users, that alone is a huge learning curve.
OpenWrt also provides the second, more ambitious path for anyone that wants to participate as a developer and maybe hack any entirely new devices. While you seem to enjoy that, I get rather lost in it. Nonetheless, I have learned much by doing the one compile run I did, and will do more at a leisurely pace.
In sum, just think of this as TWO separate ways to participate in OpenWrt. And you are taking the one that expects more experience. While I am taking the newbie's route.
++++++++++
Meanwhile, back in Attitude Adjustment 12.09 land,
I have been trying to do a few sanity checks before getting into downloading a binary with pi-propeller-loader.
A. Verify my GPIO29 is working (It does, but at 2.71V, adding a 10K pullup is not quite right)
B. Determine if I can still reach Forth via Rx/Tx with the GPIO as Reset attached. (Not yet)
=========
Sadly, problems have arose.
It seems that the Openwrt default for GPIO29 even without the pull down resistor is LOW. That means that as long as the Reset is attached in that context, the Propeller is in a suspended reset condition.
To eliminate that condition I have been manually entering the following:
echo 29 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio29/direction
echo 1 > /sys/class/gpio/gpio29/value
But I see yet another item in the /sys/class/gpio/gpio29..........
which is active_low and it is defaulted to 0.
I am not sure where that comes into play or if it can wisely be ignored.
When I do try a serial connect through /dev/ttyATH0 in Minicom, I am not reaching the Propeller in Tachyon Forth --- which was working fine before.
+++++++++++
I am not exactly sure what the issues are here. I have tried the GPIO29 wired without a 10K pullup and wired with a 10K pullup. But now my conventional RS232 is not working.
I have yet to go into the inittab and shut out the systems activity on /dev/ttyATH0 and that is 115200 baud while my Tachyon iis 57600 baud. So there might be collision activity.
I will keep trying to sort out what is what. But I need to confirm Tx, Rx, and Reset are all working and coordinated before bothering with attempting a pi-propeller-load, don't I?
+++++++++++
Of course I am a bit concerned that you pi-propeller-load might not take into account the Openwrt defaulting the GPIO to a low output as the standard state. You may have presumed that the 10K pullup would be starting with a pin that is not actively pulling LOW.
So, I am struggling to get back the services I previously resolved as good, and am not sure why.
Mind you, I'm not much into actual danger. Having software not working on my hobby projects can be a nice challenge but sky diving, for example, is probably off my list of things to do, base jumping is right out:)
Most open source projects allow multiple paths of entry. From "here the deb package just go install it", to "here is the source just build it", to "we don't have that feature yet would you like to write it?". Although some projects are quite fussy about who they except patches from, might just be one guy doing his own thing who does not care what you want to add or fix.
About that reset from GPIO:
Ideally when the router is powered up nothing is done with the GPIO you want to use. It stays low, hopefully in it's default state of being an input. We will presume there is a pull up on the Props reset pin somewhere. Cycling the routers power should then never cause a Prop reset.
Of course we don't know what any particular router does with any particular GPIO. For example my reset GPIO drives a blue LED. That LED is flashed very briefly at start up. I have no idea why or where that is happening in the OpenWRT code. Certainly I can't control that LED from Luci or uci.
At some point one would have to track this down an change it in OpenWRT somewhere.
I have not played with any "active_low" or any other tricks you can do with /sys/class/gpio. So far I have not had the need to.
pi-propeller-load sets the GPIO to HIGH before setting direction to "out" when it is started. Of course it leaves the GPIO HIGH on exit. So reset should only be happening in a controlled manner when it actually programs the Prop. Of course pi-propeller-load cannot help you with any reset waggling problems before you run it!
(N.B. "HIGH" in the above could well be "LOW" if you use the reset option to reverse the sense of reset).
Yep, you need to be sure that tx/rx and your GPIO pin are working. You should be able to chat to a Prop running Forth or whatever and make a Propeller reset manually. Then pi-propeller-load has a chance of actually working.
Forgot to mention...
1) pi-propeller-load leaves the GPIO pin exported when it's done. Originally it unexported the GPIO but that causes any access of the GPIO later to not work on my D-LINK for some odd reason.
2) pi-propeller-load leaves the GPIO pin as an output when it's done. Driving out whatever NOT RESET is for you.
I think this is reasonable. Why would we ever want to unexport our reset pin? And we do nee to be not causing another reset on exit.
Well, after pulling everything apart and checking continuity and voltages... Dumbo discovered that the battery powering the Propeller had got too low.
Okay, I do understand the the pi-propeller-load will leave the Propeller Reset High after downloading.
A. Can I do another download, or will that block a second attempt?
B. Can I run an independent GPIO export before download so that I can just use the Propeller's serial port with interfering with the pi-propeller-download?
I will keep trying. It seems as though I am much closer.
You can load the Propeller as many times as you like. I have sometimes done many downloads in quick succession just to check it was some how reliable.
You can use the GPIO how you like before and after a download. In fact I have a little script that exports the GPIO, sets the direction and does an output so that I can issue a propeller reset whenever I like.
I have gotten all the hardware working and varified.
I can bring up Forth via a serial terminal with the GPIO Reset is connected (without a 10K pullup).
So I am just muddling through transfering files over to the MR3020 and running pi-propeller-load. I have the atfty client on the MR3020. I just need to get the server going on my notebook.
The what client? Never heard of it.
What's wrong with scp ?
So I presume that SCP isn't active until I activate SSH.
Looking for an alternative FTP client and daemon pair, I came across atftp and atftpd in the opkg listings.
In truth, this is getting a bit much... so I might just start up SSH and work with whatever I get. I used SCP previously and it works fine.
Tried to use wget locally, but I seem to not understand how to do so.
It has always just worked for me, on these routers, on my PC's, on servers we manage, on other embedded systems.
Mostly the only configuration change I make is whether to allow log in as root or not. In the case of these routers I have not changed anything in ssh configuration.
As soon as you have telnet access to your box you should set a root password and from then on use ssh. As it says in the OpenWRT documentation.
Out of the box I get ssh access from the LAN and the WAN. Only today I was logging into my D-LINK at home form our office over the internet.
As a bonus you get to use scp.
Messing with ftp clients and servers is just making your life more complex and less secure.
It seems I have to learn to configure Dropbear for a second wifi login path.
++++++++++
Additionally, I had high hopes to use the MR3020 as a stand-alone wifi Propeller Programmer. But when I disconnect it from the LAN, the wifi ignores me even without SSH being active.
+++++++++
As so......
I am pretty sure I can verify that your pi-propeller-loader will perform as required.
But that doesn't complete the project. I have several big obstacles to getting a nifty stand-alone wifi Propeller Programmer.
This is all very strange. As I just said normally things "just work". Certainly I have never seen that logging in over ssh on one interface disables some other interface. That is just weird.
However as you are having problems I started playing with ssh into the MR3020 here. I discovered an odd thing:
Firstly my current setup:
1) A d-link connected to the internet.
2) My PC connected to the d-link's lan via WIFI
3) The MR3020 connected to the d-link's lan via WIFI
4) My PC connected to the MR3020 via ethernet.
Now:
a) I can ssh into the d-link from the lan side or from the internet (wan)
b) I could ssh into the MR3020 from its lan side, my PC.
c) BUT I could NOT ssh in from its wan side, from the d-link.
How come? I don't know. I thought there must be some firewall rule in the d-link that allows ssh access on the wan side. Or conversely some firewall rule on the MR3020 that blocks ssh on the lan.
I could not find such rules. I pulled all the /etc/config files out of both boxes and compared them. I could not see any relevant difference!
The solution:
On a hunch, using Luci on the MR3020 I added a firewall rule specifically to allow ssh on the wan (I don't have such a rule on the d-link but let's see.)
BINGO it works! Now I can ssh from any box to any other box in my PC-MR3202-DLINK triangle over any of their wan or lan interfaces!
In Luci it's a case of going to "Network->Firewall->Traffic rules" just add a new rule under "Open ports on router".
The relevant firewall rule that Luci creates in /etc/config/firewall looks like this:
config rule option enabled '1' option target 'ACCEPT' option src 'wan' option proto 'tcp' option dest_port '22' option name 'ssh'Now I have to figure out why my dlink allows ssh on wan even without such a rule!
Bottom lines are:
You should not have to mess with dropbear configuration.
One can certainly use the MR3020 as a stand-alone wifi Propeller Programmer.
I just noticed this:
This smells bad. It has happened to me in the past that when I think I'm talking to something over WIFI, for example, I am actually talking to it over ethernet. Then when I think everything is configured nicely I yank out the ethernet cable. BOOM no more communication.
Even when all the interfaces are up and running nicely and all the configs looked OK the packets end up getting routed a different way. Or more subtly they go out over the correct interface a replies come back on a different one.
At this stage if I was you I would blow all that away and install OpenWRT again. Out of the box the the ethernet side works. Just configure WIFI as a "station" and get it to connect to your WIFI router on the internet (I presume you have one). Follow the instructions for that on OpenWRT http://wiki.openwrt.org/doc/recipes/routedclient
N.B. I only did the first part of those instructions for "Using MASQUERADE". This means I can only ssh into the MR3020 over WIFI from my d-link. It is not visible to my PC over WIFI. It's on a different subnet so the routing does not work.
For that one has to continue with the next section "Using routing". I have not done this and perhaps never will. I can access my MR3020 over ethernet when required and it can access the internet via WIFI.
I am just focusing on getting your pi-propeller-load tested.
Then I can deal with the other issues.
So far, I have had no luck using 'sta' mode. I am using 'ap'.
Obviously, there is a lot I don't understand about routers and wifi. But that is why I am exploring OpenWrt. I just have these other items that work toward a goal of an independent Wifi Propeller Programmer and Interface.
At least we can verify your software is 'user ready'..
Now about that serial port....Can I assume it is on the P1 connector?
For some reason none of the images for this on OpenWRT.org are showing up in my browsers today.
HI,
Yes, you can use Pins 30 and 31 on the Propeller directly to the MR3020 Tx and Rx as all are 3.3V ttl. But I did include a 10K pullup at the MR3020 to Tx. Openwrt suggested this.
I have migrated to SSH so that I can use SCP for file transfers. The 'atftp' and 'atftpd' is a distraction. More importantly, by waiting until after I settled on my configuration to start Dropbear, I have both wifi and LAN access.
Openwrt pushes on to enter a password right away. Once Dropbear is in place, configuration changes may be the source of being shut out.
++++++++++
I did rebuild my bench setup to have everything on AC mains. The MR3020 and Propeller were left running overnight to see how stable the Tx, the Rx, and especially the Reset were. I left the GPIO29 in a High.
But somewhere along the way, the GPIO29 was dumped and no longer in /sys/class/gpio/ I am a bit unsure if I inadvertently reset the MR3020 or what. This will require more careful investigation.
I am NOT using a 10K pullup or capacitor on the GPIO29 at this time. It seems that there is an internal pullup in the Proeller that is driving the High to about 3.1volts. The GPIO209 unconnected will only drive 2.71v in High.
+++++++++
Meanwhile, I have to just transfer my files via SCP and run a pi-propeller-load to test the set up. I will be back a bit later today with results.
But my GPIO29 has disappeared from the /sys/class/gpio/ and a message appears that it cannot locate the Propeller.
I have to review how the -D feature designates the GPIO and try again.
I just worked up enough courage to remove R15 and R17 (GPIO 7 and 29).
They seemed to take a lot heat before they jumped off. Are they using some kind of lead-free solder there that melts at a higher temperature?
I have control of GPIO 29. Having a bit of bother finding a wire small enough to go on that tiny pad.
Serial port pads now have a header. Nearly there.
I used -Dreset=gpio,29,0
But, it seems that the /dev/ttyATH0 serial port is not released after programing... so I was forced to reboot the MR3020 after programming the Propeller in order to reuse /dev/ttyATH0 via Minicom to the Propeller.
Conclusions.
A. The pi-propeller-load_mips34kc binary is working properly to download a binary to EEPROM
B. It seems that after using, the /dev/ttyATH0 serial port remains attached and not available. So it is necessary to reboot the MR3020 to use /dev/ttyATH0 for a serial terminal.
C. The reboot process dumps the GPIO29 configuration and that resets the Propeller
So we do have a working pi-propeller-download, but reviving communications with the Propeller after a download seem to require resetting the MR3020 and reconfiguration of the GPIO29. (Until GPIO29 is reconfigured HIGH, the Propeller may be doing spurious resets.
____
NOTE - My GPIO29 does NOT have a 10K pullup to 3.3v. But I found that even with such, the pin would read 0.6V if not specifically configured Export/Out/High.
I can insert the 10K pullup and run further tests, but it seems as if the defaults in the OpenWrt firmware are pulling GPIO29 low on reboot.
And regarding /dev/ttyATH0 not being released...
I have had similar problems using SER2USB on other Linux systems. One doesn't have to always reboot the system, but the alternative is to go in as system administrator and release the serial port. I am not quite clear on how to do that or whether doing so is worth the trouble. I can easy include a script to bring GPIO29 back to export/out/high.
#!/bin/sh
echo 29 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio29/direction
echo 1 > /sys/class/gpio/gpio29/value
+++++++++++++
I suppose Heater wants to have me test the ability of the MR3020 to compile Spin code now.
The following commands : Do actually leave GPIO 29 high and low (or is it the other way around?) I have checked with my meter.
Still trying to find the fine wire to attach to there.
Could you try: The -t should get you a terminal running at the specified baud rate. Then you should see your Forth chirping up.
A. I used wirewrap wire for the GPIO leads
B. I hope you use a 90 degree four pin header as it will allow you to later close up the box.
OR even better use a FIVE pin 90 degree header and bend one pin straight for the GPIO wire. The other four go into the holes on the board.
C. I really think you may only see about 2.70 volts as your logic high regardless of how carefull your construction. There is some indication that this board i/o outputs only 2.8, but I have no direct verification.
D. My GPIO is direct -- no 10K pullup and no 100p capacitor at this time. (I constructed so I can insert these if need arises.)
+++++++++++
I am finding the 2.70 volt GPIO High is adequate and drives a Reset to the Propeller while the Propeller remains stable as long as the GPIO remains High.
And yes, I am sure these are ROHS lead-free boards with higher temperature solder.
Ah, this seems handy. But I a bit uncertain. I have to use Minicom (in the MR3020) as the Terminal software. I will try another binary load a bit later and see if that stops all the reboot nonsense.
I don't have a 90 degree header here. I'll be able to close up the box though.
That 2.7 volts seems to be about right. I think I measured 2.72. I was surprised it was so low.
The GPIO may provide only 2.7V, but does seem to tolerate 3.3V for input purposes.
If you want both GPIO attached to your header, a SIX pin 90 degree header is optimal. The 4 pins that go into the holes in the board hold the header steady. And you then have the means to plug whatever you desire into the GPIO i/o without soldering or risk of damage.
CAT5 wire is also small diameter, but very stiff. You could try a bit of that.
So now I have got my Propeller running in Tachyon and have toggled 4 LEDs on with the MR3020 connected. I will let this run overnight to see if the GPIO Reset is stable for long durations.
Later I will try to get the MR3020 configured to operate without the LAN connected as an independent programmer and serial interface. It may just be that changing to 'STA' on the wifi will do that. But I really want to make sure that I have a stable Reset first.
I did not get around to sorting out my Propeller connection.
No luck with the 3G USB dongle either.
When I follow the instruction here: http://wiki.openwrt.org/doc/recipes/3gdongle I only get:
[23246.710000] usb 1-1: new high-speed USB device number 5 using ehci-platform
When plugging in the dongle. Not at all what the instruction say we should expect.
I'm just now rebuilding the MR3020 imaged with USB 3G support as detailed here:http://wiki.openwrt.org/doc/howtobuild/wireless-router-with-a-3g-dongle
Somehow I knew this was not going to be easy....
1) Rebuilt the MR3020 image as per http://wiki.openwrt.org/doc/howtobuild/wireless-router-with-a-3g-dongle
2) Installed it from the "reflash firmware" button in Luci. Good news: it worked fine.
3) Set up WIFI and installed Luci. Good news: The latest openwrt source code fixed the opkg update problem, they now fetch many Package.tgz files instead of one as specifid in /etcopkg.conf: Seems there was some rorganizing going on that was not in the opkg.conf I pulled earlier.
4) Tried to install the packages required for the 3g dongle as per these instructions http://wiki.openwrt.org/doc/recipes/3gdongle Bad news: That fails because the file system is now full.
5) OK Try to uninstall Luci to make room for the 3G dongle packages. Bad news that fails because the file system is full !!! WTF?
6) Bad news because now I'm stuck cannot install cannot uninstall. I'm worried that the flash "firmware button" in luci will no longer work because the file system is full.
I guess I will try and delete a bunch of files manually and try the firmware reflash to get back to normal again. Tomorrow....
heater, hopefully you will get over this latest issue. Don't forget to log a bug report
BTW i see you are using the new caos calmer test version. Nothing like cutting edge.