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: [email protected] >>>> [mailto:simulavr-devel-bounces+eweddington=cso.atmel....@nongn >>>> u.org] On Behalf Of Joerg Wunsch >>>> Sent: Wednesday, March 11, 2009 3:24 PM >>>> To: [email protected] >>>> 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/simulavr-devel _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
