The CPU architecture I'm compiling for is "mipsel_24kec+dsp" or at least that's what's in the name of the tool chain.
According to the OpenWRT hardware pages it's an Ralink RT288x/RT305x.
When I build OpenWRT from source code I select: "Target System = Ralink RT288x/RT3xxx" and "Subtarget = RT288x based boards".
Now that I look at the config options I notice there is are Subtarget options of MT7620n and MT7620a based boards. So it looks like there is some chance.
The CPU architecture I'm compiling for is "mipsel_24kec+dsp" or at least that's what's in the name of the tool chain.
According to the OpenWRT hardware pages it's an Ralink RT288x/RT305x.
When I build OpenWRT from source code I select: "Target System = Ralink RT288x/RT3xxx" and "Subtarget = RT288x based boards".
Now that I look at the config options I notice there is are Subtarget options of MT7620n and MT7620a based boards. So it looks like there is some chance.
I noticed quite a few routers are using the MT7620N or A including IIRC later versions of the 615. Its based on the MIPS 24K series.
This new one has 32MB RAM and 4MB FLASH with the MT7620N. There are 2 small test points which may be the serial and 2 larger which are likely power and gnd. There is no USB brought out and just 1 Ethernet. The aerials (2) are copper strips above and soldered to the pcb. I will post pics later. IIRC this was ~$15 shipped.
It seems that even if the CPU architecture is the same there can be a lot of variation in peripherals or boot loaders or recovery methods etc etc etc
So this machine may or may not be easily usable with OpenWRT out of the box. Somebody has to get one and try it out, perhaps spending hours reverse engineering this and that and reconfiguring things to make it work.
Thing is, I'm not really into that. I find it hard enough to get things working when all the information required is under my nose:)
And there are many other projects in the queue.
The d-link thing here just happened to be in my possession and happen to work else I would have given up with OpenWRT already.
I quite like to tweak with things like the loader though, if they are generally applicable for others out there.
10K pull up +
160 ohms in series with reset signal from router +
100nF cap to ground.
Now I can poke around with multimeter as much as I like without triggering a reset. It does not reset when I unplug my soldering iron. I can disconnect the programming link back to the router and things keep running.
Before I make this a permanent construction on the proto board are there any suggestions?
Yes, I simulated it in LTSpice. Too lazy to do all that ohms law and time constant stuff:) Component values are just what happened to be at the bottom of my parts bucket, which is looking depressingly empty now a days.
heater, you shouldnt need the 100nF cap, at least not anywhere near this large. Therefore, i would suggest you may have a noisy power supply or ground loops. Do you have proper decoupling caps on the prop? Decoupling caps at the input and output pins of the regulator, a100uF bulk cap on the input to the reg? Seems to that you are only masking an underlying problem.
As for the router, i just wanted to see what cheaper options were around as i intend to use a reasonable qty. i am quite happy where we are at now. Later i will have a go at building a binary for my 703 and later perhaps another router like the mini300. But first i want to complete the task at hand.
I am following your suggestion about reset, but haven't yet decided on what to build. And I am willing to build several alternatives and try them all.
Just using a diode as Cluso first mentioned seems the easiest, most direct.
I am NOT using length wires, about 8 inches total.
Right now I am trying to get the tool chain for the AR7xxx installed.... decided to skip an IDE for this unless it becomes obviously necessary.
As far as I can tell the resistor ratio in that little reset circuit has to be such that the output voltage can get low enough to reset the Prop. Given that the input might not actually be down to 0v.
Then the capacitor/resistor time constant is filtering out unwanted high frequency Smile. At the cost of increasing rise time on coming out of reset.
So far I have not found a spec for the Propeller which tells me how low reset has to be to achieve reset or if there is any requirement on minimum rise time of coming out of reset.
So, 100nF does seem excessive but in the absence of a spec it's as good as any other value that happens to work.
Currently I have a DIP Prop welded to a PCB proto board. All power and grounds in place. Two 100nF decoupling caps across the supply as near to the pins as I can manage.
The power supply is a 5 cell 6v NiMh batter pack. There is 100nF in front of the regulator, as per the data sheet of the original reg I had in there. There is a 10uF electolytic on the reg output. Tantalum would be better in low temperatures according to the regulator spec.
Much of this arrangement is down to spec reading and intuition but mostly down to what is left in my almost empty parts bucket:) I'd feel happier with some more bulk capacitance on the rails for example.
I'll post pictures of this creation if I can get enough light for my phone camera to work properly.
I'm planning a visit to our local electronics store to get some nicer regulators and stock up on jelly bean parts so any suggestions for changes are welcome.
What IDE? I did not know OpenWRT had or suggested one.
For sure an IDE is not necessary to build OpenWrt. In fact it's no doubt easier without one and when the going get's tough an IDE is never necessary, more can be done on the command line than any IDE can imagine.
I have not even begun to think about battery charging circuits, battery stand by circuits, trickle or other charging.
From time to time over the last couple of years I have spent some hours googling around for battery advice. It's mind bending. Do you have NiCad, Lipo, NiMh...what is the best way to charge each of those...is there a minimum discharge voltage...do they need a deep discharge before recharging...do they have "memory effect"..da da da ??
Last thing I read is that modern NiMh don't have a memory effect, it's a myth hanging around from some old technology that did.
So my current plan is: I have a 1600mAh 6v NiMh battery pack. Dead convenient for applying power to stuff. If it does deliver enough current to let the magic smoke out real fast!
When it's charged it puts out 7.2 or so volts. When it gets down to 5v it goes in the charger. Let's see how long that works out?
It may all be nonsense to you, but when one reads the curves in the PDFs for specific LDO regulators, the problem becomes clear.... quiescent curve may go up 200-300%.
If you desire to claim that the device is merely a variable resistor, go right ahead. But it seems obvious that something else is actually in use.
Hmmm...interesting...
That LM2940/LM2940C you linked to seems to be particularly crappy[ 1 ]. You are right there, is a graph in that data sheet that shows quiescent current rocketing up as the input voltage falls into the "LDO region". Especially at higher load currents.
Meanwhile the reg I have installed now claims to have a max quiescent of 14ma and the one I blew up previously claims about 8ma. Both are good for almost 1 amp. There is for sure no mention of current escalating at lower voltages.
So, yes I said "variable resistor", it seems these can also be leaky [ 2 ] variable resistors and the one you have looked at is particularly horribly leaky.
Whose specs can we trust?
Once again. This calls for an experiment....
Notes:
1. "Crappy" here means does not look very good for what I might want to do but might be fine elsewhere.
2. "Leaky" - We are so used to dealing with abstractions in electronics. The lumped circuit analysis, for example, where we have pure resistors, capacitors, inductors etc connected together by wires with no resistance, capacitance or inductance. Of course all these abstractions leak or break down at some point. A typical circuit is more like a wobbly jelly where every part interacts with every other part via electromagnetic fields.
So yes, my description of a regulator is very leaky as well. But serves it's purpose.
As far as I can tell the resistor ratio in that little reset circuit has to be such that the output voltage can get low enough to reset the Prop. Given that the input might not actually be down to 0v.
Then the capacitor/resistor time constant is filtering out unwanted high frequency Smile. At the cost of increasing rise time on coming out of reset.
So far I have not found a spec for the Propeller which tells me how low reset has to be to achieve reset or if there is any requirement on minimum rise time of coming out of reset.
So, 100nF does seem excessive but in the absence of a spec it's as good as any other value that happens to work.
Currently I have a DIP Prop welded to a PCB proto board. All power and grounds in place. Two 100nF decoupling caps across the supply as near to the pins as I can manage.
The power supply is a 5 cell 6v NiMh batter pack. There is 100nF in front of the regulator, as per the data sheet of the original reg I had in there. There is a 10uF electolytic on the reg output. Tantalum would be better in low temperatures according to the regulator spec.
The 10uF electro is likely to be doing a poor job. But since the input is a battery, it should be ok. For now, put another 10uF close to the prop power pins.
I do think you have a different problem to reset. Now you are preventing reset, you may find strange behaviour in the prop due to brownout type events (noise induced on the power rail) or ground loops. Something seems amiss to me anyway.
Much of this arrangement is down to spec reading and intuition but mostly down to what is left in my almost empty parts bucket:) I'd feel happier with some more bulk capacitance on the rails for example.
I'll post pictures of this creation if I can get enough light for my phone camera to work properly.
I'm planning a visit to our local electronics store to get some nicer regulators and stock up on jelly bean parts so any suggestions for changes are welcome.
OK, get some 1uF, 10uF and 47uF tantalums and 100uF electrolytic caps. Tantalums are likely to be 35V although you don't need this high normally. Same with electro. Of course you will need some 100nF - see if you can get X7R but that may not be possible as usually they are cheapo Z5Us (usually not specified). And the prop uses 10nF too.
If you want to do audio, then a few 4.7uF electros.
Common resistors used are 100R, 470R, 1K, 3K3, 10K. I like the tiny 1/4W that are 1/10W size but you probably cannot get these either. Also look at the values used in the VGA and TV prop circuits.
I have decided that 5V USB is the way to power new boards. Therefore I can use smaller LDO regs - t/hole TO93 or larger TO220 (I use smt but they are not good for breadboards).
The Microchip MCP1700 and MCP1702 are nice. So too are the LM1118 series.
I have not even begun to think about battery charging circuits, battery stand by circuits, trickle or other charging.
From time to time over the last couple of years I have spent some hours googling around for battery advice. It's mind bending. Do you have NiCad, Lipo, NiMh...what is the best way to charge each of those...is there a minimum discharge voltage...do they need a deep discharge before recharging...do they have "memory effect"..da da da ??
Last thing I read is that modern NiMh don't have a memory effect, it's a myth hanging around from some old technology that did.
So my current plan is: I have a 1600mAh 6v NiMh battery pack. Dead convenient for applying power to stuff. If it does deliver enough current to let the magic smoke out real fast!
When it's charged it puts out 7.2 or so volts. When it gets down to 5v it goes in the charger. Let's see how long that works out?
As I understand, memory effect is a NiMh thing. The later LiPOs solved this although if not carefully charged they are liable to catching fire. There is a new technology coming - at them moment used in cars etc - LiFePO???
Anyway, what you have is nice. Maybe connect it to a tiny breadboard where you can add a couple of regulators and shunts to select. Put a picofuse or more on the board - 250mA / 500mA / 1A. Maybe get a few on your electronics store trip.
I am following your suggestion about reset, but haven't yet decided on what to build. And I am willing to build several alternatives and try them all.
Just using a diode as Cluso first mentioned seems the easiest, most direct.
I am NOT using length wires, about 8 inches total.
Right now I am trying to get the tool chain for the AR7xxx installed.... decided to skip an IDE for this unless it becomes obviously necessary.
8" on a reset line can be considered long whereas a normal ttl may not be. Thing is, the reset line may not be being driven as the driver may be tristate. This means it acts like an aerial to whatever noise is around. WiFi (any transmitter) will induce into lines if they are close enough!!!
I didn't actually answer heater as to the reset value. IIRC the reset has a hysteresis in the prop so that you could likely safely assume 1V minimum (need to really check the spec tho) so a 1n914 or 1N4148 would do fine.
A question. I can likely devote an old laptop to Linux so thinking this may be the best to compile OpenWRT on.
What Linux derivative/version would you think about installing? My laptop is a Celeron M440 1.5GHz and 2GB DDR2.
Would you make a Virtual Machine for it, boot from CD/DVD, external USB (HDD or memory stick)? If possible, I would rather keep my Windows contents, but not absolutely necessary. The HDD is 40GB.
I can remove that cap on the reset, or downsize it, if you think there is something else going on here I'm curious to find what it is.
The "memory effect" in NiMh batteries is impossible to pin down. The debate about it on the googleTubes is endless. Some say it is real, others say it's a myth, some say it did exist in some older chemistry, seems that even some battery data sheets (Sanyo) say it's real and other don't, some say it is a real effect but not normally significant enough to notice da, da, da.
My conclusion: I don't care.
I'm not about to start studying NiMH data sheets from all the manufactures. No use if I did because I have no idea who made these cells. No doubt next time I will get something different anyway.
I'm not about to start testing my batteries for it. Sounds like a very long winded process. And again who knows what you buy next.
No, my cells will be treated like big capacitors, with the exception of being charged by a slightly smart charger with a cut out and perhaps not completely discharged all the time.
I like your idea of a little board on the battery to make a tiny "wireless" bench top power supply. It could have "raw" and regulated 5v and 3.3v outputs. Perhaps a battery voltage display even. Fuses would have saved my recent experiments, it seems a current limit circuit would be a good idea. This is a whole other project now!
Re: Linux on the laptop,
First thing I would do is get a Linux "live" CD and boot the thing up with that. That way you can check the everything on the machine is Linux friendly and works, ethernet, graphics etc etc. A live CD is nice because it does not touch the HD at all.
Debian is my OS of choice so perhaps you could try the Debian live CD, I have yet to spin that up myself. https://www.debian.org/CD/live/
With only 2GB of RAM I would not be looking at using a virtual machine and perhaps 1.5GHz is a bit slow for that. So I'm going to suggest scrapping the Windows install.
What you could do is copy that 40GB hard drive image over to a USB stick or something, whilst running Linux from the live CD, then you have it backed up in case you ever want it back again. It's a vary simple thing to do.
"Is it a worthwile distraction???" - Good God man, investing a little time in getting to grips with some Linux/Unix will be the best investment into computing know how you ever make!
I would not even consider messing with building OpenWRT on anything but a Linux box. It is a Linux system after all.
I like to run Debian with KDE as the desktop. It's the least ugly of them all to my eye and I love the konsole terminal. It's certainly better than the default desktop of Debian. KDE might be a bit heavy weight and slow for your old machine, it helps to turn off all the animations and other useless eye candy, so the LXDE desktop might be better. The live CD iso images are here:
Little diversion...
Here is the serial output on the Vonets Mini300 (The large test points on the underside, TXD closest to the corner of the chip, 57600 baud)
BTW took a punt on these first and even got the TX & RX the correct way around - what a fluke! (oops that's a registered tm of someone
============================================
Ralink UBoot Version: 4.2.S.1
ASIC 7620_MP (Port5<->None)
DRAM component: 256 Mbits SDR
DRAM bus: 16 bit
Total memory: 32 MBytes
Flash component: SPI Flash
Date:May 26 2014 Time:14:52:34
============================================
icache: sets:512, ways:4, linesz:32 ,total:65536
dcache: sets:256, ways:4, linesz:32 ,total:32768
##### The CPU freq = 600 MHZ ####
estimate memory size =32 Mbytes
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
3: System Boot system code via Flash.
## Booting image at bc050000 ...
raspi_read: from:50000 len:40
Image Name: Linux Kernel Image
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 3212295 Bytes = 3.1 MB
Load Address: 80000000
Entry Point: 8000c2f0
raspi_read: from:50040 len:310407
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 8000c2f0) ...
## Giving linux memsize in MB, 32
Starting kernel ...
LINUX started...
THIS IS ASIC
Linux version 2.6.36 (root@ht) (gcc version 3.4.2) #1 Mon May 26 15:03:55 CST 2014
The CPU feqenuce set to 600 MHz
MIPS CPU sleep mode enabled.
PCIE: bypass PCIe DLL.
PCIE: Elastic buffer control: Addr:0x68 -> 0xB4
disable all power about PCIe
PCIE: PLL power down for MT7620N
CPU revision is: 00019650 (MIPS 24Kc)
Software DMA cache coherency
Determined physical RAM map:
memory: 02000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
Normal 0x00000000 -> 0x00002000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00002000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS1,57600n8 root=/dev/ram0 console=ttyS0
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Primary instruction cache 64kB, VIPT, , 4-waylinesize 32 bytes.
Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
Writing ErrCtl register=0000000c
Readback ErrCtl register=0000000c
Memory: 18788k/32768k available (3699k kernel code, 13980k reserved, 677k data, 9036k init, 0k highmem)
NR_IRQS:128
console [ttyS1] enabled
Calibrating delay loop... 399.36 BogoMIPS (lpj=798720)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource Ralink Systick timer
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RT3xxx EHCI/OHCI init.
fuse init (API version 7.15)
msgmni has been set to 36
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered (default)
HDLC line discipline maxframe=4096
N_HDLC line discipline registered.
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x10000500 (irq = 37) is a 16550A
serial8250: ttyS1 at MMIO 0x10000c00 (irq = 12) is a 16550A
brd: module loaded
deice id : ef 40 16 0 0 (40160000)
W25Q32BV(ef 40160000) (4096 Kbytes)
mtd .name = raspi, .size = 0x00400000 (0M) .erasesize = 0x00000004 (0K) .numeraseregions = 65536
Creating 5 MTD partitions on "raspi":
0x000000000000-0x000000400000 : "ALL"
0x000000000000-0x000000030000 : "Bootloader"
0x000000030000-0x000000040000 : "Config"
0x000000040000-0x000000050000 : "Factory"
0x000000050000-0x000001000000 : "Kernel"
mtd: partition "Kernel" extends beyond the end of device "raspi" -- size truncated to 0x3b0000
rdm_major = 253
SMACCR1 -- : 0x00000017
SMACCR0 -- : 0x13175942
Ralink APSoC Ethernet Driver Initilization. v3.0 256 rx/tx descriptors allocated, mtu = 1500!
SMACCR1 -- : 0x00000017
SMACCR0 -- : 0x13175942
PROC INIT OK!
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
PPP MPPE Compression module registered
NET: Registered protocol family 24
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver net1080
usbcore: registered new interface driver cdc_subset
usbcore: registered new interface driver zaurus
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
USB Serial support registered for opticon
usbcore: registered new interface driver opticon
nf_conntrack version 0.5.0 (293 buckets, 1172 max)
IPVS: Registered protocols ()
IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
IPVS: ipvs loaded.
ip_tables: (C) 2000-2006 Netfilter Core Team, Type=Restricted Cone
TCP cubic registered
NET: Registered protocol family 17
L2TP core driver, V2.0
PPPoL2TP kernel driver, V2.0
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
Freeing unused kernel memory: 9036k freed
Algorithmics/MIPS FPU Emulator v1.5
devpts: called with bogus options
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
rt3xxx-ohci rt3xxx-ohci: RT3xxx OHCI Controller
rt3xxx-ohci rt3xxx-ohci: new USB bus registered, assigned bus number 1
rt3xxx-ohci rt3xxx-ohci: irq 18, io mem 0x101c1000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after
rt3xxx-ehci rt3xxx-ehci: Ralink EHCI Host Controller
rt3xxx-ehci rt3xxx-ehci: new USB bus registered, assigned bus number 2
rt3xxx-ehci rt3xxx-ehci: irq 18, io mem 0x101c0000
rt3xxx-ehci rt3xxx-ehci: USB 0.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
rt635x_tssi0_dc is 0xffffffff
rt635x_tssi1_dc is 0x00000000
rt635x_tssi0_dc is 0x00000000
rt635x_tssi1_dc is 0x00000000
rt635x_tssi0_dc is 0xffffffff
rt635x_tssi1_dc is 0x00000000
0x1300 = 00064380
rt635x_tssi0_dc is 0x00000000
rt635x_tssi1_dc is 0x00000000
rt635x_tssi0_dc is 0xffffffff
rt635x_tssi1_dc is 0x00000000
rt635x_tssi0_dc is 0xffffffff
rt635x_tssi1_dc is 0x00000000
0x1300 = 00064380
Raeth v3.0 (Tasklet,SkbRecycle)
phy_tx_ring = 0x00f30000, tx_ring = 0xa0f30000
phy_rx_ring0 = 0x00f31000, rx_ring0 = 0xa0f31000
SMACCR1 -- : 0x00000017
SMACCR0 -- : 0x13175942
CDMA_CSG_CFG = 81000000
GDMA1_FWD_CFG = 20710000
device ra0 entered promiscuous mode
device apcli0 entered promiscuous mode
device eth2 entered promiscuous mode
br0: port 3(eth2) entering learning state
br0: port 3(eth2) entering learning state
br0: port 2(apcli0) entering learning state
br0: port 2(apcli0) entering learning state
br0: port 1(ra0) entering learning state
br0: port 1(ra0) entering learning state
br0: port 3(eth2) entering learning state
br0: port 2(apcli0) entering learning state
br0: port 1(ra0) entering learning state
br0: port 3(eth2) entering learning state
br0: port 3(eth2) entering learning state
br0: port 2(apcli0) entering learning state
br0: port 2(apcli0) entering learning state
br0: port 1(ra0) entering learning state
br0: port 1(ra0) entering learning state
switch register base addr to 0xb0000300
write offset 0x1c, value 0x1
write offset 0x4, value 0xf812039f
br0: port 3(eth2) entering forwarding state
br0: port 2(apcli0) entering forwarding state
br0: port 1(ra0) entering forwarding state
What IDE? I did not know OpenWRT had or suggested one.
For sure an IDE is not necessary to build OpenWrt. In fact it's no doubt easier without one and when the going get's tough an IDE is never necessary, more can be done on the command line than any IDE can imagine.
Hi,
I decided to skip establishing the Ar7xxx tool chain inside an IDE. But I was looking at Code Block. It all seems to just add another distraction to getting the job done.
Events have conspired against any projects. My main compile computer seems to have developed a Segmentation Fault when I try to use Synaptic, Apt-get, or Aptitude -- which I need to resolve tool chain dependences.
And so, I have have to deal with some very unwanted System Administration work for the next few days. I guess I will back up my /home director and simply reinstall Linux on the computer.
+++++++++++++++
Meanwhile the MR3020 is working well and I am still trying to get the /etc/config/network and /etc/config/wireless to work the way I desire.
Reaching the Propeller and programing in Tachyon works fine via Lan for now. I have to go teach class, bye
It's the "decided to skip establishing" part I did not understand. It implies there is an "establishing an IDE" step in some OpenWRT instructions somewhere that you are going to skip. I had never seen one and we have not mentioned an IDE here.
But yes, you certainly don't need an IDE to configure and build OpenWRT from sources for your particular router. If at some point you want to do some serious hacking on it then you might want to load parts of the source, a kernel module, an application, into an IDE. Me, I'd just use vim or Sublime Text.
That Seg fault sounds bad. When I get chicken and egg failures in the package system like that I generally give up and reinstall the whole thing.
Is that Debian or Ubuntu? What have you in /etc/apt/sources.list? What have you been installing recently?
I asked because I have only ever seen these chicken and egg packager problems after pointing source.list to some odd, non-debian, repository in order to install some software that is not available in the current Debian. What happens is that the repo you point at and the package you install also kindly installs all the dependencies it needs. Which could be something like libc. Then you can be screwed because that fundamental library is not the right version for your running system. Programs fail, dependencies are broken. Updating becomes impossible etc etc.
Routers off the shelf have a firmware upgrade feature some where in their WEB interfaces that can be used to flash OpenWRT. Only works if the OpenWRT image is acceptable to the routers upgrade system. My D-Link would not flash OpenWRT from the normal WEB interface. Luckily it also has a another "secret" WEB interface for firmware flashing only, you need to reboot it with the reset button pressed to get into that.
But the what happens when OpenWRT is installed and you want to upgrade that. OpenWRT has no nice firmware upgrade button in Luci. Again luckily for me the d-links secret upgrade feature still works after OpenWRT is installed.
Previously, I had taken an intresest in the IDE Code Blocks in Linux, so I simply had a 'brain wave' that I might install the AR7xxx tool chain in that. Maybe I will eventually get all and everything in Code Blocks, but not now.
So after looking at what OpenWrt desires and what a simple, direct propeller-loader compile requires I decided to abandon it. OpenWrt compile instructions are a bit involved, but that is because they comply with the whole concept of OpenWrt and opkg.
The pi-propeller-load as merely an executable that doesn't required all that formality. So I do see that it can be done more easily and more directly at the Command Line and by just getting the right tool-chain for the AR7xxx cross-compile. I was about to do so when I discovered my Apt-get was haywire.
=======
It is rather embarrassing to how many times I have been side-tracked in getting a good MR3020 to work the way I desired.
There was the cold solder joint problem in the header that I wasted a lot of time pondering. But also a few other items that I didn't mention as they distract the thread from the main project.
I really don't know what happened to my Linux Mint on the computer that is giving a segmentation fault, but it does seem that the repository got off into something odd. It may have been download from a Chinese repository, which I generally avoid doing and that certain seems odd aas Mint doesn't even support Asian languages.
I don't really like Mint anyways, so I am just migrating the machine to Debian Wheezy to make all my machines pure Debian.
++++++++++++++
And I see that my Propeller Protoboard has the barest of Reset circuitry on it. So I am looking at what seems most prudent to provide in the MR3020 without just junking up the Reset with excess complexity. I had mention before that this had been a huge topic of discussion and speculation in the past. But my attitude is to keep in simple if at all possible.
My teaching load doubled recently, so my pace of participation here has slowed. I will get to this when I can. But I really have to be sure I have backed up my /home directory before I get into reloading Linux. That will take a few tedious hours to dd the whole partition and zip it. And then I may rsynch it as well to have a copy that I can actually view individual files in.
==========
If I get impatient, I may just try to compile on my EEEpc notebook.
Upgrading to Debian seems like a very good idea. I like to install it with no desktop at all, you have to uncheck the desktop selection at install time, and then install KDE. It's a lot less ugly than the default desktop.
Installing FireFox and Google Chrome has a catch or two. Chrome for example installed the "debian way" does not play well with this forum. Oddly the same version installed directly from Google does.
The default browser in Debian is IceWeasle, an old and messed up version of Firefox. I just uninstall it if I ever see it.
I have some notes on making a nice Debian installation for development work, if only I could get Luci to allow you to access my server at home...
Using dd to back things up does not seem like a good idea.
1) It will copy the entire disk/partition image even if there is a lot of empty space. The back up is bigger than need be.
2) Restoring it is messy. You need to create a new partition on a disk of the correct size, then find the offset on the disk where that new partition is. Then dd the backup onto the disk at that offset. Make a mistake and you have buggered up whatever else is on the disk.
Better to use tar and gzip on the actual directories you want to back up. Better to get a remote backup/synch done. To more than one place of course.
heater,
absolutely fantastic progress! i nrever expected to be able to compile spin on the router.
btw i know how you feel. had to clean my table last week as little boys were coming to dinner on the w/e -grandsons 3 & 5.
i miss our old house - had my own office 20x12ft with desk down one side and bookshelves over cupboards down the other, and a gigantic 3 car garage - one housed my mini/mainframe.
@Heater
Soldering instructions? How embarrassing...........
Compiled Propeller binaries on the wifi router, and then download? That seems to make possible editing programs on a touchpad and then wirelessly migrating for compile and download.
Will this work with an IPad or Android device? I have been ignoring both, but I am sure other Parallax customers would be very happy to not bother with a more traditional computer setup.
Ken Gracey was asking for solutions for classroom awhile back and this seems like a low cost winner. Several students could share a wifi router as a work group. And in many case, the wifi router might become a key part of a big project.
+++++++++++
Yes I am aware of what dd does. I have a 2Tbyte disk that just stores backups of the various computers I have. Rsync is much more convenient. Zipping anything just makes it a bit slower and harder to get to.
==========
It is hard to keep up as I do have to put my teaching first and have to spend a lot of time running around in hot weather.
Sorry about the solder dig. You know me, a dig here, a dig there. If it's any consolation, recently I have been trying to get into soldering surface mount components for the first time. There have been some accidents....
If you can ssh into the router from your mobile device, what ever it is, then you should be able to edit, compile and load an attached Propeller with Spin code.
Yes, Ken did ask for this kind of solution. I do not think hacking on random routers is a scalable answer. My response to Ken was to employ the Raspberry Pi, it's cheap, it works, it's going to be around for some time. I'm guess you don't want to hear about such practicalities.
Meanwhile. msrobots and myself demonstrated that all this is possible in the browser. Whatever machine the user is running the browser on. msrobots has created what amounts to a Propeller Tool or Simple IDE in the browser that can program a remote Propeller. Like one connected to a router.
Yes, keeping up paying work is probably a good idea. The heat around here is slowing my brain to a halt...
Yet another attempt to post pics - this time with Firefox!
Pics of my Vonets Mini300 sitting on top of WR703N (to show smaller size) and with TX & RX mods
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! That Vonets looks really tiny and sweet. Hope you can get OpenWRT up on it.
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.
Comments
Well:
The CPU architecture I'm compiling for is "mipsel_24kec+dsp" or at least that's what's in the name of the tool chain.
According to the OpenWRT hardware pages it's an Ralink RT288x/RT305x.
When I build OpenWRT from source code I select: "Target System = Ralink RT288x/RT3xxx" and "Subtarget = RT288x based boards".
Now that I look at the config options I notice there is are Subtarget options of MT7620n and MT7620a based boards. So it looks like there is some chance.
This new one has 32MB RAM and 4MB FLASH with the MT7620N. There are 2 small test points which may be the serial and 2 larger which are likely power and gnd. There is no USB brought out and just 1 Ethernet. The aerials (2) are copper strips above and soldered to the pcb. I will post pics later. IIRC this was ~$15 shipped.
It seems that even if the CPU architecture is the same there can be a lot of variation in peripherals or boot loaders or recovery methods etc etc etc
So this machine may or may not be easily usable with OpenWRT out of the box. Somebody has to get one and try it out, perhaps spending hours reverse engineering this and that and reconfiguring things to make it work.
Thing is, I'm not really into that. I find it hard enough to get things working when all the information required is under my nose:)
And there are many other projects in the queue.
The d-link thing here just happened to be in my possession and happen to work else I would have given up with OpenWRT already.
I quite like to tweak with things like the loader though, if they are generally applicable for others out there.
10K pull up +
160 ohms in series with reset signal from router +
100nF cap to ground.
Now I can poke around with multimeter as much as I like without triggering a reset. It does not reset when I unplug my soldering iron. I can disconnect the programming link back to the router and things keep running.
Before I make this a permanent construction on the proto board are there any suggestions?
Yes, I simulated it in LTSpice. Too lazy to do all that ohms law and time constant stuff:) Component values are just what happened to be at the bottom of my parts bucket, which is looking depressingly empty now a days.
As for the router, i just wanted to see what cheaper options were around as i intend to use a reasonable qty. i am quite happy where we are at now. Later i will have a go at building a binary for my 703 and later perhaps another router like the mini300. But first i want to complete the task at hand.
Just using a diode as Cluso first mentioned seems the easiest, most direct.
I am NOT using length wires, about 8 inches total.
Right now I am trying to get the tool chain for the AR7xxx installed.... decided to skip an IDE for this unless it becomes obviously necessary.
As far as I can tell the resistor ratio in that little reset circuit has to be such that the output voltage can get low enough to reset the Prop. Given that the input might not actually be down to 0v.
Then the capacitor/resistor time constant is filtering out unwanted high frequency Smile. At the cost of increasing rise time on coming out of reset.
So far I have not found a spec for the Propeller which tells me how low reset has to be to achieve reset or if there is any requirement on minimum rise time of coming out of reset.
So, 100nF does seem excessive but in the absence of a spec it's as good as any other value that happens to work.
Currently I have a DIP Prop welded to a PCB proto board. All power and grounds in place. Two 100nF decoupling caps across the supply as near to the pins as I can manage.
The power supply is a 5 cell 6v NiMh batter pack. There is 100nF in front of the regulator, as per the data sheet of the original reg I had in there. There is a 10uF electolytic on the reg output. Tantalum would be better in low temperatures according to the regulator spec.
Much of this arrangement is down to spec reading and intuition but mostly down to what is left in my almost empty parts bucket:) I'd feel happier with some more bulk capacitance on the rails for example.
I'll post pictures of this creation if I can get enough light for my phone camera to work properly.
I'm planning a visit to our local electronics store to get some nicer regulators and stock up on jelly bean parts so any suggestions for changes are welcome.
What IDE? I did not know OpenWRT had or suggested one.
For sure an IDE is not necessary to build OpenWrt. In fact it's no doubt easier without one and when the going get's tough an IDE is never necessary, more can be done on the command line than any IDE can imagine.
I have not even begun to think about battery charging circuits, battery stand by circuits, trickle or other charging.
From time to time over the last couple of years I have spent some hours googling around for battery advice. It's mind bending. Do you have NiCad, Lipo, NiMh...what is the best way to charge each of those...is there a minimum discharge voltage...do they need a deep discharge before recharging...do they have "memory effect"..da da da ??
Last thing I read is that modern NiMh don't have a memory effect, it's a myth hanging around from some old technology that did.
So my current plan is: I have a 1600mAh 6v NiMh battery pack. Dead convenient for applying power to stuff. If it does deliver enough current to let the magic smoke out real fast!
When it's charged it puts out 7.2 or so volts. When it gets down to 5v it goes in the charger. Let's see how long that works out?
That LM2940/LM2940C you linked to seems to be particularly crappy[ 1 ]. You are right there, is a graph in that data sheet that shows quiescent current rocketing up as the input voltage falls into the "LDO region". Especially at higher load currents.
Meanwhile the reg I have installed now claims to have a max quiescent of 14ma and the one I blew up previously claims about 8ma. Both are good for almost 1 amp. There is for sure no mention of current escalating at lower voltages.
So, yes I said "variable resistor", it seems these can also be leaky [ 2 ] variable resistors and the one you have looked at is particularly horribly leaky.
Whose specs can we trust?
Once again. This calls for an experiment....
Notes:
1. "Crappy" here means does not look very good for what I might want to do but might be fine elsewhere.
2. "Leaky" - We are so used to dealing with abstractions in electronics. The lumped circuit analysis, for example, where we have pure resistors, capacitors, inductors etc connected together by wires with no resistance, capacitance or inductance. Of course all these abstractions leak or break down at some point. A typical circuit is more like a wobbly jelly where every part interacts with every other part via electromagnetic fields.
So yes, my description of a regulator is very leaky as well. But serves it's purpose.
I do think you have a different problem to reset. Now you are preventing reset, you may find strange behaviour in the prop due to brownout type events (noise induced on the power rail) or ground loops. Something seems amiss to me anyway. OK, get some 1uF, 10uF and 47uF tantalums and 100uF electrolytic caps. Tantalums are likely to be 35V although you don't need this high normally. Same with electro. Of course you will need some 100nF - see if you can get X7R but that may not be possible as usually they are cheapo Z5Us (usually not specified). And the prop uses 10nF too.
If you want to do audio, then a few 4.7uF electros.
Common resistors used are 100R, 470R, 1K, 3K3, 10K. I like the tiny 1/4W that are 1/10W size but you probably cannot get these either. Also look at the values used in the VGA and TV prop circuits.
I have decided that 5V USB is the way to power new boards. Therefore I can use smaller LDO regs - t/hole TO93 or larger TO220 (I use smt but they are not good for breadboards).
The Microchip MCP1700 and MCP1702 are nice. So too are the LM1118 series.
Anyway, what you have is nice. Maybe connect it to a tiny breadboard where you can add a couple of regulators and shunts to select. Put a picofuse or more on the board - 250mA / 500mA / 1A. Maybe get a few on your electronics store trip.
I didn't actually answer heater as to the reset value. IIRC the reset has a hysteresis in the prop so that you could likely safely assume 1V minimum (need to really check the spec tho) so a 1n914 or 1N4148 would do fine.
A question. I can likely devote an old laptop to Linux so thinking this may be the best to compile OpenWRT on.
What Linux derivative/version would you think about installing? My laptop is a Celeron M440 1.5GHz and 2GB DDR2.
Would you make a Virtual Machine for it, boot from CD/DVD, external USB (HDD or memory stick)? If possible, I would rather keep my Windows contents, but not absolutely necessary. The HDD is 40GB.
Is this a worthwhile distraction???
I'll be off to the store to get those parts, they have a bunch of regulators off the shelf, I was thinking the MC33269DT-3.3G looks nice. Others are [URL]here: http://www.partco.biz/verkkokauppa/index.php?cPath=2075_11_1014_1822[/URL]
I can remove that cap on the reset, or downsize it, if you think there is something else going on here I'm curious to find what it is.
The "memory effect" in NiMh batteries is impossible to pin down. The debate about it on the googleTubes is endless. Some say it is real, others say it's a myth, some say it did exist in some older chemistry, seems that even some battery data sheets (Sanyo) say it's real and other don't, some say it is a real effect but not normally significant enough to notice da, da, da.
My conclusion: I don't care.
I'm not about to start studying NiMH data sheets from all the manufactures. No use if I did because I have no idea who made these cells. No doubt next time I will get something different anyway.
I'm not about to start testing my batteries for it. Sounds like a very long winded process. And again who knows what you buy next.
No, my cells will be treated like big capacitors, with the exception of being charged by a slightly smart charger with a cut out and perhaps not completely discharged all the time.
I like your idea of a little board on the battery to make a tiny "wireless" bench top power supply. It could have "raw" and regulated 5v and 3.3v outputs. Perhaps a battery voltage display even. Fuses would have saved my recent experiments, it seems a current limit circuit would be a good idea. This is a whole other project now!
Re: Linux on the laptop,
First thing I would do is get a Linux "live" CD and boot the thing up with that. That way you can check the everything on the machine is Linux friendly and works, ethernet, graphics etc etc. A live CD is nice because it does not touch the HD at all.
Debian is my OS of choice so perhaps you could try the Debian live CD, I have yet to spin that up myself. https://www.debian.org/CD/live/
With only 2GB of RAM I would not be looking at using a virtual machine and perhaps 1.5GHz is a bit slow for that. So I'm going to suggest scrapping the Windows install.
What you could do is copy that 40GB hard drive image over to a USB stick or something, whilst running Linux from the live CD, then you have it backed up in case you ever want it back again. It's a vary simple thing to do.
"Is it a worthwile distraction???" - Good God man, investing a little time in getting to grips with some Linux/Unix will be the best investment into computing know how you ever make!
I would not even consider messing with building OpenWRT on anything but a Linux box. It is a Linux system after all.
I like to run Debian with KDE as the desktop. It's the least ugly of them all to my eye and I love the konsole terminal. It's certainly better than the default desktop of Debian. KDE might be a bit heavy weight and slow for your old machine, it helps to turn off all the animations and other useless eye candy, so the LXDE desktop might be better. The live CD iso images are here:
http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
Here is the serial output on the Vonets Mini300 (The large test points on the underside, TXD closest to the corner of the chip, 57600 baud)
BTW took a punt on these first and even got the TX & RX the correct way around - what a fluke! (oops that's a registered tm of someone
Hi,
I decided to skip establishing the Ar7xxx tool chain inside an IDE. But I was looking at Code Block. It all seems to just add another distraction to getting the job done.
Events have conspired against any projects. My main compile computer seems to have developed a Segmentation Fault when I try to use Synaptic, Apt-get, or Aptitude -- which I need to resolve tool chain dependences.
And so, I have have to deal with some very unwanted System Administration work for the next few days. I guess I will back up my /home director and simply reinstall Linux on the computer.
+++++++++++++++
Meanwhile the MR3020 is working well and I am still trying to get the /etc/config/network and /etc/config/wireless to work the way I desire.
Reaching the Propeller and programing in Tachyon works fine via Lan for now. I have to go teach class, bye
"...what a fluke!.."
You could say "...what a phluke!.." I guess. It's the same but made in China:)
Good fortune indeed. Can you show us the output of
$ cat /proc/cpuinfo
and
$ lsmod
on that console? Do you have anyway to flash that thing?
I need to connect the Ethernet port and see what I can do. From what I understand I should be able to flash a new OpenWRT binary.
It's the "decided to skip establishing" part I did not understand. It implies there is an "establishing an IDE" step in some OpenWRT instructions somewhere that you are going to skip. I had never seen one and we have not mentioned an IDE here.
But yes, you certainly don't need an IDE to configure and build OpenWRT from sources for your particular router. If at some point you want to do some serious hacking on it then you might want to load parts of the source, a kernel module, an application, into an IDE. Me, I'd just use vim or Sublime Text.
That Seg fault sounds bad. When I get chicken and egg failures in the package system like that I generally give up and reinstall the whole thing.
Is that Debian or Ubuntu? What have you in /etc/apt/sources.list? What have you been installing recently?
I asked because I have only ever seen these chicken and egg packager problems after pointing source.list to some odd, non-debian, repository in order to install some software that is not available in the current Debian. What happens is that the repo you point at and the package you install also kindly installs all the dependencies it needs. Which could be something like libc. Then you can be screwed because that fundamental library is not the right version for your running system. Programs fail, dependencies are broken. Updating becomes impossible etc etc.
I just don't ever do that any more.
Routers off the shelf have a firmware upgrade feature some where in their WEB interfaces that can be used to flash OpenWRT. Only works if the OpenWRT image is acceptable to the routers upgrade system. My D-Link would not flash OpenWRT from the normal WEB interface. Luckily it also has a another "secret" WEB interface for firmware flashing only, you need to reboot it with the reset button pressed to get into that.
But the what happens when OpenWRT is installed and you want to upgrade that. OpenWRT has no nice firmware upgrade button in Luci. Again luckily for me the d-links secret upgrade feature still works after OpenWRT is installed.
Check this out: Yep, OpenSpin cross compiles for OpenWRT with only a tiny change to the Makefile!
I'd be testing it now but I had to clear away my lab, the kitchen table, as we are expecting guests.
Frikken guests, can't they go visit someone else?
So after looking at what OpenWrt desires and what a simple, direct propeller-loader compile requires I decided to abandon it. OpenWrt compile instructions are a bit involved, but that is because they comply with the whole concept of OpenWrt and opkg.
The pi-propeller-load as merely an executable that doesn't required all that formality. So I do see that it can be done more easily and more directly at the Command Line and by just getting the right tool-chain for the AR7xxx cross-compile. I was about to do so when I discovered my Apt-get was haywire.
=======
It is rather embarrassing to how many times I have been side-tracked in getting a good MR3020 to work the way I desired.
There was the cold solder joint problem in the header that I wasted a lot of time pondering. But also a few other items that I didn't mention as they distract the thread from the main project.
I really don't know what happened to my Linux Mint on the computer that is giving a segmentation fault, but it does seem that the repository got off into something odd. It may have been download from a Chinese repository, which I generally avoid doing and that certain seems odd aas Mint doesn't even support Asian languages.
I don't really like Mint anyways, so I am just migrating the machine to Debian Wheezy to make all my machines pure Debian.
++++++++++++++
And I see that my Propeller Protoboard has the barest of Reset circuitry on it. So I am looking at what seems most prudent to provide in the MR3020 without just junking up the Reset with excess complexity. I had mention before that this had been a huge topic of discussion and speculation in the past. But my attitude is to keep in simple if at all possible.
My teaching load doubled recently, so my pace of participation here has slowed. I will get to this when I can. But I really have to be sure I have backed up my /home directory before I get into reloading Linux. That will take a few tedious hours to dd the whole partition and zip it. And then I may rsynch it as well to have a copy that I can actually view individual files in.
==========
If I get impatient, I may just try to compile on my EEEpc notebook.
Advice on soldering is being discussed here as we speak: http://forums.parallax.com/showthread.php/156620-Need-tips-on-soldering
Upgrading to Debian seems like a very good idea. I like to install it with no desktop at all, you have to uncheck the desktop selection at install time, and then install KDE. It's a lot less ugly than the default desktop.
Installing FireFox and Google Chrome has a catch or two. Chrome for example installed the "debian way" does not play well with this forum. Oddly the same version installed directly from Google does.
The default browser in Debian is IceWeasle, an old and messed up version of Firefox. I just uninstall it if I ever see it.
I have some notes on making a nice Debian installation for development work, if only I could get Luci to allow you to access my server at home...
Using dd to back things up does not seem like a good idea.
1) It will copy the entire disk/partition image even if there is a lot of empty space. The back up is bigger than need be.
2) Restoring it is messy. You need to create a new partition on a disk of the correct size, then find the offset on the disk where that new partition is. Then dd the backup onto the disk at that offset. Make a mistake and you have buggered up whatever else is on the disk.
Better to use tar and gzip on the actual directories you want to back up. Better to get a remote backup/synch done. To more than one place of course.
absolutely fantastic progress! i nrever expected to be able to compile spin on the router.
btw i know how you feel. had to clean my table last week as little boys were coming to dinner on the w/e -grandsons 3 & 5.
i miss our old house - had my own office 20x12ft with desk down one side and bookshelves over cupboards down the other, and a gigantic 3 car garage - one housed my mini/mainframe.
Soldering instructions? How embarrassing...........
Compiled Propeller binaries on the wifi router, and then download? That seems to make possible editing programs on a touchpad and then wirelessly migrating for compile and download.
Will this work with an IPad or Android device? I have been ignoring both, but I am sure other Parallax customers would be very happy to not bother with a more traditional computer setup.
Ken Gracey was asking for solutions for classroom awhile back and this seems like a low cost winner. Several students could share a wifi router as a work group. And in many case, the wifi router might become a key part of a big project.
+++++++++++
Yes I am aware of what dd does. I have a 2Tbyte disk that just stores backups of the various computers I have. Rsync is much more convenient. Zipping anything just makes it a bit slower and harder to get to.
==========
It is hard to keep up as I do have to put my teaching first and have to spend a lot of time running around in hot weather.
Sorry about the solder dig. You know me, a dig here, a dig there. If it's any consolation, recently I have been trying to get into soldering surface mount components for the first time. There have been some accidents....
If you can ssh into the router from your mobile device, what ever it is, then you should be able to edit, compile and load an attached Propeller with Spin code.
Yes, Ken did ask for this kind of solution. I do not think hacking on random routers is a scalable answer. My response to Ken was to employ the Raspberry Pi, it's cheap, it works, it's going to be around for some time. I'm guess you don't want to hear about such practicalities.
Meanwhile. msrobots and myself demonstrated that all this is possible in the browser. Whatever machine the user is running the browser on. msrobots has created what amounts to a Propeller Tool or Simple IDE in the browser that can program a remote Propeller. Like one connected to a router.
Yes, keeping up paying work is probably a good idea. The heat around here is slowing my brain to a halt...
Pics of my Vonets Mini300 sitting on top of WR703N (to show smaller size) and with TX & RX mods
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! That Vonets looks really tiny and sweet. Hope you can get OpenWRT up on it.
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.