Re: [Simulavr-devel] version bump

[Knut Schwichtenberg]

Joel Sherrill wrote:
> Weddington, Eric wrote:
>>  
>>
>>  
>>> -----Original Message-----
>>> From: address@hidden
>>> [mailto:address@hidden
>>> u.org] On Behalf Of Joerg Wunsch
>>> Sent: Wednesday, March 11, 2009 3:24 PM
>>> To: address@hidden
>>> Subject: [Simulavr-devel] version bump
>>>
>>>    
>>>> I think there needs to be a project list for GSOC.
>>>>       
>>
>> I definitely agree with you there. It's just this has had so much
>> activity, what should be put on such a project list for GSoC?
>>   
> The current TODO is a starting point.
> 
> Adding the missing models from the C version is probably
> a good GSoC project.  Grow it from there to add the CPU
> models which are only memory size and peripheral subset
> variations.  I don't know the effort required though.
That's does not sound good to me :-(.

But before defining jobs lets look to the current program and see what's missing
and which way to go - my opinion.
The M128 was in the past the "has it all" CPU. What is the difference between
the M128-HW and simulavrxx?

- TWI-Subsystem is missing completely - that is a closed tasked and of course
not simple

- ADC with MUX and so on was missing - currently I'm not sure
- handling of the fuse missing completely - to do this one needs to know were
the fuse come from. That leads to

- handling of different segments than text, data, bss is not supported

- a bootloader with a the tiny little details like different entries, switching
the interrupts, writing to the flash should be implemented

- the "Scope" is currently only en empty box

Based on my memory these are missing items - there is also a part within the
documentation.

Now the M128 is not longer the "has it all" CPU. In the none X-MegaWorld we have
a new EEPROM, different Timers, USI, CAN, 24Bit-Flash and maybe something more.

The IO-Subsystems are always good tasks to be implemented externally - with CAN
is a no need :-). But to be check and build a proper IO-simulation it would be a
great help if the Silicon-specilaist from Atmel could define functional
identical IO-subsystems (e.g. M32, M128,... have identical timers but 6xx ist
different). Eric here a serious support from Atmel would simplify programming.

On my opinion if the IO-subsystem are available, the tasks to make the M128
simulation "close" to the HW, than it is time to deploy the functions to the
other no X-AVRs (Mega, S, Tiny,... but not XMegas) .

A GSoC project could be to run a bootloader, maybe a full FLIP implementation on
both sides (PC, AVR). It does not matter which bootloader on the AVR is used -
it could also be a connection between avrdude and a simulated bootloader - more
difficult, if preferred :-).

Another one could be: Enter analog values into some (>1) channels of one M128,
digitize it, transmit the values via TWI to a second M128 and show the results
as PWM on the scope.


X-Megas, a GUI an interface to spice, deployment,... are jobs for the future.

> Knut mentioned a multiple CPUs example that doesn't run.
> Probably too little work for GSoC.  But important.
That sounds important for a project specific simulavrxx (hi Joel). I've see
Klaus' multiple usage. A quick project specific solution.

Knut