Which uC and other great newbie questions?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.


All suggestions welcome.  :)

Fredderic

Re: Which uC and other great newbie questions?
Fredderic,
check out www.glyn.de and www.renesas.com 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.

Quoted text here. Click to load it

RS485. just one 8 pin tiny SMD part and a few resistors.

Quoted text here. Click to load it

No need for that. Some free chip selects for the external memory bus are
available.

regards
/jan


Newsbeitrag:
snipped-for-privacy@sumirpi.is_backwards_at.com.au...
Quoted text here. Click to load it



Re: Which uC and other great newbie questions?
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.



Re: Which uC and other great newbie questions?
In article < snipped-for-privacy@sumirpi.is_backwards_at.com.a
Quoted text here. Click to load it

Why?  There might be more suitable 8 bit systems at 12Mhz.


Quoted text here. Click to load it
Why?

Quoted text here. Click to load it

OK... but what peripherals do you need?


Quoted text here. Click to load it

Why?


Quoted text here. Click to load it
More than 4Mhz


Quoted text here. Click to load it

The answer is that you are starting in the wrong place.... what are you
trying to develop?

Quoted text here. Click to load it

What do you need in the way of data transfer? What sort of environment?

Quoted text here. Click to load it

You could use CAN bus?  There are many parts with this built in.

Quoted text here. Click to load it

!!!! Use CAN. Or possibly ethernet? There are parts with that on them.


Quoted text here. Click to load it

It sounds like you have made your disision without giving any idea of
the application. It's back to front.

What are you trying to make?  How much data to how many nodes....

THEN decide on the processor, and if you need long jumps and the address
range.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

Because.



Because.  Call it a conservative guestimate.

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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).


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load 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.


Quoted text here. Click to load it

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).



On Tue, 14 Oct 2003 19:58:41 +0000, Gary Kato wrote:

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.  ;)


Quoted text here. Click to load it

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).  ;)


Fredderic

Re: Which uC and other great newbie questions?
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!

ross



Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

I confess I had forgotten that the AVR is a Harvard...


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.  :)


Fredderic

Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

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?

Fredderic

Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

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.  ;)


Fredderic

Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

What's wrong with 32-bits?

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.
 
Quoted text here. Click to load it

Trust me, you will encounter enough problems, even if you take the
easy route ;-)

/Jan-Hinnerk


Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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?


Quoted text here. Click to load it

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...  ;)


Quoted text here. Click to load it

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).  ;)


Fredderic

Re: Which uC and other great newbie questions?
Quoted text here. Click to load it

I wouldn't pick 68k for a new project. The core is being abandoned in favor
of ARM - by everyone, including Motorola.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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?



Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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 ;) ).


Quoted text here. Click to load it

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.  ;)


Fredderic

Re: Which uC and other great newbie questions?
Quoted text here. Click to load it


 If you are sure you need > 100K, then look for devices with
comfortably more than 100K of on-chip FLASH.


 Philips LPC21xx family - just added 64 pins + ADC/PWM members to the 48
pin
ones already out. Has 256KF, and up to 64KB RAM.

 Zilog eZ80F9x family. Again 256KF,

 STm uPSD33xx - 8 bit/40MHz, but >256KF, ADC, and on chip debug.

 If you want Ethernet, Zilog offer an eZ80F with MAC on chip.

-jg

Re: Which uC and other great newbie questions?
Quoted text here. Click to load it
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 www.avrfreaks.net

Quoted text here. Click to load it



--
Best Regards
Ulf at atmel dot com
We've slightly trimmed the long signature. Click to see the full one.
Re: Which uC and other great newbie questions?
On Wed, 15 Oct 2003 11:03:30 +0200, "Ulf Samuelsson"


Quoted text here. Click to load it


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.


Re: Which uC and other great newbie questions?

Quoted text here. Click to load it

*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).


Fredderic

Re: Which uC and other great newbie questions?
Quoted text here. Click to load it
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:
1. Only one interrupt priority
2. 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.

Site Timeline