![]() ![]() That way I don't miss information that the specific chapter on the USB peripheral may not mention. The way I read the RM is by searching for the string "USB" and going through all occurences in the RM. NOTE: I intentionally read the RM after reading the code for the existing driver because the comments from the old driver source give me points to watch out for in the RM. This time I will give it my full attention and because on Day 1 I brushed up my knowledge of the USB specs, I will have a better understanding of what every register does. Of course that time I did not read the USB chapter very thoroughly. It's not a first time read because I went through the whole reference manual from start to finish once when I started working with this particular MCU family. Next, I re-read the USB-related info in RM0394, the reference manual for the STM元2L4x2. If I did not already have an API to be implemented, I would definitely read all the function signatures and documentation for STM's HAL before planning my own API. This is an easy way to answer questions such as "Do I need to initialize register A before register B?" or "Do I need to set flag X?" in cases where the Reference Manual is not clear. The main way I will go about it will be to grep through STM's source code for the names of registers and flags that I'm currently writing code for. While I have no concrete plans to read STM's complete HAL code for the USB peripheral, I will definitely peek at it from time to time. ![]() You'll see what kind of data structures are used, what API, and if the driver code you look at is for the same MCU, you may see comments regarding oddities or errata affecting that MCU. Even if not as well commented, existing code can still give you important hints. ![]() However I still did read the code for an existing USB driver. When I wrote my first USB driver I did not have that luxury, of course. These comments may now save me from making the same mistakes again. Or if I had an issue that I debugged for hours only to discover that I was looking in the wrong place altogether, I would have written a comment about that. In this particular context, if there was something that was unclear to me about an aspect of USB, that I had to do research on while writing my driver I would have written it into a comment, complete with a reference to the document(s) that provided me the information. One philosophy I follow when writing comments is "Write the comments that would have saved me time if they had been there before I started working." The main reason I'm doing this is for the comments. I re-read my own driver code I wrote for the USB peripheral of NXP's MK20DXxxx. General question: any question that is not technicalĪfter your question is answered, please change the flair to "Resolved".(*) At mods' discretion, certain self-promotion submissions from people who contribute to this sub in other ways may be allowed and tagged with the "Self-promo" flairĬomplete rules: /r/embedded/about/rules/ Link flairsĪfter posting a submission, please select a flair: No memes (pictures with superimposed text), shit posts.No spam no commercial posts, links to commercial pages (including crowd funding sites), no employment ads (job offers and requests go to the weekly thread), no self-promotion (*).If asking a question, ask the actual question, fully yet concisely, right in the title.Be civil: do not insult no all-caps, no excessive "!" and "?", please. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |