GPIO in PEx is so bizarre...

[dave408]

I have GPIO in Atollic with PEx working (bitbanged SPI), using the BitIO component.  However, in KDS+PEx, I don't have that component for some reason.  My non-PEx bitbang SPI code doesn't work, so I decided to use PEx in KDS.

I tried fsl_gpio, but there seems to be a bug where I cannot assign the port.  If I select PORTD, for example, it switches back to PORTA as soon as I click somewhere else.  And of course, since I want two (different) ports, I get an additional error saying that the two components are sharing a port.

So I decided to move on to try the GenericBitIO component in KDS+PEx.  Setup seemed clear enough until I saw this GUI:

I already set the Direction under the Component Name, so I don't understand why I would have to set something in a Direction tab.  In addition, I tried to figure out the significance of PTADD_PTADD0, but I can't find any part of that in the reference manual.  Also, the checkbox should really just be labeled "Output" or "Is output".

I was going to keep moving forward and just ignore this detail regarding direction, but I also can't figure out what the valid port names or bit names are that I should be using.  When PEx uses a droplist with the header and pin number (e.g. J2_12), it's so much easier to configure.  Droplists >> textboxes!

I had BitIO in Atollic+PEx working in 5 minutes.  So far, I've spent over four hours trying to get my IO code working in KDS.  I'm not sure why this is, but I'm going to keep plugging away at it.

[Alice_Yang]

Hello Dave,

1. I saw you said "fsl_gpio" , so please tell me do you use KSDK ?  In other words , when you create project ,have you selected here :

2. Please tell me the version of KDS and KSDK ，and  which chip do you use ?  Then i can quickly repeat your error and find solution.

BR

Alice

[dave408]

Hi Alice, yes, I'm using KDS 2.0 + KSDK 1.1 + PEx, and have two problems:

1. fsl_gpio doesn't take the port that I have assigned to the component -- it reverts to PORTA every time.
2. I don't understand what to set in GenericBitIO.  I entered in port names but they ent up coming up as undefined.  The default is PTAD, which is accepted, but does that mean port A or port D?  For example, is Port B then assigned to PTBD or PTAB?  A droplist would make things a lot less ambiguous, and other components use them for ports, so I imagine it's possible with this component as well.  :smileyhappy:

I'm doing everything on a FRDM-K64F development board, so it's the MK64FN1M0VLL12.

Thanks!

[Alice_Yang]

Hello Dave,

I have some doubts. Please see my screenshot :

this is my fsl_gpio component, we can select port in "Device" , and on my side , there is no GenericBitIO component , could you please screenshot yours , like this :

[dave408]

Alice, here's a video of the bug in action.

[vfilip]

Hi,

the Device item in fsl_gpio component should not be visible and it is really confusing (switch to old inspector should resolve it). Please note that fsl_gpio can handle pins from multiple ports. It is recommended to have one gpio component in project. However you should be able to have more components in projects. If this is not allowed in 1.1 we can provide hot-fix if needed.

rgds

Vojtech Filip

[dave408]

Alice, I can select the Port just fine.  But like I said earlier, when I click somewhere else and come back to the the Device selection, it changes back to PORTA.

Here is my screenshot:

[vfilip]

Hello,

the Device item should not be visible. It is problem in PEx for KSDK 1.1.0 (already fixed in PEx for KSDK 1.2.0). As workaround please ignore it or switch to old inspector view (details attached).

We are sorry for inconvenience.

rgds

Vojtech Filip

[dave408]

Hi Filip, back to my problems with fsl_gpio -- I am probably doing something really dumb, but I cannot get fsl_gpio to set any digital outputs.  Here is what my configuration looks like in PEx:

I thought that maybe I had to set the pin directions manually, despite the PEx settings, but I just confirmed by stepping through GPIO_DRV_Init and seeing it configure the directions for the one input (MISO) and the seven outputs (MOSI, MCK, CS, and four MUX bits).

But when I step over GPIO_DRV_SetPinOutput( mux0), where mux0 is an output bit, the corresponding pin J1.11 on the FRDM-K64F does not go high.

Can you suggest anything for me to check?

[Jorge_Gonzalez]

Dave:

Set the "Open Drain" setting to disabled in all the pins, unless you have external pull-ups.

[dave408]

Oh man, how did I miss that...  thank you.

[dave408]

Yong, disabling tabs view definitely made it easier to figure out how to get fsl_gpio to work.  However, it looks like I cannot have two fsl_gpio components in my project, even though they use different ports.  My "mux" fsl_gpio component uses PORTC, and my "spi" fsl_gpio component uses PORTD.  If I have only one enabled at a time, PEx can generate code.

