n00b question - What's the difference between a low-levevel device driver and a high-level component, exactly?

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

n00b question - What's the difference between a low-levevel device driver and a high-level component, exactly?

1,917 次查看
tomii
Contributor III

So, I'm new to KDS, Codewarrior, etc - especially processor expert stuff.

 

I've been having some problems with a high-level component (InternalI2C, if it matters), and I've been noticing some things and wondering about how badly I'm screwing things up, etc.

 

I notice that when I create a high-level component (e.g. PWM), an LDD is present in the list beneath it (I am supposing that there is an inheritance mechanism going on there).  That LDD and all of its sub-functions (if you will) are all greyed out. I'm able to go through the PE dialogs and do all the settings for the PWM, for instance, and make an LED dim/brighten.  My assumption after managing all this is that the top-level component is using those functions/methods, and that I shouldn't touch them (generally speaking).

 

So, I blindly tried to do the same thing with I2C, and immediately ran in to trouble, in that the functions all returned errors.  Surfing the code a bit (a lot, actually) led me to believe that maybe the hardware wasn't correctly initialized - that maybe the init function was never actually being run..

 

So I deleted the high-level function (InternalI2C), and dropped in the LDD (I2C_LDD) instead.  Now, I can run some of those functions without error, but I'm obviously doing something else wrong, as they're hanging up...

 

But that aside, am I reading this right?  I mean, the LDD's are just that, low-level driver routines, and the high-level functions are encapsulating those LDDs into a somewhat easier-to-use set of functions?

 

What are the differences in the use and initialization (eg the care and feeding)?

 

Any thoughts, pontifications, etc?

标签 (1)
标记 (3)
2 回复数

1,259 次查看
BlackNight
NXP Employee
NXP Employee

You might have a read at There is a Time and Date for both Worlds | MCU on Eclipse

First, there were the 'high level beans' or 'high level components': Easy to use components and drivers which can be both used in bare metal and RTOS environment, as long as the application (with or without RTOS) takes care about shared peripherals. You will see that high level components get initialized implicitly with PE_low_level_init() called inside main().

These high level components exists say for HCS08, HCS12, DSC, ColdFire.

Then came Kinetis and with it the LDD (Logical Device Drivers). The difference is that they have a different API, and the biggest change is that they have a 'driver handle' passed to each API function you call. You get that device handle from the Init() method. Unlike the high-level components, you can use one driver from different contexts. The downside is that the API is more complex, and makes it not compatible with the previous high level components. That's why for many of the LDD components there is a 'high-level-component' as a wrapper to the LDD: both to make usage simpler (or less powerful), and to provide a bridge and compatibility between the LDD and the high level component world.

Having said that, things are changing again with the Kinetis SDK (www.freescale.com/kds): unlike as with the LDD and high level components were they are generating the actual driver code, with the Kinetis SDK the driver code is 'static' (not generated) and comes from the SDK. Processor Expert SDK components here configure the SDK (creating the configuration header files), but not actually generating the driver code. The driver code is in the SDK.

I hope this helps,

Erich

1,259 次查看
tomii
Contributor III

Erich,

     Thanks - I've actually already been reading your posts on mcuonelcipse.com for a bit, now, as I try to pick some of this stuff up.

     Also true is that I've started out with the KDS, as it was the only free tool I could find that didn't require me to spend a month integrating...  So, here I am, a beta user that is trying to learn the hardware.  D'oh!

     Now I shall stride bravely (stupidly?) forward and see what trouble I can get myself into.  So far, I am now on my 9th "hello world," each doing something slightly different with the hardware, and so far I've had good luck (if some interesting learning experiences) with the high-level components (since I am nowhere even considering an RTOS at this point).  It's been the I2C stuff (that I alluded to) that has got me wondering about the deeper workings of the environment.

     I think that you and I are saying the same things, only maybe in slightly different dialects :smileywink:

     Thank you very much.

          Tom

0 项奖励
回复