KSDK_1.1.0中DSPI存在严重bug，坑人的玩意

LuoHG

利用MAPS开发板弄一个GUI设计，用Kinetis做GUI设计真的很纠结，NXP和STM都用上了高大上的emWin了，一真梦想FSL咋时候让卡粉们也能用上emWin呢，难道非逼着我转道MDK用其emWin不成，MDK的文件分层做得很不到位这点很无耐，而FSL把自家的eGUI开源之后貌似攻城狮们都不太感冒，论坛反响极少，连杜娘都把egui YY 成"鳄龟",。我也看了很久的eGUI doc，不可否认的是它虽然很强大，但程序设计相当的复杂，要真使用还得先缓一缓，得先弄点简单的下手才行，于是就盯上了板上的SPI LCM，它的FlexBus LCD先留着后期跑ucGUI，要用SPI LCM，必须使用DSPI模块啊，然后上参照Kinetis SDK v1.1 API Reference Manual中的9.3 DSPI Master Driver配置SPI2，然后用阻塞式发送，结果调用阻塞发送系统就跑飞到“HardFault_Handler    B .”去了，阻塞发送时要是单步调试则可以正常执行，看V1.1里的demo就偏偏没有DSPI的例程，MAPS的例程是初始化用DRV层，发送直接调用寄存器操作了，看来MAPS也是拿SDK一点办法都木有，对明显的缺陷也只能避而不谈，那个例程虽然能点亮LCM，但离真正应用于产品那差距大了去了，字库还要转换到显存，而不是字库与显示一一对应，把字库按显存要求转换后，应用程序直接将字库送到显存显示那才是效率啊。吐槽了这么多，主要表示用户使用这FSL的SDK真的亚力山大啊，被坑了一回又一回，海燕呐，你可长点心吧，啥时候才能让用户用得更省点心啊，学一学STMcube，SDK做得好，拥趸无限多，听说人家的Cortex-M7评估板也上市了，不得不佩服真是速度啊。直接上代码，看看FAE大神们是否能给点解决之道。

#include "fsl_dspi_hal.h"
#include "fsl_dspi_master_driver.h"


#define SPI_COM_MAX_NUM     2

typedef enum _SpiComNoDef
{
  kSpiComLcm = 0,
  kSpiComFlash,
} SpiComNo_t;


static const uint8_t ucMasterInstance[SPI_COM_MAX_NUM] = {HW_SPI2, HW_SPI2};

/*< Configure the members of the user config. */
static const dspi_master_user_config_t xMasterCfg[SPI_COM_MAX_NUM] =
{
  {
    .whichCtar = kDspiCtar0,
    .isSckContinuous = false,
    .isChipSelectContinuous = false,
    .whichPcs = kDspiPcs1,
    .pcsPolarity = kDspiPcs_ActiveLow,
  },

  {
    .whichCtar = kDspiCtar0,
    .isSckContinuous = false,
    .isChipSelectContinuous = false,
    .whichPcs = kDspiPcs0,
    .pcsPolarity = kDspiPcs_ActiveLow,
  }
};

static const dspi_device_t xSpiMasterDev[SPI_COM_MAX_NUM] =
{
  {
    .bitsPerSec = 1000000,
    .dataBusConfig.bitsPerFrame = 8,
    .dataBusConfig.clkPolarity  = kDspiClockPolarity_ActiveHigh,
    .dataBusConfig.clkPhase     = kDspiClockPhase_FirstEdge,
    .dataBusConfig.direction    = kDspiMsbFirst,
  },

  {
    .bitsPerSec = 1000000,
    .dataBusConfig.bitsPerFrame = 8,
    .dataBusConfig.clkPolarity  = kDspiClockPolarity_ActiveHigh,
    .dataBusConfig.clkPhase     = kDspiClockPhase_FirstEdge,
    .dataBusConfig.direction    = kDspiMsbFirst,
  }
};

static dspi_master_state_t xMasterState[SPI_COM_MAX_NUM];


void vPinMuxSpiConfig(uint32_t ulInstance)
{
    switch(ulInstance)
    {
      case HW_SPI2:                       /* SPI2 */
        /* Enable the clock for SPI module */
        CLOCK_SYS_EnableSpiClock(HW_SPI2);
        /* Affects PORTD_PCR11 register */
        PORT_HAL_SetMuxMode(PORTD_BASE, 11u, kPortMuxAlt2);     // SPI2_PCS0
        /* Affects PORTD_PCR12 register */
        PORT_HAL_SetMuxMode(PORTD_BASE, 12u, kPortMuxAlt2);     // SPI2_SCK
        /* Affects PORTD_PCR13 register */
        PORT_HAL_SetMuxMode(PORTD_BASE, 13u, kPortMuxAlt2);     // SPI2_SOUT
        /* Affects PORTD_PCR14 register */
        PORT_HAL_SetMuxMode(PORTD_BASE, 14u, kPortMuxAlt2);     // SPI2_SIN
        /* Affects PORTD_PCR15 register */
        PORT_HAL_SetMuxMode(PORTD_BASE, 15u, kPortMuxAlt2);     // SPI2_PCS1
        break;
    default:
        break;
    }
}


