[jcxz 184]

Порой выгоднее воткнуть в довесок к основному толстому процу какой-нить М0+.

Т.е. - взять LPC43xx? Это да...

И решение той задачи мы потом переделали взяв более жирный многоядерный проц. Ибо на LPC1758 хоть и успевало, но работало на пределе и больше почти ничего проц не успевал делать.

Но на тот момент задача стояла так: железо было уже сделано без меня (на LPC1758 + ПЛИС + CY7C68013A), был инвестор с кешем, и надо было ему показать рабочее железо, пускай выполняющее только часть функций. Так что - или сделать на том что есть, или потерять проект вообще. А через годик мы поменяли элементную базу на другой проц и всё B)

[Reflector 0]

Не понял Вашу мысль....

В чём проблема-то? Что именно нельзя сделать? Если не нужно знать предыдущее состояние какого-то пина на порту, но состояние всех остальных можно установить в нужное одной операцией записи. Каким бы сложным ни был генератор.

void SetPins(uint value)

{

BSRR = (value & 255) | (~value << 16);

}

Да, похоже ты прав, при таком подходе можно сделать и инверсию... но это не бесплатно. Для начала нужно код доработать:

BSRR = value | ((~value & 255) << 16);

Смотрим что нагенерит компилятор. Один вызов:

