Cross Platform Development

On Thu, 23 Apr 2015 21:06:38 +0200

Is it not easier just to check the router status for connected devices?

Configure the router to assign the same address per MAC with a quick copy and paste from the LAN connection status to the DHCP settings (although it may still get clobbered by a manually configured device).

ITYM network 192.168.0.0 broadcast 192.168.0.255 or address 192.168.1.14 gateway 192.168.1.1 :-)

or just leave out the network and broadcast lines completely. They aren't needed any more as the network software calculates them from the address and netmask lines if they aren't specified. :)

Yes of course. I got a 192.168.1.0 network at home, bit most routers use 192.168.0.0 In my efforts to adapt it to the more common network mask, I missed half of the lines... But I got half of them right :-)

if you are going to change your routers address map I would personally suggest it would be better to choose a less common address range rather than the common one(s)

alister wrote on Friday 24 Apr 2015 10:57:

map I would personally

common address range

Why?

In my case I have a vpn setup to enable me to connect to my home network if I had the same address range as my friend it could result in address clashes making it difficult for me to access my server & his shared data storage & the same time.

alister wrote on Friday 24 Apr 2015 14:50:

Fairy Nuff :) You have to admit that that's rather a special case though...

You can NAT the VPN to avoid local address clashes:

It makes things less troublesome if/when you buy a new router and plug it in to your LAN to configure it, or connect to another LAN by VPN.

true, but hence my initial suggestion that you are going to change your rooter settings going different rather than the same as everyone else may be a better option, after all if you decide to add something like my setup (or even connect to someone else's VPN ) it may save a lot of unnecessary upheaval.

the is after all no need to be on the same private ip address range as everyone else.

there are various options & at the time there were other reasons that made a particular range beneficial to me

When reading your first post I wasn't thinking of running on the PC so I didn't follow this at all. It's all water over the damn, so no need to dwell on it.

Yeah, I have that all figured out now. I had to buy another Ethernet cable since I'm not at home and configured my friend's router to give the pi a fixed IP address. I got a remote command line from the pi on my PC and was able to run minicom (I messed up the name to miniterm before) and the launchpad is now talking to me.

I do have a problem where Mecrisp is sending LF only and the display keeps marching across the screen to the end of line where it just overwrites the last character. I can't find a setting to add CR on LF. There is one to add LF on CR, but that's not what I need. Do I need to find another terminal program?

Once I get past this, I might use Notepad++ with the plugin. Thanks for all your help. :)

Yes, thanks. I am familiar with this and have connected to the router (I forgot to bring an Ethernet cable, so I had to buy yet another one) and given the rPi a fixed IP address. I am to the point of running Putty on my PC and talking to the Mecrisp on the launchpad, but it only returns LF and I can't find a way to append the CR in minicom. Is that something the rPi terminal window can do maybe?

Good stuff.

The only thing I can thing of offhand it to pipe Mecrisp output through unix2dos, something like this:

mecrisp | unix2dos

This assumes that Mecrisp is accepting input via stdio and writing replies through stdout which may or may not be correct. The pipeline represented by the '|' symbol connecting Mecrisp's output channel to unix2dos's input channel. unix2dos does what you might expect and replaces each LF with a CRLF combination.

Try it and see. I don't know whether unix2dos works on a character by character basis, it which case it should be fine, or whether it only works a line at a time, in which case the output may be too jerky to use. It is really intended for file conversion, but seemed to work OK just now in a pipeline fed from a test file.

Of course, Forth being Forth, you could probably also modify whatever (lowish level) word is dealing with linefeeds so it outputs CRLF rather than LF.....

Mecrisp is not a Linux program. It is an app on the target launchpad board. So if I were to do this I would use

minicom | unix2dos

Might work, but someone pointed me to a terminal program that works correctly.

Sounds nice, but I would have to recompile... no re-crosscompile the Mecrisp sources which would be a whole 'nother level of ramping up for me.

Microcom is currently doing the job well and now I "just" need to learn how to use Mecrisp. Thanks for all your help.

