Re: [Simulavr-devel] version bump

[Knut Schwichtenberg]

Sitting in front of the simulation there is another issue:

Killing the active wait-loop is a need! Currently simulavrxx is a fan-test for
the most PCs, because the central wait is implemented as an active wait to
receive GUI events, gdb messages. One loop cycle is - if I remember it correct -
1ns simulation time. That does not hurt as long as you have a dual core CPU - if
not, most HW is getting slow - on Linux.

Knut

Knut Schwichtenberg schrieb:
> 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
> 
> 
> _______________________________________________
> Simulavr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/simulavr-devel