Can we deprecate and remove of built-in CMSIS?!

[eldarkg]

We can delete the built-in CMSIS (dirs CoreSupport) because it is old and have some issues fixed in the current version of CMSIS 5.
In README I can link to newer CoreSupport.
Are any opinions?

[garou-g]

I can't find in CMSIS repo header for core_c.m1.h that are used in MDR1986VE1T.h. So it should be?

[garou-g]

Although they are the same, but headers in CM1 requires core_cm1.h

[eldarkg]

@xgaroux CM0 and CM1 are the same programmatically. If my understand is right we can use instead file core_cm1.h file core_cm0.h. In headers I can to change core_cm1.h to core_cm0.h.

[eldarkg]

Are any other objections?

[garou-g]

No, nothing else from me.

[Amomum]

Well, I recently did a diff between core_cm0.h from CMSIS5 and current core_cm1.h from here. There are some non-trivial differencies in structure layots and field sizes (apart from obvious differencies in whitespace, comments etc).

For example in current core_cm1.h:

 struct
 {
   uint32_t nPRIV:1;                    /*!< bit:      0  Execution privilege in Thread mode */
   uint32_t SPSEL:1;                    /*!< bit:      1  Stack to be used                   */
   uint32_t FPCA:1;                     /*!< bit:      2  FP extension active flag           */
   uint32_t _reserved0:29;              /*!< bit:  3..31  Reserved                           */
 } b;                                   /*!< Structure used for bit  access                  */
 uint32_t w;                            /*!< Type      used for word access                  */
} CONTROL_Type;

In the core_cm0 from CMSIS 5.2.0 (current stable):

  struct
  {
    uint32_t _reserved0:1;               /*!< bit:      0  Reserved */
    uint32_t SPSEL:1;                    /*!< bit:      1  Stack to be used */
    uint32_t _reserved1:30;              /*!< bit:  2..31  Reserved */
  } b;                                   /*!< Structure used for bit  access */
  uint32_t w;                            /*!< Type      used for word access */
} CONTROL_Type;

As far as I know Cortex-M1 is not officially supported by CMSIS because vendors can modify it significantly.
Also we should not forget that officially 1986VE1 is not even Cortex-M1, it's "32-bit RISC" :)

I vote for very carefull examination of differencies between cm0 and cm1 headers; then we can think about it more thoroughly.

I think we can safely remove current CMSIS for Cortex-M3.

[eldarkg]

@Amomum thank u for the info. I'll check this moments.

[Amomum]

I asked milandr support about 1986VE1 core:

а) Является ли "высокопроизводительное RISC-ядро" в 1986ВЕ1Т ядром Cortex-M1 или его "полным функциональным аналогом"?
б) Существуют ли отличия между этим ядром и ядром Cortex-M0?
в) Возможно ли использование библиотеки CMSIS версии 5, в частности, файлов core_cm0.h или core_cm0plus.h при работе с микроконтроллером 1986ВЕ1Т?

а - Ядро Cortex-M1 было разработано для FPGA. 1986ВЕ1Т - не FPGA, поэтому считайте полным функциональным аналогом.
б - Основные характеристики процессора М1 практически совпадают с вариантом M0, но при этом компанией ARM он был реализован только в виде программной модели.
в - Мы такой задачей не знимались, попробуйте. Впринципе core_cm0.h практически совпадает с core_cm1.h, на первый взгляд проблем быть не должно. CMSIS - это впринципе всего лишь текстовые define ресурсов ядра, для читабельности программистом.

So core in 1986VE1 is an analogue of Cortex-M1.

When asked about differencies in core_cm1.h and core_cm0.h:

В сравнение не углублялся.
Вполне возможно что разработчики ядра, с развитием ядра добавляют или убирают какие-то биты. То, что в одной версии было reserved стало чем-то осмысленным. В старых версиях этих битов нет, в новых есть. Поведение кристаллов будет аналогичное.
Используйте те файлы которые поставляем мы. За какие-то иные файлы отвечать не можем, поскольку их развитие не отслеживаем.

So I guess we can keep old core_cm1.h, core_cmFunc.h and core_cmInstr.h just for "Cortex-M1" MCU's. That's not very pretty but it's safe.

[eldarkg]

@Amomum thank you for info

[eldarkg]

In future this files will be deleted.