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
