Suitable controller

Take a look at my MAVRIC board:

MAVRIC has 8 on-board, but I'm pretty sure you can expand that with I2C based A/D converter chips if necessary.

Up to 53 programmable I/O lines.

6 PWMs which can easily be configured for servo out.

The I/O lines can be configured as input or output and you have up to 53 available.

No analog out, but 3 of the PWMs can be configured to generate an analog signal with the addition of a few discrete components. I've been told that digital to analog is a rather difficult to mix onto the die with typical microcontrollers which may explain why you don't see this too often. Many make up for that by the creative use of a PWM channel.

Hardware support for I2C - no bit banging required. This is a great way to add peripheral expansion, just hook up to the I2C bus. I use my SRF08 ultrasonic ranger and CMPS03 compass module this way, couldn't be simpler.

Just use some of the available I/O lines for this - there are plenty of libraries available around the 'net so you don't have to write your own control routines if you don't wish.

On-board regulator, accepts 7 - 15V input, with reverse voltage protection.

The MAVRIC board size is 3.0 x 3.6 inches.

In addition to those mentioned above, other features include 128K of program memory (FLASH), 128K of external static RAM (64K is easily addressible by the ATmega128, the other 64K is available by bank switching), dual level shifted UARTs, SPI communications interface, on-board I2C serial Real Time Clock with battery backup (Dallas DS1307), on-board 32K I2C serial EEPROM, on-board LED, DIP switches to engage various features, optional screw terminals for easy hook-up, ISP (in-system programming) header for easy programming, and JTAG debugging header, just to mention a few.

Note that 16 of the general purpose I/O lines are consumed by the external static RAM for the data and address bus, so if you use the external RAM (you can disable it via the DIP switch), that will leave you with 37 I/O lines. If your application doesn't need the additional RAM and the 4K on-board the MCU is sufficient, you can disable the external RAM and use the 16 lines for general digital I/O. Also worth noting is that the various chip peripherals like the 6 PWMs are shared with general purpose I/O, so if you use all 6 PWM channels, you lose 6 I/O lines. But even with all you need to do, it still sounds like you'll have plenty to spare.

I offer my boards as a bare PCB, Kit, or fully assembled and tested, priced accordingly. So,if you are comfortable with surface mount soldering, you can save some bucks and get the kit and build it yourself. Alternatively, if your parts cabinet is well stocked, you can just get the bare board and order the few remaining parts you need and save some money that way too.

Are you competing in a robot competition? I know of at least one of the teams of the FIRST robotics competition held earlier this year who used my M128B board, which has similar features as the MAVRIC (MAVRIC was not available at the time). My contact with the team spoke very highly of its capabilities. They even won the coveted "Controls" award, due in part to my board they tell me. They even sent me a team T-shirt :-), which I am very proud of.

Best of luck with your search and with your robot!

Cheers,

-Brian

Neat product, nice docs.

How many bits is the A/D 8,10,12 ?

Thanks.

The A/D is 10 bits. 7 channels are differential channels and a really cool feature is that 2 of the channels have programmable gain settable to

1x, 10x, or 200x. This is very nice for sampling a low level signal and can save you from having to add an amplifier to your circuit, for example.

Cheers,

-Brian

The A/D on my MAVRIC board is the standard A/D available on the Atmel ATmega128, no extra chips. The AVR line up is impressive - from their smallest to the largest, the architecture is the (by and large) the same, sans a few instructions here and there. The various chips differ primarily in how many I/O pins they have, which chip peripherals are on-board, and how much FLASH, RAM, and EEPROM is on-board. FLASH generally ranges from 1024 or 2048 bytes from the smallest up through 128K to the largest. RAM ranges anywhere from 128 bytes to 4K on board, though I think they had a few early chips that had no internal SRAM (only the 32 general purpose registers). Their chips range from 8-pin DIP and on up, so they really cover a large space.

Almost all of their recent chips also have an on-board RC oscillator most of which can clock at up to 8 MHz (accurate enough for RS232, but not highly stable with temperature) so you can design solutions with zero external parts in many cases.

Here's the datasheet on the ATmega128 - it's long, but does a good job of describing the features:

Here's Atmel's parametric table of all their parts that summarize the major differences among their AVR series:

Note that in all their documentation, TWI (two wire interface) is Atmel's designation for what is commonly referred to as I2C.

I made the switch from 68HC11's about 5 years ago and haven't looked back. Lots of decent tools are available, too. Check out

which has a tools page with dev boards, compilers, RTOSs, not to mention design notes, and other goodies.

Cheers,

-Brian

I had to switch to embedded microprocessors, and then got back into the microcontroller game with the IsoPod. I have been meaning to get into the AVR's, but my discovery frontage is directed to CANBUS.

Mike

That's a pretty powerful endorsement, 'cause the HC11 is venerable, to say the least, in the 8-bit world.

