Hi William, 2011/5/6 William <[email protected]> > > Yes! This is what I thought was your original intent, when you said > you had verified that the HEX code was the same, and is why I kept > asking about the inline statements and their placement. > > As to why you wanted to rewrite spi_init to use your new routines, I > have no idea.
Because SD card lib doesn't have to deal directly with SPI registers (direct access to device file == device file layer) but instead ask SPI lib to set it (access to SPI lib == spi lib layer). That's why I was talking about different layers. This done, it's now easy to use SD card with MSSP1, MSSP2 or SPI software, because actual registers are hidden behind a procedure. That's why we did this. > Perhaps you thought it was more elegant, or more > efficient, or??? As your latest compromise proves, the HEX code will > be exactly the same. > yes, but it consumes quite a lot... except with const-detect usage. We're beginning to see something interesting. > Now then, about open-source -- JALLIB is 'released' every so often, > correct? And those 'releases' do not require the end-user to know > anything about SVN, so it is important that each source file in the > 'release' adhere to the copyright and license of each individual > source file. That is why I wanted you to add your name to the files, > and remove my name from a file that I didn't create. > OK, I understand that. but I also didn't want to put my name as author on spi_master_hw2.jal: even if you didn't create this file, you're still the author in some way. Truely, I just "sed" "1"s into "2"s. I put my name as adapted-by, and apologize for the ommission. Being an author isn't related to file creation: some libs in jallib refers to authors who didn't write the lib, nor are part of the jallib team, nor even post a message here. This occurs when an existing code is translated into JAL: writer adapted it, but the core logic isn't from his/her brain. About SVN relation, ***maybe*** we could add a revision ID. I wrote "maybe" because this usually is bad practive, as it produdes unecessary conflicts while merging. But, let's be pragmatic: we don't use SVN merge feature often, if at all. So, we could give a try, this would add an interesting entry point to SVN, when file is released in the nature, and would allow having the full history. (because, say, I change again spi_master_hw.jal, but my name is already put as adapted-by, so you won't notice the difference...) > As the author of the library, which is in fact the very heart of > hardware SPI operation, I do intend to speak up from time to time. > Sure you do, you can, and you're highly recommended to do so ! And I'm happy you did as I'm sure we'll finally end with something better ! But don't ask to revert it back in the name of "I have programs out there, I don't want to test them again, don't change anything!". This really isn't in the jallib spirit, being able to change, to improve, modify API, etc.. is something we claimed here at jallib from the very beginning, I really don't want this project to become fossilized because of an existing code base. Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
