Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 7 months ago.
Library source code confusion
I'll admit I'm not generally comfortable with many aspects of "libraries". I understand their value, but implementing with them can be daunting and confusing. I like to look "under the hood" (so to speak) but libraries thwart that.
I'm using the online mbed compiler, and one of the example programs I've downloaded calls "AnalogIn" and I'd like to see how that operates.
So, with all that in mind, I clicked, in the left frame, mbed, Classes and then AnalogIn. If I try to click the '55' in: "Definition at line 55 of file AnalogIn.h." I get an error message (which of course I cannot copy and paste - argh!):
"The source files preview is unavailable for library builds. To preview source files you should convert the build into library."
1 Huh? It's already a "library" isn't it? So why would I want to build it into a library?
2 And more to the point, can and how do I get to the source of "AnalogIn"?
-Mike
edit: OK - digging again I was able to move the ball forward WRT 2) and loaded mbed-src but that only shows me that AnalogIn really calls the function analogin_init() and that has no source still.
So my questions still stand.
3 Answers
8 years, 7 months ago.
You're on the right track. Unfortunately without an intelligent parser you only can see down one level at a time. If you had the same code out in Eclipse for example you could keep tunneling in to where the call was coming from and you'd see that the high level API calls the target unique instantiation. Within mbed-src (or now mbed-dev) you will see additional folders for your specific target. Take a look a few more levels deep and you will find the actual code in the target CMSIS or HAL folders.
Or, export your code to Eclipse or one of the other IDEs and you can easily navigate to the correct code with a couple of clicks.
HTH Bill
8 years, 7 months ago.
The reason it gets a little confusing is because while the header file is the same for all mbed platforms the c file behind it will depend on the CPU being used.
The platform specific implementations are in the source under /targets/hal/[vendor]/[CPU]/, a quick look doesn't make it very clear which cpu is on the mdot but I think the correct analog in for you would be this one.
A lot of what goes on in these files are reads and writes to specific control registers within the CPU. To make sense of them you normally need to see the user manual for the processor. You can get that from the manufacturers web site. If I've got the correct CPU then for the analog in you would want chapter 13 (pages 390-432) of this pdf paying particular attention the to register descriptions starting on page 418.
Other device specific header files have all of the register names #defined with the correct memory addresses given in the manual so that the code can use the names rather than the memory locations.
Not having to dig through 1700 page long documents like this is why libraries like the mbed one are so helpful.
What's often missing from datasheets is a "what you need to set in order to configure this" flowchart. The actual process of pulling data from the ADC is fairly simple (honest) but getting it running in the first place is a bit more involved as you need to consider your clock frequency and there may be registers that must be written in a specific order.
posted by 18 Apr 2016That's why you end up needing to virtually read the whole manual, just to find the single tiny footnote saying "In order to get this section of the device to operate correctly you must also enable the power and clock to a completely unrelated peripheral which isn't mentioned at any other point in this section of the manual."
Not that any silicon vendor would ever do anything like that to their customers.
Normally they simply skip the footnote completely and let you figure it our yourself.
posted by 18 Apr 2016
8 years, 7 months ago.
I've been learning my way around MBED-src too, hit the same issues.
A rough map would be that the C++ class definitions are in API
The Classes are defined in Common
There's headers for a lower level API in "HAL". This uses more C-like code rather than C++, in particular the peripheral "object" at that level is really a "struct". This is the layer that actually operates the hardware.
Following "Targets" .. "HAL" .. Manufacturer name .. Chip name should get you the actual C modules. In some cases it is "Targets" .. "HAL" .. Manufacturer name .. Chip group .. Chip name as devices with the same internal architecture but different pinning may share files.
The peripheral allocation is "clever" but can be hard to follow. Unlike most of the header files the "peripheralnames.h" and "portnames.h" files are device specific and are in the "Targets/hal" tree.
Also noticed this in the "related items" bar to the right: https://developer.mbed.org/handbook/mbed-library-internals which I could have done with earlier when I was trying to work it out for myself
posted by 18 Apr 2016