"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 

"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: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: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

"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

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.

"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 

John Speth <johnspeth@yahoo.com> wrote:

> Certainly, if you write your own driver, it takes a good bit of
> programming ability, tool investment, and testing requirements.

There's also the option of user-mode drivers which are easier to
implement. Libusb works on virtually all platforms, Windows Vista has
WinUSB and on OS X has IOKit. There's also some commercial offerings for
Windows, eg. Jungo's WinDriver.

-a

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

"FD" <fd@fd.ods.org> wrote in message 
news:4631d3e9$0$30828$e4fe514c@dreader19.news.xs4all.nl...
> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> schreef in bericht
> news:f0r6kh$ge0$1@aioe.org...
>> >
>>> 3. Specifically, if you choose the COM port emulation (usbser.sys),
>>> you'll be dogged with always wondering what the COM port is when you 
>>> plug
>>> it in. I hate that problem.  Love to know if there's a solution.
>>>
>>
>> A well behaved CDC uses a serial number and you allocate
>> a new port for every new serial number you detect.
>> This is not so good in a school environment where
>> you can have a large qty of USB devices and you will eventually
>> have a COM port allocated for each such device.
>>
>> -- 
>> Best Regards,
>> Ulf Samuelsson
>> This is intended to be my personal opinion which may,
>> or may not be shared by my employer Atmel Nordic AB
>
> I am a newbie on the USB front and the host side driver is something that 
> I
> overlooked a bit. I definitely need Windows and Linux support.
>
> A USB to serial convertor (in my design) might be a very simple solution.
>
> It is not too hard to find the COM port where the device is connected to:
> - scan the first 20 ports for availability (open the device)
> - provide a handshake method between application and device
> - for multiple devices: serial number the device with handshaking
> I already use this with the serial devices I developed, since I 
> implemented
> a serial communications protocol.
>
> Frank
>

I have had good luck with the Silabs CP2103 USB to Serial Bridge 
components. They provide good utility programs for low level programming of 
the parts. They seem to work with less problems than other Serial/USB 
converters.

For my serial communications, I use SerialNG: 
http://www.domis.de/serialng.htm. It seems to work well with Delphi 4. 
There is a function that returns a list of all COM ports that have been 
enumerated by the PC, so you don't need to try opening all possible ports. 
I send out a test code and detect proper response to determine if a device 
is connected.

The device I developed is essentially a data collection device, operating 
at 2400 samples per second to read line frequency waveforms to 10 bit 
accuracy. My port is set for 57600 Baud. I use a Microchip PIC18F242, 
14.7456 MHz clock, which divides exactly to the usual baud rates. I 
programmed in assembly using a reference application as a starting point. 
The 18F parts are designed to be used efficiently with C compilers. I have 
C18, but have not yet used it.

Paul