Clash resolution could get messy... Unless I just make a point of keeping a name list and avoiding any names that conflict. Either way, it would give the nodes "human" names which will make referencing a node easier.
And since a single bus wound all around the house could get rather long, I'll have to do some message routing. I haven't quite decided on a network topography to use (relatively low priority at this stage)... I was thinking of breaking the network into groups of three or four nodes each, and putting two network ports onto each node (or even three or four
1-to-1 links). Especially if I can support cyclic networks (not hard to implement so long as you've got room to keep a list of every single node on the network). Might even get to play around with load spreading algorithms then. ;)
I had considered that... I used to play around in Assembler on an A1000 back when they were new. Based on a 68000, and was a dream to write for. I've heard differing tales about the availability of that range, though.
This is something I would really like. I'm aware that at least one of the
68k's is stated to be static, but the others apparently are not?
Hmmm..... Maximum price... I have 25 cents in my wallet! Quite seriously though, I'm in scrounge mode at the moment. Trying to build up a collection of bits and pieces I'll need, while I sift through the replies and suggestions. I'm not against doing it hard with a free tool, as long as it works; in fact, for one project I ended up writing my own re-sequencing assembler to avoid out-of-range branches -- only bummer is that the deadline for the project was going to arrive before I'd completed the assembler, so stuck with the existing tools and finished it off afterwards just for fun.
Come to think of it, a mixed-processor system could be entertaining. Maybe I'll try implementing a byte-code assembler. Distribute code to the nodes in byte-code form, and let them assemble it themselves. Put that one down for sometime in 2009... ;)
hehehe I know... It's mostly that I want to make as certain as possible that when I put this thing together, it'll be able to cope with what I want to use it for. I'd rather avoid having to go redesigning the thing a few months down the track, right after I've started building the other five. ;) Which is why I'd like a standard DIP package, so I can bread board it before I go anywhere near solder, or even wire-wrap.
One issue I'm going to run into, is how to get the initial software onto it. I was thinking some kind of debugging console with a "load" facility would do the trick, but that appears to mean either purchasing a uC with one already onboard, or buying a ROM with it pre-loaded. Do any of the
68k family have debugging/programming interfaces? Perhaps I could implement that...?
If I use a fully static uC which can handle long periods between clock pulses, I was even considering IPLing (I think that's the term... Incremental Program Loading). A couple of buffers, a full-duplex serial driver, and a pair of decimal counters, sitting where ROM should be. Each time the processor throws an address, it's clock source is halted while the address gets sent on down the serial link. Then when data is written back again and safely latched, the circuit resumes the clock source (as long as it's full duplex, you don't actually have to wait for the address to arrive, if you already know what it'll be). You compile the code you want to test, then convert it into a series of processor instructions which will place that code into memory (we used to do something similar on PC's draw small graphics, like cursors), followed by a jump to the start of the code. To improve speed a little, you can use the technique to IPL in a program loader, which then sucks a standard S-format file down the serial port, and optionally store it in the EEPROM or whatever if it has one. Insanely slow and not very good at error detection, but rather effective. And slightly easier than a hardware S-file loader (which I designed for fun a few years ago -- never actually built though). ;)
So how does code addressing work? Is it 20-bit, or paged?
The 4K internal ram would probably be used exclusively by the OS (for want of a better term). Could always just give each module its own 64k data page. ;)
I've been pointed at the RS-4xx group... Haven't had a chance to delve into them very far though... Still processing all the other suggestions.
4000ft is quite a distance... How do they cope with two or more trying to transmit at the same time? I'm guessing I'd have to set up some kind of arbitration.
I wouldn't pick 68k for a new project. The core is being abandoned in favor of ARM - by everyone, including Motorola.
This is why God gave us microcontrollers with inbuilt bootloader ROMs (e.g. Cirrus 7212, 7312), microcontrollers with on-chip JTAG interfaces for programming external flash (e.g. most ARM and PowerPC and MIPS microcontrollers), and microcontrollers with in-system programming pins for loading flash contents.
Are you thinking of what IBMers sometimes call RIPL, Remote Initial Program Load, where the system has a small bootstrap ROM that loads the main OS off a server on the LAN?
Okay then... That's a shame... Some of those 68k's had some very nice features.
Guess I'd better start looking for a cheap ARM eval kits.
Hmmm..... I haven't been close enough to anything other than a 6811-or-so to notice features like that. How the program got there, hasn't really been my concern until now. ;)
I've used JTAG programmed hardware, but never actually looked at it directly. Don't happen to have any good references on it, would you?
From what I've read, those JTAG interfaces aren't cheap. Though I think I recall reading something about someone trying to make one on the cheap... Something else to keep in mind (there's something to be said for never having to choose the actual uC hardware you're working on ;) ).
Ahhh..... Close. Forgot the 'R', and I wasn't intending to use a LAN, just a serial cable, and probably not built into the node hardware... I figure uC interfacing would probably be a little too fickle to successfully pull such an idea off in most cases, at least without being substantially more difficult than just about any other idea, but if it was workable it might prove to be an interesting solution to an annoying problem. Consideration of the workability of that idea was the main reason I put that notion forth. Of course, the debugging features you mention would make it rather redundant. ;)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.