Traditional Forths didn't have a compiled form: there was a built-in (reverse polish) assembler for the very lowest level words, but there are very few of those. The lowest level 100 words or so were assembler, so that was all you had to translate with if you ported it to another machine: everything else was interpreted. The idea was that the assembler was just bright enough to interpret the next layer, which extended the interpreter so it could deal with higher level words, so basically the thing rebuilt itself pretty much from scratch each time it was run: it was written recursively in a recursive language: it that doesn't make your head hurt, nothing will!

One result was that you could change almost anything in the implementation provided you knew what you were doing. Whenever you define a new Forth word it gets interpreted pretty much as you finish entering it.

However, I understand that modern implementations work differently and may even have a compiler and a compilation phase. But, its still IMO one of the ultimate write-only languages.

I believe you are confusing just what "interpreted" means in the context of Forth. Even if they "interpret" some portion of the system code, it is usually compiled into a binary file which is loaded when the system is run. I don't know of *any* forths which were compiled from some minimal assembler at load time rather than installation time.

I am not proficient at any software language at this time. I used to know C pretty well, but that is being pushed out by C++. Since I don't have much of a language bias I find most C code to be pretty much as write-only as Forth.

I find Forth to be extremely productive when interfacing to hardware which is *my* area of expertise. I produce boards and use Forth to program the test fixtures.

I just finished looking at e4thcom and can't seem to get it to run. I'm not sure what advantages it has over microcom, but I wanted to take a look since it claims to specifically support several embedded Forths such as Mecrisp. Here are the directions I followed...

Installing e4thcom

e4thcom is distributed as a tar.gz archive. For testing or as a user without admin rights unpack the archive in a directory of your choise, e.g. in your home directory or on the desktop. You will then find the e4thcom binary and related files in a new directory named e4thcom-xyz. The e4thcom binary in this directory is the one for X86 Linux Systems.

When installing e4thcom on a Raspberry Pi with Raspbian OS please copy the binary from the Raspbian subdirectory to the e4thcom directory.

As an admin you can make e4thcom available to all system users by unpacking the archive to the /opt directory, changing owner and group with chown -R root:root /opt/e4thcom-xyz and creating links named e4thcom and forthbox in /usr/local/bin to the coresponding files in the /opt/e4thcom-xyz directory.

sudo ln -s /opt/e4thcom-0.4.4/e4thcom e4thcom

sudo ln -s /opt/e4thcom-0.4.4/forthbox forthbox

When I type e4thcom at the rPi command line it says, "-bash: /usr/local/bin/e4thcom: cannot execute binary file". Not much idea of what I've done wrong.

I must respectfully disagree: I was messing about with a version of Forth that ran on a 6809 box under Flex09. I had all the source for this Forth and vividly remember that there was almost no compiled code in it - and that part of it was all assembler. This was code included the low level assembler words plus the jump into the initial word low-level word. Everything else was a file containing Forth source and was pulled in by the assembler words and prepared for use before it put up the initial user prompt. This set-up was traditional enough Forth to avoid the use of the FLEX filing system: all data and code 'screens' lived in a single random file containing numbered 1K chunks known as 'screens'. A 'screen' was 16 lines of 64 characters (1 kB). User written source code lived in this screenstore - it had do because the editor would only operate on one screen at a time and had no means of accessing normal Flex files.

I don't remember how the system code was stored but it could well have been another of these Forth random access screen file: it would be logical to do it that way.

Don't forget that Forth was developed to run on very low powered kit: IIRC something like a DEC PDP8 and much of it came out of the astronomy community.

I prefer ANSI C to C++, which I find hopelessly baroque and far too full of 'features'. Some support from this view comes from the point that any of the "C++" programs I've run into have been little more than ANSI C with added // comments and using cin and cout for I/O rather than C's stdio functions.

Given its background that isn't all that surprising: I believe the astronomers used it to control telescopes of various types.

There's a whole newsgroup over there (see xpost) for forth discussions!