I'm not quite a newbie in terms of working with uC's... I've written software for a few. But I am in terms of the hardware they involve; lets just say I only just scraped through my electronics subjects at Uni.
My uC and circuit requirements are thus; 16-bit or better, at about 4MHz. Approx 100k address range. Small chip count, to keep PCB size minimal. On-chip serial driving and input capture would be a bonus. Long-range indirect jumps (> 64k) would be very useful.
So first off, I'm wondering what kind of speed I can realistically expect out of a breadboard circuit. How about one built using wire wrap? Construction of a decent quality PCB is a bit out of my means at present. And from what I've seen, so is purchasing a suitable eval kit.
Also, I've noticed that most 32-bit chips are built for high speeds, and have minimum speeds they'll work at. I only need about 4 MHz, if that. But I want something at least 16-bit (preferably 32), with at least
100k addressing range. Most 16-bit processors I've seen stop at 64k, and those that don't, seem to use freaky MMU's to make part of that 64k space a window into a larger address space. Are there 16-bit processors with
20+ bit native address space?
I'm also looking to use the fewest components I can, to keep the PCB size to a minimum (when I finally get around to putting it to PCB). So easy RAM interfacing, and serial ports on chip would be a major benefit.
Alternatively the MC68000, if I recall, was a 32-bit core with a 16-bit bus. Perhaps a uC derivative or similar unit might fit the bill?
I'd like some kind of simple bus with a 20-30 meter range, 50 would be nice. I've thought about RS232 and similar (I've read about a more robust variant, but I forget what it's called), however I'm not sure how to go about arbitrating it, or if it's possible to handle more than two devices. If needs be I could simply place three ports on each device and have them perform message routing, but that will probably introduce some nasty communications lag (I need to keep round-trip times as brief as possible). Plus I'd rather avoid dragging the whole network to a halt when I decide to transfer 30-odd kilobytes of code from the base to a node.
This is all for a modular controller I want to build. I haven't decided how to hook up the physical modules, or how to perform auto-detection and module addressing with a minimal number of components on the module board. Perhaps a small FPGA or something on each would do the trick.
On that note, I'd no idea how to go about dealing with a PLA, FPGA or similar component. I rather expect I'm in for a shock if I think I'll be able to get anything like that happening on the cheap.
and have a look at the M16C series of microprocessors.
--> M16C62A
Very affordable eval boards and tools are available.
Breadboarding is easy and if you want to "grow your own" the chips do not need much peripheral circuitry. (A crystal and two capacitors (or a ceramic resonator), a MAX232 is all you need to get a minimal system up and running.
They can be debugged with a ROM monitor that also allows to debug from internal flash, so all you need is one of the three UARTs to communicate with the monitor debugger.
RS485. just one 8 pin tiny SMD part and a few resistors.
No need for that. Some free chip selects for the external memory bus are available.
regards /jan
Fredderic schrieb in im Newsbeitrag: snipped-for-privacy@sumirpi.isbackwards_at.com.au...
For 32-bit, there is the ARM architecture. Implementations are found all over the place (Atmel and Intel are the only two I can think of now - pre coffee). There are indeed uC versions of the 68000 like the 68332 (don't know if it's still made) and the 68348 Dragonball. Zilog also makes a 24-bit Z80, the eZ80. They used to make a 32-bit Z380, but I don't think it sold well. There's also the Super-H series from Renesas (a merging of HItachi and Mitsubishi's semiconductors). Seems to me that Intel also made uC versions of their 386 (386ex?). Not sure if they still do. Check out their websites.
As for communications, there are several serial protocols. There is the 9-bit serial where the extra bit is used to signal whether the other 8 bits contain address or data. All nodes read the address to see if the host is talking to them. If so, they listen for the data, if not they ignore the data. Two other serial standards are I2C and SPI. And of course, there's that new fangled Ethernet stuff. :-)
I'd suggest getting "Designing Embedded Hardware" from O'Reilly if you're a hardware newbie.
The ATmega128 should do the trick. Single chip. Although 8 bit, it has plenty of registers and if you run at 8 MHz, you should get equivalent performance or better than a 16 bit at 4 MHz.
128 kB In system programmable Flash + 4kB SRAM + 4 kB EEPROM AVR architecture supports 8 MB Linear address space. EIJMP, EICALL.
2 UARTs and a number of timers w Input capture.
You can probably find plenty of inepxpensive boards out there. Free compiler/tools on
formatting link
--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.
No, it does not. It uses bank switching (he does not want that) and has no interrupt level system, which is really crappy for more complex applications.
*nods* Bank switching is certainly something I want to stay away from, I'm almost certain I'd find myself with an ISR sitting on a different bank to the currently executing code, and being modular in both code and hardware, I won't be able to fiddle things around to avoid it. Having to switch banks a couple times in an ISR called a hundred times a second isn't something I look forwards to. (In one of my more static projects on an MC68HC11 or whatever it was, I was even been able to avoid relative jump restrictions by rolling together a smart assember that rearranged the code based on XREF counts and a few hints -- special comments) Plus it'll force me to either choose a bank sizing which will suit everything (a fairly impossible task since I don't know everything it'll need to run), or allow each module to set its own banking (which would prove, I suspect, to be a clumsy resource consuming task).
I could probably cram things in a little tighter, but leaving a little extra room to maneuver will give me a generally much more reliable system.
Most of the peripheral requirements will be handled by daughter boards. A few ADC channels, a couple input capture channels, and the likes, might be useful if I can figure out a clean way to get them to the required daughter board. I was thinking a physically shifted bus might work, but relying on on-chip features will impose odd limits on what modules can be attached. On the other hand, it shouldn't be too hard to make a daughter board with an ADC, or a counter/latch pair driven off the main board's clock.
Because I'm going to find myself doing a lot of jumps via lookup tables, why else? I've got a lot of programming experience, but in the past projects I've always either had to conform to existing hardware, or had someone else to design hardware which can handle my minimal specifications.
Ballpark figure...? I chose 4Mhz as an estimate of what I'd need, as well as being nice and safe even during prototyping. Though if it will reliably run faster, then that's probably what I'll do.
Out of perverse curiosity, what can I expect the top speed difference between breadboard and wire wrapping to be? I'm expecting wires shoved into holes on a breadboard to have issues that would severely cap the top speed attainable -- especially in uC memory connections.
I wouldn't say the "wrong place", rather more of an "odd place". I wanted to avoid steering the answers people might give. If absolutely necessary, I'll fall back to using a 6812 or similar which I'm familiar with, though it would mean dropping some of the idiot-proofing features I wanted to implement.
I'm pretty sure I mentioned that. Usually short messages, 8 bytes or less. But during an update, several kilobytes will need to be transferred. Likewise most of the time speed isn't an issue. Except I would like to allow some kind of "high priority" message facility, and keep round trip time at least short enough that the user wouldn't generally notice the delay between operating the uC device (ie. pressing a button), and the device performing some action after asking the main controller for permission (1/5th of a second would probably be fair).
I can't say I'm familiar with that one... I've heard of a few of the common bus architectures, though I'm not really familiar with any of them.
I'm thinking Ethernet is a bit of overkill... Though I haven't seen a 1-chip Ethernet device, so I don't know how difficult it would be to use... But Ethernet cabling is also a little excessive, isn't it? I intend to have 6 or 7 of these little things spanning the house, with various modules attached, all linked together.
You're almost right. I haven't decided on a particular chip, but I do know what I'll need in general terms. I doubt I'd require an FPGA, but a PLA or two might come in handy for the add-on bits to the main uC unit. If I can find out how to go about it.
I'm trying to make a fairly general-purpose controlly do-dad, with a large home-automation thread, but a few side tasks that don't suit any HA system I've encountered yet. For example, instead of a central controller, a rules compiler on a PC will divide up the configured event triggers and responses and distribute them across the nodes so each node plays its part basically independently of the others. It'll know what information it has to pass on to which nodes, and what nodes to expect information from, but will otherwise mind its own business.
Essentially, you take one node (with uC), and slap on a selection of modules. Each module will be connected to the uC via a small bus (card select, 8-bit data, and misc signals inc. "attention"), and should be able to identify itself (a PLA will be useful here, unless I go with the per-module EEPROM option mentioned below).
Then, if you've got a network route to a PC with the over-view software available, it'll go and fetch the code modules required to suit the hardware modules attached. I'd also like to support a more standalone functioning, whereby a PC is unnecessary; my current intention is to implement a special module carrying an EEPROM with the available module codes, which it will distribute across the network as needed. Or, perhaps, if it looks practical, extend the address and data buses through the modules so each one can carry it's own EEPROM as standard.
From a software point of view, I pretty much know what I'll need. It's the hardware I'm having the most trouble with. I'm aiming to pin down the minimum requirements as stated, then consider larger options that are practical without making the development state unwieldy, but will still grant me the scope I'm looking for. Plus I figure that the slower it runs, the more reliably it'll run; so I'll probably provide a "turbo" setting, switched in by having any module that needs more than the usual grunt indicate this fact. Most of the units however, won't need more than
100k and a couple MHz (though I'm almost certain I'll need to break the
64k barrier quite soon).
Do they come in standard DIP packaging? As I want the nodes to be able to do a little more than just turn things on and off, the extra processing power might well come in handy; for instance, I'd like to eventually re-implement most of the PC software onto a module that carries a small LCD and keypad. That module should be able, for instance, to allow the operator to modify the current rules set (edit, compile, redistribute). Also, instead of the PC having to talk to the hardware in its language, with drivers and interface applications, I'd like to provide a serial link and text interface so it doesn't matter what kind of computer you have (as an avid Linux user, I'm very sensitive to Winblows-only hardware). All that is way down the track, but getting hardware in place which will support it is my goal right now.
Now this is interesting. A 24-bit address bus would do me just fine, at least up until they start putting out 128-bit uC's, running at
10THz, with high-tech optical breadboards that can handle it. Should be a few years away yet. ;)
On a personal level, I would like to stay away from PC-derived and 8-bit processors, unless one falls into my lap that's especially suitable. As well as being a practical exercise in home automation (with some unusual twists on implementation), I intend to use it as a spring-board on which to stretch my skills just about as far as they'll go. I'm not on a development schedule, I don't even intend to be finished by the time Windows 2003 is actually released, though I will probably aim to sell cheap kits to anyone still interested in the face of commercial alternatives. But mostly I want to expand my uC experience, and maybe even be able to dock my palm in any room of the house. Oh, and I can almost guarantee there'll end up being at least one of the little (I hope) buggers in the car (short-range packet-radio network, perhaps). ;)
IMO your way too far ahead of yourself, start simple. There is no way your going know all the hardware requirements before hand. 100k of code is heaps, I doubt you would use a quarter of that. 4 MHz, 16 bits - forget that, use a higher speed 8 bit. With comms try RS422 serial between the boards or CAN. DIP switches to set board addresses, etc. Also for PC interface, you'll have to implement a console, and for comms some kind of robust protocol (CAN will be good for this) ... Its a very complicated project your attempting, and it won't be easy!
Correct me if i'm wrong, but i believe the bank-switching only has to be done for data RAM. AVRs use a Harvard architecture, and the software is all programmed in the internal (self-programmable, if it is needed) Flash. Even then, 64 KB are addressable per bank. I don't know what kind of home automation you think you'll need, but do you really need more than banks of 64 KB for data?
There are two things that would worry me about the AVR:
Only one interrupt priority
The Flash is internal - once you've gone through its maximum number of r/w cycles, the whole chip is good for the garbage bin. Now, the maximal number of writes is pretty high, so i wouldn't be /too/ worried, except that you might not want to have to redesign everything in 10 years if AVRs aren't produced anymore. Still, a Forth interpreter (read the programs from RAM) can be made for AVRs, and used for more dynamic (and less speed-sensitive) parts.
A strange one. ;) The interface module I've got planned for a little ways down the track will be the main code hog culprit. And I've got to make sure chunks of code can be upgraded on-the-fly, without missing a beat.
Each node will be designed to operate independently, or in a network. I've also got a couple distribution-related side projects for which I'd like to use the extra processor time. In that regard, code banking could probably help to add a layer of security, but I don't much like the clunkyness it would introduce.
One of the modules in particular would be considered "realtime", and will demand quite a lot of attention from the CPU. Especially if there's more than one of them on that node (n+1 interrupts, 100 times a second, unless I can figure out a better way -- as it is I'm going to have quite a bit of fun dealing with cases where two interrupts fall excessively close together). Prioritized interrupts would be of great benefit. I'm planning to keep the number of modules on a node to no more than 8, so they can be addressed by physical bit-shifting in the bus. 900 interrupts a second may not be all that many, but I don't want them stepping on each others feet, and it still needs room for network data flow, etc.
Anyhow, so the code is strictly limited to 64k, while the paging system allows the data to range over however much space is needed? That may well fit... I was going on the assumption that the 64k window would have to be divided between code and data. It's paging code sections that I'm particularly dubious about. A true split code/data system is something I haven't had much opportunity to play with yet, so I'm a little unfamiliar with the details there.
From a software side, most of this little project is already mapped out. I'd planned to start it in my final year of university. Hardware and basic modules. Then if I was lucky, expand on it into a few deeper issues.
Updates shouldn't be that often anyhow... Only when modules are changed, or code updates injected. And I don't really expect it to still be around in 10 years anyhow... Someone's got to test the next model! ;)
Right now I'm thinking of looking very hard at 32-bit uC's... See if any of them can be used fairly easily, and at relatively low speeds. Or perhaps that 24-bit Z80... The version I produce for other people will spend 90% of its time idling, and probably will fit quiet nicely into 64k. But the initial version, with excess debugging features, and a host of optional extras I'm planning on implementing... I'm rather dubious about it all fitting into such a tight space.
I am starting simple. I just want room to grow, without having to redesign the darned thing later down the track.
To be honest, I hate electronics. The digital side of it is fun, logic, and all that. But electrical issues give me the irrits. So I'm going a little over-spec.
I confess I had forgotten that the AVR is a Harvard...
I intend to. But in the early stages the extra speed won't be needed. And until I start playing around with some of my side projects, most of the nodes I put together won't need even that much speed. Likewise with the 16-bit issue. An 8-bit processor with a lot of registers may be an acceptable compromise. But most 8-bit's I've encountered aren't designed that way, and more registers means more time jumping in and out of interrupts. So a 16-bit with a normal compliment of registers, should do just fine. Besides which, I've used 8-bits before. Half of the reason for doing this in the first place, is to use something just a little bit bigger. I've done a fair bit on various 68xx models, and a little here and there with some of the other 8-bits. I don't really want to go all the way up to a 32-bit, but I would like to get off the 8-bit ledge. Besides, manipulating 32-bit numbers in an 8-bit processor is just plain tedious! At least at 16-bit, it's remotely bearable.
I was hoping to avoid having to DIP the address... But lacking a better idea between now and then, that's pretty much what I had in mind.
Easy? What's the fun in that? I'm out of practice, and I need something to seriously shake me up. The hardest part for me, is going to be the hardware. The code side of it will just flow from there. My final year University project was a robot comparable to those in the Micro Mouse competition (in fact, it had to conform to those very same rules). Of the four of us doing the project, one only showed up twice, one did nothing most of the time, and then offered us a load of crap. The other guy had stuff all programming skills, and spent his time building the hardware for the sensory system. That left me to write the software, of which our mouse ended up being the second most advanced that year. The only reason it wasn't right on par with the other, is because I spent two months out of action at a fairly critical point in the project (and spent too much time helping said team instead of doing my own work). I was also team leader by fact of being the only one with a good idea of all aspects of the project from hardware to interfacing to software. Now, in that case we were given a basic sensor less board and chassis to work from. This time I'm doing the whole lot myself. I have the skills, the ideas, and being on a pension, I have the time. I've also been thinking about the software and modules I'd like to implement on it for quite some time. What I don't have, is much money, equipment, or a processor to build it around. So I'm going to try and aim high, and if I fall back to a lesser level, I'll just put some of the more grandiose plans on hold for the time being. But either way, I'm going to pick the brains of people in this group to explore the possibilities first. :)
If you use an ATmega128 based board, you could instead store the node address in the on-board EEPROM. You have a 1-time configuration where you set the node address before you connect it to your net. Use the second serial port for that - just hook up to your PC serial port, config the node's address and any other parameters, store to EEPROM.
Just a thought ... it was save using up I/O pins for something so mundane as DIP switches.
Cheers,
-Brian
-- Brian Dean, snipped-for-privacy@bdmicro.com BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
ARM7TDMI Family 1.8V High Speed Low-Power Flash 60MHz operation,=20 zero wait-state Flash, on-chip Real-Time Monitor and Trace=20
formatting link
up to 256K bytes of embedded Flash memory, 10-bit A/D converters, 16K = of SRAM, pulse width=20 modulation (PWM) timers, UARTS, serial peripheral interface (SPI) and up = to=20
46 General-Purpose Input/Outputs in a small outline 64-pin package.=20
For a 16 bit micro look at the TI msp430 series. (developed from the pdp11's)
formatting link
Even though you say you need 16 bit, I'm sure you could easily do what = you need with an 8 bitter. Have a look at either
cygnal up to 100 mips 8051 with up to 1Mbit adc, some with usb
formatting link
formatting link
formatting link
formatting link
formatting link
or dallas maxim especially 80c400 and or their tini boards
formatting link
formatting link
For 8 or 16 bit advantage of msp430 or avrs is a gcc port.
Most 32 bit micros have a gcc port.
May also be worth your while having a look at some of the dsp's as well. One of the dsp/micro hybrids may also suit your application.
formatting link
formatting link
Have a look at news:comp.dsp
Had a few people rave about
formatting link
isopod but haven't came across hardly anyone using them.
Not exactly. The code is limited to 128 KB(64k x 16, while RAM is addressed in bytes), but the data address range limits external RAM to ~60 KB (and external RAM access is 2x slower than internal) + 4 KB internal, so you must use banks for more. Harvard means no cute self-modifying code (hehe), but the 128 can still program itself - you'll have to make sure it fits your needs, though, since i think the update code must be restricted to a certain address range.
For your networking, have you taken a look at standards? For example, RS-422/423/485 (all with ranges up to 4000 ft and multiple receivers)? That'd let you take advantage of the built-in USARTs and save some interrupts.
Has some possibilities... DIP's aren't really a problem, I already need to do some funky address decoding anyhow... Just another line driver chip sitting on the bus...
But it does raise the possibility of some other ideas I hadn't considered... Wonder if I could "name" a node, and let the network figure itself out?
What if you run a simple 8-bit checksum over the "name" and use the result as the network address? You'd still need to store the name is EEPROM or some time of persistant memory.
-Brian
-- Brian Dean, snipped-for-privacy@bdmicro.com BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
In small quantities the price difference is not so big. There are lot of ARM-based controllers and processors somewhere near $10. The main problem is to find a reseller for small quantities, but you have time, haven't you ;-)
If you don't like the thought of big SMD-packages, you could take some
68k. It has 32-bit registers, but only 16-bit databus.
Clock frequency is usually not a problem. Devices intended for embedded applications tend to have a static design, i.e. you can clock it as slow as you want.
BTW: It would be easier to help, if you could give some numbers, like maximum price for development tools and max. price per unit.
Trust me, you will encounter enough problems, even if you take the easy route ;-)
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.