However, if I have both enabled, I get a PEx error popup when I try to generate code.  It tells me to look in the Problems window for more details.  Then the Problems window tells me to check the Component Inspector for errors.  When I go to the Component Inspector, there are *no* errors.  However, the Components window shows red Xs on each of the fsl_gpio components, but no additional error information.  So I can't figure out how to get both working, and thought that maybe this is a limitation in PEx and I can't used more than one at a time...  ???

[Jorge_Gonzalez · Accepted solution]

Hello Dave:

I posted a video about using fsl_gpio component in the next link: Video Link : 3195

Apart from the video I would like to clarify some points with you:

- As colleague Filip mentioned, in the fsl_gpio component the device selection (PORTA, PORTB, ...) is not relevant, since the component allows you to allocate any pins from any ports as inputs/outputs.

- You only need one fsl_gpio component, just add all of your required pins to the input and output configurations. In the video I use PORTC for the input button and PORTB for the LEDs, but I could have also added the green LED (which belongs to PORTE) without any extra component.

- I think the GenericBitIO is a custom Processor Expert component created by colleague Erich Styger, right? So we cannot help much with that one.

- If you do not feel comfortable with KSDK yet and would prefer to use the BitIO or BitIO_LDD component, just from the New Project Wizard uncheck the "Kinetis SDK" option. BitIO is part of the legacy Processor Expert components, which will not be available anymore for new Kinetis devices, but for K64 you can still use them. The next is a discussion about this: Re: How do I merge PEx components from PEx DriverSuite into KDS/SDK?

I hope this helps with your confusion.

Regards!

Jorge Gonzalez

[dave408]

Jorge, thanks for the clarification.  I'll watch the video.

I'll remove the extra fsl_gpio component.  I don't really need a hotfix for this, I just need to know what the constraints are on components, and now it's crystal clear for me and fsl_gpio.

Thanks for bringing up that point about GenericBitIO.  The problem was that I had started playing with KDS last year and apparently I must have installed Erich's component when I was learning about PEx (from his blog, actually).  So that makes sense now!

I started with KSDK, but after spending too much time trying to get things like C++ and certain components working (that aren't yet working in KSDK 1.1), I have decided to try working with PEx only and avoiding KSDK, if I can.  However, at the moment I'm just learning how to use each peripheral one at a time, in separate projects.  I don't know yet if putting everything together in the end is going to have an issue that can only be resolved by using KSDK.

Perhaps you can tell me if this list of requirements will be an issue for non-KSDK projects?

• Project 1, ideally MQX but could be BM
  • Target processor: K22F, possibly K02F instead
  • GPIO
  • PWM with FTM 0 & 3
  • QD with FTM 1 & 2
  • SPI
  • I2C
  • UART
• Project 2 has all of the above peripherals, in addition to:
  • Target processor: K64F
  • Ethernet
  • MQX

Does this all look reasonable?  I have to avoid as many bugs as possible, and it seems like KSDK isn't quite ready yet.

Thank you for your help!

[Jorge_Gonzalez]

Hello Dave:

fsl_xxx components are used to configure KSDK static drivers, so you are really not "avoiding" KSDK. To avoid KSDK uncheck "Kinetis SDK" from the New Project Wizard as I mentioned.

About your scenarios, I think you can get around with the available Pre-SDK software enablement, since K22F and K64F are supported by both: legacy Processor Expert components and classic MQX, but at some point you may want to migrate to KSDK. For K02 I am not quite sure though.

Regards!

Jorge Gonzalez

[dave408]

Ok, thanks.  I had forgotten that all of the MQX work I have done thus far is using MQX for KSDK, and not the separate MQX 4.1.1 installation.

From that post you linked previously, it sounds like I won't be able to use KSDK to get MQX integration and still use the legacy PEx components.  So in this case, I suppose I will need to either use whatever PEx components that are functional along with my own peripheral coding (like what I have had to do for QD support), or I need to punt on KSDK completely and use the separate MQX 4.1.1 installation along with the legacy PEx components.

Does it sound like I'm understanding everything correctly now?  :smileyhappy:  Thank you *so* very much for your detailed answers, and most of all, patience.

[Jorge_Gonzalez]

Correct, you understand the concepts better now Dave. The problem is that you got caught in a Kinetis enablement tools transition, for the best we hope, but this has caused a certain amount of confusion. We understand that, sorry for the troubles.

In any case we are here to help and make the learning curve easier and smoother :smileyhappy:.

Regards!

Jorge Gonzalez

[dave408]

Thanks, I will give disabling Tabs view a try!