Selection of a USB microcontroller

"FD" <fd@fd.ods.org> wrote in message 
news:463081e1$0$7174$e4fe514c@dreader26.news.xs4all.nl...
> The best programming language would be C. C++ and Pascal (Delphi) on the 
> PC
> is no problem and so is some assembler in the microcontroller.
> The microcontroller should be around 5 to 20 MIPS with at least 8KB Flash,
> 2KB RAM and a little non-volatile storage (like EEPROM).
>
In the last year I've built several projects using the SiLabs C8051F320 and 
C8051F340 series full speed slave USB controllers.  The 'F320 runs at 24Mhz, 
and the 'F340 at 48Mhz.  Flash ranges from 16KB to 64KB, RAM from 1KB to 
4KB, plus a 1KB USB FIFO.  These work very well in small projects, since the 
chip has an on board oscillator (no crystal needed) and it can be USB bus 
powered with onboard regulator.  The SiLabs website has quite a bit on 
reference designs and basic software, especially the USB CDC and HID class 
drivers.  I use the SiLabs IDE with the SDCC-51 compiler, no cost and no 
code limits.
   Jack Peacock 

Viktor wrote:
>> I have experience with Atmel ATmega8, 32 and 128 (without USB). Lots of
>> Flash and RAM, but they are not so good in industrial environments.
> 
> Could you elaborate on this please? Are AVRs at a given voltage and
> frequency more susceptible to noise than 8031 variants?
> 
>> The 8051 family is much more reliable, but my very good experiences with
>> these are over 5 years old.
> 
> You could do worse than an 8031 variant with an FDTI USB chip.
> 
> 

Using an FTDI serial device will give you three big advantages.  On the 
hardware side, you have no need for USB-specific development in hardware 
or firmware - you use whatever microcontroller you want, and connect up 
a serial port.  On the PC side, you have drivers and libraries freely 
available for Windows, Linux, and MacOS in lots of varieties.  You can 
choose to treat the device as a serial port (easy programming) or use 
the libraries (almost as easy, and giving access to extra features such 
as serial numbers).  A third advantage is that you don't need any code 
on your microcontroller to get up and running - if your microcontroller 
can be programmed over a UART, or using a serial bit stream of some 
kind, then a PC program along with the FTDI chip can program your 
microcontroller.

"Viktor" <vkesler@gmail.com> schreef in bericht 
news:1177780763.332539.3550@u30g2000hsc.googlegroups.com...
>
>>
>> I have experience with Atmel ATmega8, 32 and 128 (without USB). Lots of
>> Flash and RAM, but they are not so good in industrial environments.
>
> Could you elaborate on this please? Are AVRs at a given voltage and
> frequency more susceptible to noise than 8031 variants?
>
>> The 8051 family is much more reliable, but my very good experiences with
>> these are over 5 years old.
>
> You could do worse than an 8031 variant with an FDTI USB chip.
>

I now have 5 designs with ATmega processors to control high voltage DC and 
stepper motors. With about 2000 boards produced, we had several problems in 
the field, like: corruption of Flash (sometimes) and EEPROM (quite often) 
and flipping of bits in the fuses (5 occasions). Also brand new chips had 
bad fuses, so that they could not be programmed in the circuit (which could 
be fixed by applying an external clock oscillator).

Before I used TI's TM370 and ST's ST6 in a similar design (about 5000 
produced) without any of these problems. Used about 1000 pieces of Hitachi 
H8S in industrial equipment where driver chips often burn out just because 
of earthing problems, but the processor never failed.
Years ago I only developed with the 8051 and they were reliable as hell. I 
used them to remotely monitor and control heating pipes at the railways. 
Talking about a noisy environment when a train comes by! The 8051 tripped, 
but a reset always brought them up and running again.

Frank

"FD" <fd@fd.ods.org> wrote in message
news:46370182$0$32623$e4fe514c@dreader16.news.xs4all.nl...
> I now have 5 designs with ATmega processors to control high voltage DC and
> stepper motors. With about 2000 boards produced, we had several problems
in
> the field, like: corruption of Flash (sometimes) and EEPROM (quite often)
> and flipping of bits in the fuses (5 occasions). Also brand new chips had
> bad fuses, so that they could not be programmed in the circuit (which
could
> be fixed by applying an external clock oscillator).

I am inclined to think your board design is not EMC proof.
I have designed a system with an ATmega162 which is tested according to
IEC/EN60945. This also includes several tests where 2kV AC and 1kV DC
transients are applied to all terminals of the device and a 6kV or 8kV
static discharge is applied to the housing or in the very near vincinity of
the device.

No problems were encountered, the device operated normally or recovered
immediately (watchdog reset) after the test.

Meindert

"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> schreef in bericht 
news:46370f27$0$29000$e4fe514c@dreader24.news.xs4all.nl...
> "FD" <fd@fd.ods.org> wrote in message
> news:46370182$0$32623$e4fe514c@dreader16.news.xs4all.nl...
>> I now have 5 designs with ATmega processors to control high voltage DC 
>> and
>> stepper motors. With about 2000 boards produced, we had several problems
> in
>> the field, like: corruption of Flash (sometimes) and EEPROM (quite often)
>> and flipping of bits in the fuses (5 occasions). Also brand new chips had
>> bad fuses, so that they could not be programmed in the circuit (which
> could
>> be fixed by applying an external clock oscillator).
>
> I am inclined to think your board design is not EMC proof.
> I have designed a system with an ATmega162 which is tested according to
> IEC/EN60945. This also includes several tests where 2kV AC and 1kV DC
> transients are applied to all terminals of the device and a 6kV or 8kV
> static discharge is applied to the housing or in the very near vincinity 
> of
> the device.
>
> No problems were encountered, the device operated normally or recovered
> immediately (watchdog reset) after the test.
>
> Meindert
>

At first I also thought the design was not EMC proof, but it passed all 
tests. We have done additional testing in extreme conditions 
(temperature/humidity/power) with large transients on power supply, 
terminals, housing and with some sabotage actions like removing shielding 
and grounding wires.
Now there are 5 designs which are used in different pieces of equipment. 
Weird is that they all show similar problems.

The only thing that I really have found is that the ATmega is very sensitive 
about the way it is powered up and down.
A slow rise and fall of power can cause corruption of the EEPROM. I modified 
the software to shutdown the application and processor when the power is 
removed, but it did not solve the problem completely.

Frank

"FD" <fd@fd.ods.org> wrote in message
news:46385a16$0$26212$e4fe514c@dreader25.news.xs4all.nl...
> The only thing that I really have found is that the ATmega is very
sensitive
> about the way it is powered up and down.
> A slow rise and fall of power can cause corruption of the EEPROM. I
modified
> the software to shutdown the application and processor when the power is
> removed, but it did not solve the problem completely.

You are using the brown-out detection on the ATmegas I assume?

Meindert

"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> schreef in bericht 
news:46386902$0$26622$e4fe514c@dreader12.news.xs4all.nl...
> "FD" <fd@fd.ods.org> wrote in message
> news:46385a16$0$26212$e4fe514c@dreader25.news.xs4all.nl...
>> The only thing that I really have found is that the ATmega is very
> sensitive
>> about the way it is powered up and down.
>> A slow rise and fall of power can cause corruption of the EEPROM. I
> modified
>> the software to shutdown the application and processor when the power is
>> removed, but it did not solve the problem completely.
>
> You are using the brown-out detection on the ATmegas I assume?
>
> Meindert

Of course, but that did not make any difference.

Frank