On Thu, Jan 17, 2013 at 11:20 PM, Laurent Gauch <[email protected]> wrote: >> Multi-billion companies have used your approach for their work on the >> Linux kernel and all they get for it is ridicule by everyone with >> half a clue in the kernel community. > bla bla bla . You cannot compare Linux and OpenOCD. Linux is now mature > and it is natural to have only small patches in the kernel. > But what about the begin of Linux ? I am not sure there were only small > patches.
Thats okay Laurent, I take is as "work on main repository not separate fork so you wont be outdated as with mpsse driver", and this is good remark :-) Smaller steps would also be more acceptable for the rest of developers... However from the organization perspective we should leave old code as 0.x.y and start new as 1.x.y... Lets treas current code as a pool of ideas and proof of concepts and now make something stable and more clean out of it :-) >> Bitbanging is never a good idea. The only time it has the slightest >> chance of even working is if the IO register is very very close to >> the code that implements the logic. Consider a USB interface driven >> by high-level scripting and you find the very antithesis. It's a >> horrible idea. > depending on what the end-user is doing. Sometimes it could help to do a > specific actions... I mean cjtag spi hacks. But you are right it should > not be used in the concept itself. Again, I dont agree here. Bitbang is an essential operation on a GPIO. No matter what is the target, bus, interface, etc. Bitbang means "operate on GPIO step by step". If the GPIO is attached to local machine or any other place of the universe thats another thing, still it is "bitbang". Because bitbang can and will introduce delays, "Transfer" method was introduced to gather as many single operations together and stream them in a single transfer/command. This way we have only two methods "bitbang" and "transfer" that can be used to accomplish any task of the Interface. And this is why I want those two to become mandatory methods of the new Interface model. Anything else can be accomplished by Interface Features that can be dynamically loadable/editable and use "bitbang" + "transfer" for bistream generation. Bitbang is used to toggle output buffers read/write. It can be also used to create dedicated protocols, drive reset signals, talk to the interface peripherals, even send/read the bitstream on integrated GPIO, etc. All this from the level of TCL. One command, one GPIO mask operation. Only two things are hardcoded into the source code for efficiency. Other efficient and hardcoded things can be dynamically loaded as Interface Feature. This makes API virtually limitless and gets rid of JTAG centric approach. Transfer is used to send many bits/bytes/words at once, like mpsse operation to send lets say 64k words - so many bits, only one command, only one transfer (if below 64k?). If there are more bitbang operations enqueued of the same type (i.e. read port or write port) they can be compacted and sent using Transfer instead Bitbang for better performance. It is also possible define only one method for an Interface - Bitbang, make it accept char arrays, number of bits and number of bytes to transfer, then the undelrying function will know what command to choose and the API gets even simpler. What is so wrong about that? If we restrict layer communication only to one up and one down, for HLA we can define HLA transport, then target calls would be passed directly to the Interface Feature HLA using Transport "HLA". For generic interfaces target will call transport to generate a bitstream and interface would transfer that bitstream to the hardware. I know this seems obvious, but this is still missing and needs to be done, unless you are happy with current organization. Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
