microcontroller suggestions anyone?

Hi,

I would say smth like that:

Atmel ATmega128 + FTDI FT232BM chip which acts like a good old MAX232 for USB. This is certainly the quickest way to get the USB running, I suppose. There are many USB-ready uP nowadays, but I'm still afraid about their market 'persistence'.

ATmega is here to stay and FTDI too I hope.

For the ATmega you can also get C compiler for free (GCC) or almost-professional-one for mere 150$ (CodeVision).

This is of course very personal point of view, but I've just finished my project with ATmega and FTDI chip :-)

Take care,

Mark

And once you get you're design up and running and are ready to deal with Atmel on a serious basis you can expect to be pissed about, ignored and insulted on a regular basis.

Anyone from Atmel stupid enough to have me elaborate? I thought not. _____________________________________ Murray R.Van Luyn Revolutionary Urban Guerilla. Ph: +618 9354 1375 E-mail: snipped-for-privacy@ses.curtin.edu.au snipped-for-privacy@cs.curtin.edu.au

I'm not from atmel but I am using one of their controllers in a product I'm developing.

What sort of problems have you had? Has anybody else out there had similar problems?

Craig

These first two replies bring up another point:

You have both suggested a standalone microcontroller to be combined with a USB IC. Isn't it possible to get all this functionality on a single chip?

Which way is cheaper? Is the hardware design significantly more complex if I'm using the two chips instead of one?

Jim

Hi All,

You might want to check out the Cypress pSoc @

BTW, Cypress offers micros with both USB 1.1 and 2.0 support also.

Regards, Rob

Mehamerla,

In article , Xmehamerla@

Can you elaborate when you say the code is not well optimized? From what I saw of this compiler and options, it has pragmas for code size/speed optimizations plus several passes that I didn't see listed in other compilers (ImageCraft, GNU for sure, etc).

I'm considering purchasing this, so any other comments you have would be appreciated.

Thanks, TR.

have a look at

also ezi-usb which Rob mentioned

Alex

Sorry about that Craig. Hope I didn't put anyone off Atmel. I've made too broad a generalisation regarding the type of product support that they offer, and unfairly based this on my interactions with select group of 's*it-heads' whom they employ.

Regards, Murray. _____________________________________ Murray R.Van Luyn Revolutionary Urban Guerilla. Ph: +618 9354 1375 E-mail: snipped-for-privacy@ses.curtin.edu.au snipped-for-privacy@cs.curtin.edu.au

similar

That wouldn't be because of them EOLing product lines realitively soon after introducing them ?

Realtivly soon being a few years.

Or would that be issuses with some of the tools , ices etc they sell ? Not the ice40 ?

Alex

John napisal(a):

Hmm, I never use any optimisation. My projects are rather small and slow so I do not have to bother with optimized code. Many times had to find bugs in the output code and optimization does not help to find them.

I was analyzing CodeVision output code a few times. Once because of the error generated by CV. I have seen that CV puts many strange instructions making the code longer which make code harder to analyze. I did not count instrucion times and length but it seemed strange to me that CV many times used very short functions (AFAIR 2 instrucions) despite putting inlines. In opposition Keil (for 8051) output code is very clear and easy to analyze.

I think that it is worth its price. Compare it to the Keil price which is much higher. Besides you can check CV yourself - as I said it can be used for free with minor restrictions.

They tend to EOL products very soon after release (total life of the Mega163 was around 18 months).

We have been repeatedly promised that emulators we have bought will be upgradeable but when a new device becomes available or when a device is EOL'ed you have to get a new emulator. We've been caught for about

Their "free" tools (which you have to use with their emulators) are pretty crappy and are basically debugged by their users. Studio 3 finally became stable and usable at about V3.5, Studio 4 is still only at V4.07 and while an improvement is still not a particularly professional piece of software. I would happily have paid for a decent emulator front end.

Atmel are also prone to sending snotty e-mails to people who complain about this stuff in public.

I think the AVR is a great processor and I'm glad we chose it. We have about 15 boards now with various flavours of the device. We'll continue to use it in new products so my experiences with the device can't have been that bad.

Cheers

In the defense of Atmel I would say that when they EOL most of the AVRs, they have another part that is pin compatible in its default mode. Is that not true for the Mega163?

If I wanted to complain about anything it would be the support. I found that the support team is rather slow about responding. Often you are referred to the AVRfreaks web site which is not even run at Atmel! I know they support it financially, but it is silly to let someone else run *your* support site!!!

Ted Wood wrote:

message news:...

'Pin Compatible' does not mean zero engineering effort. The 'new' devices are not likely to run the old code/fuse options, and those with CE approvals should, strictly, get their product re-approved....

On the EOL map are also ATtiny11/ATriny12, and AT90S1200, AT90S2313.

-jg

I'd second the FTDI chips, they're very easy to use.

If anyone is thinking of using them and wants a simple example of the PC software needed to drive them there's an example on the downloads page of our web site below. This is about the simplest possible (C++ builder) code needed to get the USB interface working.

I'm a hardware engineer, not software, and the FTDI example had me baffled, there's too much GUI cleverness etc when all I wanted was a simple tutorial.

Hope this helps anyone considering the FTDI chips.

Nial Stewart

------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design

This is system engineering. Given the estimated number of units, find a couple of hw solutions and pick the cheapest one. Now figure out how to push some of the hw into sw and amortize the effort into the cost saving per unit x number of units. I know it sounds crazy, but doing the usb in sw might actually pay off at some huge volume.

Just about anything certified for use in a nuclear power plant.

Or lots of military applications.

There are tons of applications where the cost/effort required to replace a device with a different "compatible" model are completely out of proporation to the actual cost of the device itself.

Could be. But when they're your customers, you try to meet their requirements and make them happy. If you don't, somebody else will.

Yeah, right. All we need are "cost effective" cheap unproven instrumentation and controls running nuclear reactors and oil refineries.

There are darn good reasons why the process control industry is very conservative.

Best regards, Spehro Pefhany

Yes, they are to be replaced by parts which are (optionally) available in 32-lead MELFs (physically smaller than the 8-DIP!). I've been talking to Atmel about these parts because I had planned to use them in my upcoming book. Apparently these parts are in an old process, and I'm "somewhat assured" that the replacements will be mostly code-compatible. Anyway, Atmel won't be leaving a hole in their lineup.

I don't have a lot of details yet. My Atmel contact is out of town at the moment. Fortunately, I have other things to work on in the meantime. I've been so busy over the past couple of months, virtually dropped off the Internet. Lots of catchup to do.

-- Lewin A.R.W. Edwards