ATMEGA64/128 and Proteus question.

[Iain]

atmega64

We (Labcenter) are considering implementing a limited model for these parts comprising a set of the most commonly used peripherals alongside the instruction execution engine.

The general idea is that such a model could be developed in a reasonably short time and would allow us to gauge demand for a full model whereas development of a full model in the first instance would be quite time intensive.

We'd be interested to hear whether users (or potential users) would find a model of this type to be of use, and if so which peripherals could be excluded/not modelled (or alternatively, which peripherals would be considered essential...) ?

 

[dimmy]

attiny2313 example codes for imagecraft c

Maybe it would be nice to start from an existing model (ATmega 16/32), maintain compatibility (SFR addresses, interrupt vectors), and firstly just extend memories and add the second UART/USART?

By the way, ATmega162 is a nice compromise: 2 USART's, 4 timers, 1024 bytes RAM - and a DIP package.

 

[panalog9]

proteus atmega64

Iain -

Can you list the peripherals in order of complexity/time for building the models for them ? That way we could kind of pick a-la-carte.

In general, I think you'll find the Atmel/AVR crowd a fairly large one, and given a good tool, will bring them in in droves.

Personally, I would like to see them in the following order :

Timers - all 4
SPI hardware port (both)
I2C hardware port
USART port (both)
External interrupts
PWM hardware
A/D 8 channels
Hardware multiplier (easy I think ?)

The rest as you can do it

Thanks -

-pana

 

[Iain]

code visionusard

The decision about what would be included is not mines (a colleague 'owns' the AVR at the moment) but a lot of it would depend on how similar the peripherals are to those in the existing variants modelled.

As a *very* rough guide I would think it would split something like :

Almost Certainly modelled :
Timers,
USART,
Watchdog,
ADC (perhaps some channels modelled?),
Analog Comparator (assuming similarity to M103),
MSSP


In the gray zone :
PWM modes,
Output Compare Modulator,
103 Compatibility Mode,

Definately not modelled in Initial release :
TWI Interface.

 

[Iain]

.hex to .eep atmel

Sorry - meant to add that I would image external interrupts to be definates for inclusion

 

[ME]

codevision usart sample proteus

Do you have any plans of supporting the CodeVisionAVR C compiler?

 

[Iain]

coff cvavr 2

First of all, these parts are now modelled (including TWI) in V6.6

ME - Which object format does codevision produce ?

From a quick glance at the code anything that produces COF or the IAR Ubrof format (also of course HEX files - no debug with this format unless written in assembler and compiled via Source menu in ISIS) should be fine .

Simply specify the .COF file as the program file for the chip.

Iain.

 

[ME]

codevision proteus

ME - Which object format does codevision produce ?

From a quick glance at the code anything that produces COF or the IAR Ubrof format (also of course HEX files - no debug with this format unless written in assembler and compiled via Source menu in ISIS) should be fine.

Simply specify the .COF file as the program file for the chip.

Iain.

CodeVision can produce COFF files, but CodeVision is not listed at your site as supported compilers:
http://www.labcenter.co.uk/index.html?/products/compilers.htm
Only IAR and GCC are mentioned, not the other two AVR C compilers: CodeVision and ImageCraft. I thought there was a reason why ImageCraft and CodeVision is not mentioned.

Why is it not listed if it's supported?
Have you tested Proteus with CodeVision?
You can download the CodeVision User Manual here:
http://www.hpinfotech.ro/cvavrman.zip
The COFF files are described in the the CodeVision User Manual.

Using the File Output Format(s) list box you can select the following formats for the files generated by the compiler:
• COFF (required by the Atmel AVR Studio debugger), ROM, Intel HEX and EEP (required by the In-System Programmer) ;
• Atmel generic OBJ, ROM, Intel HEX and EEP (required by the In-System Programmer).

ImageCraft also supports COFF.

 

[Fragrance]

proteus demo and codevision

ME - Which object format does codevision produce ?

From a quick glance at the code anything that produces COF or the IAR Ubrof format (also of course HEX files - no debug with this format unless written in assembler and compiled via Source menu in ISIS) should be fine.

Simply specify the .COF file as the program file for the chip.

Iain.

CodeVision can produce COFF files, but CodeVision is not listed at your site as supported compilers:
h**p://www.labcenter.co.uk/index.html?/products/compilers.htm
Only IAR and GCC are mentioned, not the other two AVR C compilers: CodeVision and ImageCraft. I thought there was a reason why ImageCraft and CodeVision is not mentioned.

Why is it not listed if it's supported?
Have you tested Proteus with CodeVision?
You can download the CodeVision User Manual here:
h**p://www.hpinfotech.ro/cvavrman.zip
The COFF files are described in the the CodeVision User Manual.

Using the File Output Format(s) list box you can select the following formats for the files generated by the compiler:
• COFF (required by the Atmel AVR Studio debugger), ROM, Intel HEX and EEP (required by the In-System Programmer) ;
• Atmel generic OBJ, ROM, Intel HEX and EEP (required by the In-System Programmer).

ImageCraft also supports COFF.

Hi loving ME

Yes you can used code visionavr .cof file for debuging in proteus i have carefully varified this, also attach a example using code visionavr .cof file as debuger in proteus you have to press Ctrl and F12 to start debuging

 

[Iain]

proteus debug atmega168

The reason that these compilers aren't listed under the supported compilers page is that we dont possess a copy of the compiler and so cannot guarantee correct operation or provide back end support to customers using that compiler.

That said, we may well get in touch with CodeVision and ImageCraft in the near future to resolve this.

Iain.

 

[ME]

atmega168 proteus

That said, we may well get in touch with CodeVision and ImageCraft in the near future to resolve this.

Iain.

Yes I think that would be in the interest of both CodeVision, ImageCraftall and Proteus. It would give you maore potential customers.
I know you can download a free limited demo version of CodeVision, I don't know if this is enough to test the coff files.
Maybe ImageCraft has a downloadable demoversion too.

 

[Iain]

proteus attiny2313

I have spoken to both Imagecraft and Codevision, both of which have now been added to the supported compilers range for the AVR models.
http://www.labcenter.co.uk/products/avr.htm

Thanks to ME for pointing this out.

Iain.

 

[ME]

eep atmega 64

I have spoken to both Imagecraft and Codevision, both of which have now been added to the supported compilers range for the AVR models.
h**p://www.labcenter.co.uk/products/avr.htm

Thanks to ME for pointing this out.

Iain.

There's a few typos at the bottom of this sit regarding HP InfoTech's link:
www.labcenter.co.uk/index.html?/products/avr.htm

It says HTInfosofts Website but the correct name is HP InfoTech.

The link is also wrong: **broken link removed**
The correct link is: http://www.hpinfotech.ro/


A lot of the newer AVR microcontrollers are not listed as supported devices, for example ATtiny2313, ATtiny13, ATmega48, ATmega88, ATmega168, ATmega169, ATmega162, ATmega165 etc.
Are these devices not supported?

 

[Iain]

iar cof file

I've changed the link and info - my mistake :-(

Re. new devices :
The listed set on the website is current - we recently added the Mega 64/128 and will be looking at expanding the variant set sometime next year (variant inclusion dependant on demand - see h**p://www.labcenter.co.uk/vmodels/modelreq.htm).

We are currently updating the PIC18 variant set and I believe will be looking towards the LPC900 next, but will certainly be revisiting the AVR family in due course.

Iain.