So how do the two, HC11 vs. AVR, compare MIPs wise? What was most attractive to you to do the switch? I assume it would be the Flash, which was the thing most missing in the HC11 line for me, but I'd like to hear your take on it. Do you ever burn the AVR's out in development from the re-Flashing limit? what is it at 1000 cycles?

The AVRs are basically 1 instruction per clock cycle machines so if you run at 16 MHz you get about 16 MIPS. However, with AVR parts that have optional external memory like the ATmega128, one additional clock cycle is required for instructions that access the external memory due to the multiplexing of the address and data bus. I'm not sure about the HC11's. I remember writing a 6811 assembler many years ago and recall each instruction taking anywhere from 1 to around 6 clock cycles (going from memory).

Personally, I just find the AVR's easier to use. I think mostly it is the near zero external component requirements of the AVRs, so you are correct, FLASH, and RAM on-board. But also, the large register set of 32 general purpose registers makes it very nice as well. And with the wide selection available, it's so easy to reach into the parts drawer and select a right-sized AVR for the job without too much overkill. I guess that's the appeal of Microchip PICs as well.

I never jumped on the PIC bandwagon primarily because at the time Microchip had no programming software for Unix for their PICstart programmer. And even after multiple requests, they refused to release any information about its protocol so that I could write software for it to support my own environment. Atmel didn't have any programming software for Unix either, but the AVR programming protocol was very simple and I implemented my own (AVRDUDE - which is now open source):

I never have, but I'm sure it happens. I think most recent AVRs indicate

10,000 cycles, at least that is what the ATmega128 data sheet says about it.

The main thing I don't like about the AVRs is the harvard architecture - seperate program and data memories, but this hasn't caused me any real pain - just makes some things slightly more clumsy than they need to be.

Cheers,

-Brian

So RISC like, one cycle one instruction for internal Flash. How are the instructions? PIC like or more CISC like? Are they meaningful? or does it take a handful to get anything done. (Still trying to get a feel relative to HC11.)

HC11's run 8MHz clock for 2MHz internal. Most short instructions are 2 cycles, some 3, and some complex instructions 5,6 and up from there. So basically, HC11 pushes close to 1Mip. But it's a good instruction set with strong addressing modes. Not the best, certainly, but as I said earlier - venerable. Then there are 3 and 4 MHz versions, so you can get above a MIP with them.

How large are the registers? 8? 16?

Yeah. We were all set to get excited about the HC12's when they came out with Flash, until we found out they were 100 cycle Flash. I just didn't think I could in good conscience sell boards to my customers which would burn out in 100 development cycles. We did have some go out around 100 cycles. So we didn't advertize them. We got excited about the 68F333 which was supposed to be 10,000x flash. If you haven't heard of it, don't worry. We made several boards chasing Mot's changing pin outs, until they discontinued it, just as we were getting ready to go to market.Drat!

So that was another false start. So when the 56F80x DSP's came out with

100,000x Flash, 40MIPs to boot, we were very happy to get back into the game with IsoPod(TM) and ServoPod(TM). Not to likely to were the Flash out from the development cycle.

It seems to be a very nice, orthoganol instruction set with all the usual add, sub, mul, and, or, eor, net, inc, dec, (no div) etc instructions with variations for signed/unsigned, w & w/o carry etc. Operands can be two registers or a register and an immediate. All operations are 8 bit. Data movement is by load/store with all the usual addressing modes in combination with pre and post decrement/increment, but with the large register set, moving data in and out of memory is not as common as on other architectures with fewer registers. 6 of the registers are special and work together as 3 pairs of 2 and are used as pointers for indirect addressing (the X, Y, and Z registers which are r26:r27, r28:r29, and r30:r31).

All the usual test and branch instructions are present as well as bit test and set insructions.

At Atmel seminars, the presenters say that the instruction set was designed in consultation with various C compiler vendors for the purpose of making sure that the instruction set would efficiently map to high level language code generation. As a result, a good C compiler can really produce very efficient code for the AVR.

8

Ugh. Well, some folks aren't too happy with Atmel's short product lifespans to date. I get the feeling that Atmel spread themselves a little thin by having such a wide variety of parts. At the last seminar ealier this summer, the presenter indicated that they are going through the process of shrinking their offering down to a few more capable parts in each category instead of all the little variations. On the up side, I believe that for parts that have been obsoleted, their intended replacement has been pin compatible.

However, they are coming out with some neat new products in the near future. An ATmega256 is planned which is a 100 pin part with double the FLASH and is slated to have 16 PWM channels, 16 A/D converters, more timers, more everything. If it comes out in the form they've said, it should be quite impressive. They are also adding CAN to their peripheral set and USB even I think, so that should be good news as well.

Yes, your 'Pod(s) seem to be quite impressive. At 40 MIPS, they should be able to really hum along. Nice feature set on them, too.

Cheers,

-Brian

Its one of the easiest to use from the all different manufacturers.

I find TI's a real pos, but at least they have the information there = unlike lots of other manufacturers.

The other main source of AVR info is

have to register(free).