Thanks to prof_braino I elaborate a bit about my spinneret setup:
I'll try to explain On the network side things are simple. Netmask for ALL is /24 aka 255.255.255.0, gateway for all but the router is the router's IP 192.168.1.1 The core components are:
- A Router setup as 192.168.1.1 (providing dhcp for the 192.168.1.100+ Range)
- My Qnap NAS/Server (castle) setup with a static 192.168.1.10
- The Spinneret is configured at 192.168.1.5
- My Notebook via Wlan 192.168.1.23
It's the easiest way to let the spinneret be a part of your "real" net, as long as its private and you have a router, there are only very few security concerns. Having it this way there is no need at all to modify your routing or your IP addresses.
Some ports are forwarded to the server (22,80 ...) also I can enable a port forwarding to the spinneret from the outside world if the need should arise, but as I have no authentication implemented in propforth nor is there any cryptography available, that's not always on.
At the Moment the Spinneret is fed by the Qnap server itself via USB shared with the propplug. So the develpement can be done completely remote. The main feature is the connection of Pin 26 and 27 to the native UART on the Mainboard of the QNAP. (you can find details in the links on my blog entry). Normally that UART is not meant to be used by the customer, so One need to open up the Case to get Debian running and anytime net access fails for whatever reason. Having an out-of-band management available is a real nice to have.
A few words about the remote programming: As there are very few tools available to get things onto the propeller for an ARM enviroment and pyloader failed for some reason, I was on the hunt for some comfy solution. Netcat or socat came in mind to tunnel the serial communication over the net, which works fine for "normal" data, but it turned out the timing needed by the loaders (bst, propellent, you name it) is much to harsh for my trusty "*cats" so I found usbip to be quite a sharp sword for that situation. It basically takes the Propplug (FTDI) from the USB Stack of the Server (QNAP) and let it pop up on the client side (my Laptop) which shows the FTDI Device right in dmesg so I had a locally available /dev/ttyUSB0 to work with. Made me quite happy. I had some fear to get things together on the software side but after I decided to give propforth a try it really was just a walkt hrough the tests (now tutorial) and giving the thing a serial cog and some (ioconn) and ... done. Actually I was even a bit frustrated to see my plans of a week full of propeller coding gone in just an evening of propforth.
At first some Soldering:
Then heavy testing:
Differential signals are a perfect opportunity to max out the Rigol. Ch 1: TX Ch 2: RX Ch 3: RS484- A Ch 4: RS485+ B Math: A-B Decode1: TX+RX
Luckily my initial Problems tuned out to be soft ones.
For now my new Version is much more usable.
Jeah right, Linux need at least a 32bit architecture that's why you are out of Luck for the Atmel ATmegas. That is unless you emulate a full blown 32bit ARM. And, hey 6.5 kips has something soothing to it. Suddenly my trusty old G1 feels a bit faster. Thank you Dmitry.
Found via: Hack a day
Here is the Spinnneret loaded with propforth, attached (or merely duck taped) to my debianized TS-109 Pro II, the three wires are going to the back of the Qnap right to the UART. With the Setup as is, I can telnet to port 23 and get a trusty:
PropForth v4.6 2011JUL25 7:10 4
Debian GNU/Linux 6.0 castle ttyS0
castle login:
Mein Spinneret hat mich nach etwas Bangen wegen des befürchteten Zollaufenthalts dann doch heil erreicht.