0x2000084c  ldr r3, [sp, #4] 
0x2000084e  ldr r2, [pc, #96]
0x20000850  orr.w r3, r3, #16711680
0x20000854  str r3, [r2, #24] 
0x20000856  ldr r3, [sp, #4] 
0x20000858  orr.w r3, r3, #16711680
0x2000085c  str r3, [r2, #24]

Два вызова подряд:

0x2000084c  ldr r1, [sp, #4] 
0x2000084e  ldr r2, [pc, #108]    
0x20000850  mvns r3, r1 
0x20000852  lsls r3, r3, #16 
0x20000854  and.w r3, r3, #16711680
0x20000858  orrs r3, r1 
0x2000085a  str r3, [r2, #24] 
0x2000085c  ldr r1, [sp, #4] 
0x2000085e  mvns r3, r1 
0x20000860  lsls r3, r3, #16 
0x20000862  and.w r3, r3, #16711680    
0x20000866  orrs r3, r1 
0x20000868  str r3, [r2, #24]

Я же предлагал такой код:

static void write(uint32_t data) { base()->BSRR = (pinsMask << 16) | data; }

Тут очищаются все биты сразу, по константной маске, ее не нужно инвертировать, обрезать и сдвигать, а если было бы нужно, то она так константой бы и осталась.

Один вызов:

0x2000084c  ldr r3, [sp, #4] 
0x2000084e  ldr r2, [pc, #88]
0x20000850  orr.w r3, r3, #16711680
0x20000854  str r3, [r2, #24]

Два вызова подряд:

0x2000084c  ldr r2, [sp, #4] 
0x2000084e  ldr r1, [pc, #92]
0x20000850  mvns r3, r2 
0x20000852  lsls r3, r3, #16 
0x20000854  and.w r3, r3, #16711680
0x20000858  orrs r3, r2 
0x2000085a  str r3, [r1, #24]

 

Update: Претензия снимается, специально объявил записываемую переменную как volatile, чтобы компилятор ее не рассматривал как константу, то в твоем коде она читается 2 раза и ественно компилятор это продублировал :) Разница есть, но она всего 4 байта :)

Изменено 21 апреля, 2017 пользователем Reflector

[Forger 17]

Т.е. - взять LPC43xx?

Типа того, но по отдельности порой выходит даже дешевле, да и выбор ничем не ограничем.

 

Но LPC4300 уже устарел, уже есть более злобные: http://www.microchip.com/wwwproducts/en/ATSAM4C16

[jcxz 184]

Да, похоже ты прав, при таком подходе можно сделать и инверсию...

Инверсию за одну операцию на STM ни при каком подходе сделать нельзя.

Мой код не инвертирует, а устанавливает значение всех пинов за одну операцию записи для любого числа. Инверсии там нет.

[Reflector 0]

Инверсию за одну операцию на STM ни при каком подходе сделать нельзя.

Имеется в виду, что в таком случае инверсию в принципе возможно сделать оставив и атомарную запись, пусть и немного более медленную. В данный момент железо это не поддерживает, но все может измениться в будущем.

 

[jcxz 184]

Типа того, но по отдельности порой выходит даже дешевле, да и выбор ничем не ограничем.

Одно ПО разрабатывать/сопровождать/обновлять проще и дешевле. В этом плане многоядерный проц лучше нескольких одноядерных.

Я, когда писал прошивку для LPC1758 + параллельно для CY7C68013A, это почувствовал на себе. И документации читать больше и в отладке сложнее. А уж когда оказалось, что прошивку и того и другого надо ещё у заказчика обновить.... :smile3009:

[Forger 17]

Одно ПО разрабатывать/сопровождать/обновлять проще и дешевле. В этом плане многоядерный проц лучше нескольких одноядерных.

Я, когда писал прошивку для LPC1758 + параллельно для CY7C68013A, это почувствовал на себе. И документации читать больше и в отладке сложнее. А уж когда оказалось, что прошивку и того и другого надо ещё у заказчика

Как обычно, все сводится к деньгам, поэтому нужно считать, что выгоднее - использовать один толстый мудрёный проц или два обычных. Главное, что есть выбор ))

[jcxz 184]

Но LPC4300 уже устарел, уже есть более злобные: http://www.microchip.com/wwwproducts/en/ATSAM4C16

По сравнению с этим - не устарел.

LPC4370 (который у меня был) - 3 ядра на 204МГц: M4F + M0*2.

Здесь же только 2 ядра, пускай и M4 (но одно ядро - просто M4 без F как я понял), но на 120МГц.

Это ещё посмотреть кто быстрее будет ;)

Да и ОЗУ в LPC4370 побольше почти в 2 раза - 282кБ. Правда флеши нет :laughing:

 

Итого: 120*2=240МГц против 204*3=612МГц B)

А уж про АЦП LPC-ки я вообще молчу ;)

 

PS: Да, кстати - для второго ядра ещё и частота не указана. Может она в 2 раза ниже?

[Forger 17]

По сравнению с этим - не устарел.

LPC4370 (который у меня был) - 3 ядра на 204МГц: M4F + M0*2.

Гы, я не знал про такие :laughing:

Похоже, семейство это развивают во всю ))

[razrab83 17]

любезно заряженное ружье спрятанное разработчиками spl от st ожидает тебя
 

/**
  ******************************************************************************
  * @file    stm8l15x_gpio.c
  * @author  MCD Application Team
  * @version V1.6.1
*/

typedef enum {RESET = 0, SET = !RESET} BitStatus;

/**
  * @brief  Reads the specified GPIO input data pin.
  * @param  GPIOx : Select the GPIO peripheral number (x = A to I).
  * @param  GPIO_Pin : Specifies the pin number.
  *           This parameter can be one of the following values:
  *            @arg GPIO_Pin_0: Pin 0
  *            @arg GPIO_Pin_1: Pin 1
  *            @arg GPIO_Pin_2: Pin 2
  *            @arg GPIO_Pin_3: Pin 3
  *            @arg GPIO_Pin_4: Pin 4
  *            @arg GPIO_Pin_5: Pin 5
  *            @arg GPIO_Pin_6: Pin 6
  *            @arg GPIO_Pin_7: Pin 7
  * @retval BitStatus : GPIO input pin status.
  */
BitStatus GPIO_ReadInputDataBit(GPIO_TypeDef* GPIOx, GPIO_Pin_TypeDef GPIO_Pin)
{
  return ((BitStatus)(GPIOx->IDR & (uint8_t)GPIO_Pin));
}

 

[jcxz 184]

3 часа назад, razrab83 сказал:

любезно заряженное ружье спрятанное разработчиками spl от st ожидает тебя

И с каких пор у нас STM8 стал == STM32? Или вы не ощущаете разницы между ними?

[juvf 10]

1 час назад, jcxz сказал:

И с каких пор у нас STM8 стал == STM32? Или вы не ощущаете разницы между ними?

это вы их приравниваете. Я задавал вопрос о spl от st. И тема тут прежде всего об этом, которая также затронула и HAL, и LL, и снипеты, и в том числе были упомянуты stm8 и прочие процессоры.

 

5 часов назад, razrab83 сказал:

разработчиками spl от st ожидает тебя ...

+1

[jcxz 184]

1 минуту назад, juvf сказал:

это вы их приравниваете. Я задавал вопрос о spl от st. И тема тут прежде всего об этом, которая также затронула и HAL, и LL, и снипеты, и в том числе были упомянуты stm8 и прочие процессоры.

И я их не приравниваю. Не надо передёргивать. И внимательнее прочитайте мой пост и пост, который я комментировал, и подумайте о каком процессоре идёт в нём речь и о чём тема и раздел форума.

 

[juvf 10]

14 минут назад, jcxz сказал:

И внимательнее прочитайте мой пост и пост, который я комментировал, и подумайте о каком процессоре идёт в нём речь и о чём тема и раздел форума.

Я вижу в посте разраб83 о стм8, я вижу в посте разраб83 о spl от st. Я не вижу в посте разраб83 что стм8 == стм32.

А чуть выше я вижу посты с LPC4370, с stm8,  LPC1758, XMC4700, ATMega.... но я не вижу (и ни кто не заметил), что упоминание об этих процессорах, это тоже самое, что приравнивание к stm32.

в сообщении разраб83 я вижу как продолжение дискуссии об библиотеках от st (и не только от st).

 

ps

В 21.04.2017 в 16:39, jcxz сказал:

LPC4370 (который у меня был) - 3 ядра на 204МГц: M4F + M0*2.

  внимательнее прочитайте мой пост и пост, который я комментировал, и подумайте о каком процессоре идёт в нём речь и о чём тема и раздел форума.