void vSpiComInit(void)
{
    uint8_t ucComIdx;
    uint32_t ulInstance;
    uint32_t ulDelayInNanoSec;
    uint32_t ulCalculateDelay;
    uint32_t ulCalculateBaudRate;
    dspi_status_t xSpiStatus;

    ucComIdx = 0;
    while (ucComIdx < SPI_COM_MAX_NUM)
    {
        ulInstance = ucMasterInstance[ucComIdx];

        /*< SPI pin configure. */
        vPinMuxSpiConfig(ulInstance);

        /*< Init the DSPI module. */
        xSpiStatus = DSPI_DRV_MasterInit(ulInstance, &xMasterState[ucComIdx], \
                                         &xMasterCfg[ucComIdx]);
        if (kStatus_DSPI_Success != xSpiStatus)
            while (true) {}

        /*< Configure the SPI bus. */
        xSpiStatus = DSPI_DRV_MasterConfigureBus(ulInstance, &xSpiMasterDev[ucComIdx], \
                                                 &ulCalculateBaudRate);
        if (kStatus_DSPI_Success != xSpiStatus)
            while (true) {}

        /*< PCS to SCK Delay option. */
        ulDelayInNanoSec = 200;
        xSpiStatus = DSPI_DRV_MasterSetDelay(ulInstance, kDspiPcsToSck, \
                                             ulDelayInNanoSec, &ulCalculateDelay);
        if (kStatus_DSPI_Success != xSpiStatus)
            while (true) {}

        ++ucComIdx;
    }

    uint8_t ucSpiTxBuffer[4] = {0x01, 0x02, 0x03, 0x04};
    uint8_t ucSpiRxBuffer[4] = {0x01, 0x02, 0x03, 0x04};
    iSpiComExchangeData(kSpiComLcm, ucSpiTxBuffer, ucSpiRxBuffer, 4);   // 调试时用F10必死无疑，用F11一步步深入可正常，FSL能不能这样坑人啊
}


int16_t iSpiComExchangeData(uint8_t ucComNo, uint8_t *pucSnd, uint8_t *pucRcv, uint16_t uiLen)
{
    dspi_status_t xSpiStatus;

    if ( (NULL == pucSnd) || (NULL == pucRcv) )
        return API_INVALID;

    if ( (ucComNo >= SPI_COM_MAX_NUM) || (0 == uiLen) )
        return API_FAIL;

    xSpiStatus = DSPI_DRV_MasterTransferBlocking(ucMasterInstance[ucComNo],  \
                                                 &xSpiMasterDev[ucComNo],    \
                                                 pucSnd, pucRcv, uiLen, 1000);

    if (kStatus_DSPI_Success != xSpiStatus)
        return false;
    else
        return true;
}

阅读全文

jinyi7016

还有这问题啊？

LuoHG

jinyi7016 发表于 2015-8-11 21:29
还有这问题啊？

是啊，用FSL的SDK竟然会有这样莫名其妙的bug，下了个V1.2试试，杯具的是V1.2完全不兼容V1.1，比如V1.1是这样定义HW_GPIOA，而V1.2竟然不可思议的改成了GPIO_IDX，我看HW比IDX具有实际含义，还有一些回调函数名称全给改了，例如HwTimerIsrCallback_t改为hwtimer_callback_t，这叫攻城狮情何以堪啊，难道再来个名称大变更就成了V1.3了？

pyheben

LuoHG 发表于 2015-8-12 09:01
是啊，用FSL的SDK竟然会有这样莫名其妙的bug，下了个V1.2试试，杯具的是V1.2完全不兼容V1.1，比如V1.1是 ...

表示赞同KSDK的确不是很好用。

cxtarm

LuoHG 发表于 2015-8-12 09:01
是啊，用FSL的SDK竟然会有这样莫名其妙的bug，下了个V1.2试试，杯具的是V1.2完全不兼容V1.1，比如V1.1是 ...

还有这种事啊

LuoHG

pyheben 发表于 2015-8-12 10:07
表示赞同KSDK的确不是很好用。

用FSL的SDK开发真是一把鼻涕一把汗啊，FSL的芯片功能极其强悍，但SDK却是个拖后腿的玩意。

LuoHG

cxtarm 发表于 2015-8-12 10:17
还有这种事啊

用用就知道了，现在还在折腾着把程序升级与V1.2同步，各种error，泪奔中啊

FSL_TICS_ZJJ

LuoHG 发表于 2015-8-12 10:26
用用就知道了，现在还在折腾着把程序升级与V1.2同步，各种error，泪奔中啊 ...

你可以直接在KSDK1.2版本的SPI例程中移植你的相关代码。
KSDK1.2中有driver_example，这里面有关于SPI模块的代码。

LuoHG

FSL_TICS_ZJJ 发表于 2015-8-13 09:29
你可以直接在KSDK1.2版本的SPI例程中移植你的相关代码。
KSDK1.2中有driver_example，这里面有关于SPI模 ...

我的其它模块都是按照V1.1的驱动来设计了，移植到V1.2那可不是一般的费劲啊，各种不兼容，连中断回调函数注册机制都给取消了，真的很费劲，不想越陷越深已经放弃了。
用STM多简单啊，整个产品线都是兼容的，把stm32f4xx.h改为stm32f7xx.h, stm32f4xx_hal.h改为stm32f7xx_hal.h，然后一切都OK了，我不想当KSDK的小白鼠了，我只能在煎熬中慢慢等到它稳定时再用了，估计得等到V2.0才敢用。

_烟酒僧_

看来真是有bug