On Thu, Jan 26, 2012 at 11:49 PM, Andreas Fritiofson <[email protected]> wrote: > Indeed. I have some, still rather vague, ideas on how to change that. > I'm planning on exploring them in a not too distant future. As always, > my ideas are rather ambitious; I don't think it's fun building on code > that I know is architecturally broken. So we'll see if anything useful > comes out of it. I don't know how libswd would fit into that picture > (the one in my head) but then I haven't had the time to look at > Tomek's work at all. I have to say I'm a bit sceptical since having a > protocol as a library suggests that it is placed somewhere *between* > the target and the interface. Much like the current JTAG queue, which > will be the first thing to go once I start hacking.
Hello Andreas :-) I think first we need to modularize the code blocks (i.e. interface, transport, target, memory, cpu, smp, os, ...) and make them connected at runtime to some context that will represent a working system. This way different components can be connected to match target system and the context is the reference point for their runtime instances (do we want to use obect programming here?). All functions should operate on a context only, no globals at all. Context will make openocd multithreaded. etc etc :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
