{"action":"created","issue":{"url":"https://api.github.com/repos/libopencm3/libopencm3/issues/410","labels_url":"https://api.github.com/repos/libopencm3/libopencm3/issues/410/labels{/name}","comments_url":"https://api.github.com/repos/libopencm3/libopencm3/issues/410/comments","events_url":"https://api.github.com/repos/libopencm3/libopencm3/issues/410/events","html_url":"https://github.com/libopencm3/libopencm3/pull/410","id":59168637,"number":410,"title":"RCC request for comment","user":{"login":"esden","id":17334,"avatar_url":"https://avatars.githubusercontent.com/u/17334?v=3","gravatar_id":"","url":"https://api.github.com/users/esden","html_url":"https://github.com/esden","followers_url":"https://api.github.com/users/esden/followers","following_url":"https://api.github.com/users/esden/following{/other_user}","gists_url":"https://api.github.com/users/esden/gists{/gist_id}","starred_url":"https://api.github.com/users/esden/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/esden/subscriptions","organizations_url":"https://api.github.com/users/esden/orgs","repos_url":"https://api.github.com/users/esden/repos","events_url":"https://api.github.com/users/esden/events{/privacy}","received_events_url":"https://api.github.com/users/esden/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-02-27T00:27:37Z","updated_at":"2015-03-01T05:12:40Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/libopencm3/libopencm3/pulls/410","html_url":"https://github.com/libopencm3/libopencm3/pull/410","diff_url":"https://github.com/libopencm3/libopencm3/pull/410.diff","patch_url":"https://github.com/libopencm3/libopencm3/pull/410.patch"},"body":"I am looking into the way RCC is being initialized. I do like the way it is done on F4 as it makes the code more readable and should make the code reasonably flexible without adding copy pasta functions as it is the case for F1. (the idea for F1 was that it is saving memory by being a single function and we use it only once in the code, the compiler will optimize out the other implementations)\r\n\r\nThis pull request is meant to start conversation on how we can retrieve the different resulting clocks after the RCC is set up.\r\n\r\nAlso I am adding some prefix changes in this patch to decrease the name space pollution by the library. That we could fold in into this upgrade as we will be breaking the current API anyways.\r\n\r\nThe proposed solution adds the resulting clock values to the clock scale struct. There are two alternatives to this solution that would introduce functions returning the currently set clocks.\r\n\r\nThis solution would be the basis for implementing similar approach for all the other chips supported by the library. This patch is meant only as an example.\r\n\r\nHere is the list of possible solutions:\r\n1. Store the clocks in the struct. (can be error prone and has copypasta issues and whoever writes the struct has to make sure they put the right values in)\r\n2. Implement functions that return the current clock setting based on the last used scale struct. It will return wrong value if a developer decides to set the clock \"by hand\" instead of using the setup function and struct.\r\n3. Implement functions that return the current clock setting based on the relevant register values set. I am not sure if we can access all of them without disturbing the system.\r\n4. Code generation. Have a script in libopencm3 that generates static RCC functions and const variables containing everything. Might be the smallest memory footprint solution.\r\n\r\nThe solution 2 and 3 will likely cost more flash memory as the functions will likely be bigger than storing 4 additional variables in the scale struct. Also the functions have to be very careful that they take all factors into account and will likely have to be implemented differently for every chip supported by the library.\r\n\r\nI am curious what your guys take on this is and if you can thing of even better ways of doing this that will use as little memory as possible, be accurate and introduce as little possible implementation bugs and so on.\r\n\r\nThis pull request is a continuation on the proposed solution in #286 and will impact #379 \r\n"},"comment":{"url":"https://api.github.com/repos/libopencm3/libopencm3/issues/comments/76574782","html_url":"https://github.com/libopencm3/libopencm3/pull/410#issuecomment-76574782","issue_url":"https://api.github.com/repos/libopencm3/libopencm3/issues/410","id":76574782,"user":{"login":"ChuckM","id":532407,"avatar_url":"https://avatars.githubusercontent.com/u/532407?v=3","gravatar_id":"","url":"https://api.github.com/users/ChuckM","html_url":"https://github.com/ChuckM","followers_url":"https://api.github.com/users/ChuckM/followers","following_url":"https://api.github.com/users/ChuckM/following{/other_user}","gists_url":"https://api.github.com/users/ChuckM/gists{/gist_id}","starred_url":"https://api.github.com/users/ChuckM/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ChuckM/subscriptions","organizations_url":"https://api.github.com/users/ChuckM/orgs","repos_url":"https://api.github.com/users/ChuckM/repos","events_url":"https://api.github.com/users/ChuckM/events{/privacy}","received_events_url":"https://api.github.com/users/ChuckM/received_events","type":"User","site_admin":false},"created_at":"2015-03-01T05:12:40Z","updated_at":"2015-03-01T05:12:40Z","body":"Oh, and you can calculate clock speeds if you know whether or not the system is running on HSE and the value of that HSE crystal. But it seems like over kill to recompute that every time when you can just cache a copy of it in a variable somewhere. My original rewrite had a `get_clock_speed({AHB, APB1, APB2})` function but it did not provide much utility over having an variable I could reference with the value in it."}}