[Harbinger 10]

Просто так, скорее всего, нет.

Но есть намёк, что из любого "discovery" можно сделать полноценный ST-Link. Пока что недосуг проверить такую гипотезу: по "board ident" определяется, как ему работать: JTAG, SWD, SWIM или всё вместе.

Схемы отладчиков во всех дискавери почти идентичны, в Вашем ките, подозреваю, тоже.

[Alex_Pol 0]

Подскажите, есть ли на STM8 какой нибудь дизассемблер? Думал, можно в STVD, по аналогии с AVR студией, но что то не получается.

[nx6310 0]

Здравствуйте, уважаемые форумчане! Я использую stm8af6288 +STVD+Cosmic. Я включил прерывания по переполнению таймера TIM2. В файле stm8a_lib.с я попадаю почему то в прерывание EXTI_PORTB_IRQHandler вместо TIM2_CAP_COM_IRQHandler. Поменяв местами эти прерывания в файле stm8_interrupt_vector.c все вроде заработало, прерывания по таймеру переходили на функцию TIM2_CAP_COM_IRQHandler. Затем я включил внешнее прерывание по порту В. Теперь при возникновении обоих прерываний я попадаю в функцию TIM2_CAP_COM_IRQHandler. Такое чувство что по всем прерываниям я перехожу в один и тот же адрес обработки прерывания.

Может кто скалкивался с этим? С данным процом работаю недавно, много пока не знаю.

файл D:\projects\stm8_interrupt_vector.c

#include "stm8a_it.h"

extern void @near _stext(); /* startup routine */

void @near (* const _vectab[])() =
{
  
  (void @near (*)())0x8200,
  _stext, /* RESET */
  
  (void @near (*)())0x8200,
  TRAP_IRQHandler, /* TRAP - Software interrupt */
  
  (void @near (*)())0x8200,
  TLI_IRQHandler, /* irq0 - External Top Level interrupt (TLI) */
  
  (void @near (*)())0x8200,
  AWU_IRQHandler, /* irq1 - Auto Wake Up from Halt interrupt */

  (void @near (*)())0x8200,
  CLK_IRQHandler, /* irq2 - Clock Controller interrupt */

  (void @near (*)())0x8200,
  EXTI_PORTA_IRQHandler, /* irq3 - External interrupt 0 (GPIOA) */

  (void @near (*)())0x8200,
  EXTI_PORTB_IRQHandler, /* irq4 - External interrupt 1 (GPIOB) */

  (void @near (*)())0x8200,
  EXTI_PORTC_IRQHandler, /* irq5 - External interrupt 2 (GPIOC) */

  (void @near (*)())0x8200,
  EXTI_PORTD_IRQHandler, /* irq6 - External interrupt 3 (GPIOD) */

  (void @near (*)())0x8200,
  EXTI_PORTE_IRQHandler, /* irq7 - External interrupt 4 (GPIOE) */

  (void @near (*)())0x8200,
  CAN_RX_IRQHandler, /* irq8 - CAN Rx interrupt */

  (void @near (*)())0x8200,
  CAN_TX_IRQHandler, /* irq9 - CAN Tx/ER/SC interrupt */

  (void @near (*)())0x8200,
  SPI_IRQHandler, /* irq10 - SPI End of transfer interrupt */

  (void @near (*)())0x8200,
  TIM1_UPD_OVF_TRG_BRK_IRQHandler, /* irq11 - TIM1 Update/Overflow/Trigger/Break interrupt */

  (void @near (*)())0x8200,
  TIM1_CAP_COM_IRQHandler, /* irq12 - TIM1 Capture/Compare interrupt */

  (void @near (*)())0x8200,
TIM2_UPD_OVF_BRK_IRQHandler, /* irq13 - TIM2 Update/Overflow/Break interrupt  */

  (void @near (*)())0x8200,
  TIM2_CAP_COM_IRQHandler, /* irq14 - TIM2 Capture/Compare interrupt */

  (void @near (*)())0x8200,
  TIM3_UPD_OVF_BRK_IRQHandler, /* irq15 - TIM3 Update/Overflow/Break interrupt */

  (void @near (*)())0x8200,
  TIM3_CAP_COM_IRQHandler, /* irq16 - TIM3 Capture/Compare interrupt */

  (void @near (*)())0x8200,
  LINUART_TX_IRQHandler, /* irq17 - LINUART Tx complete interrupt */

  (void @near (*)())0x8200,
  LINUART_RX_IRQHandler, /* irq18 - LINUART Rx interrupt */

  (void @near (*)())0x8200,
  I2C_IRQHandler, /* irq19 - I2C interrupt */

  (void @near (*)())0x8200,
  USART_TX_IRQHandler, /* irq20 - USART/LINUART1 Tx interrupt */

  (void @near (*)())0x8200,
  USART_RX_IRQHandler, /* irq21 - USART/LINUART1 Rx interrupt */

  (void @near (*)())0x8200,
  ADC_IRQHandler, /* irq22 - ADC1/ADC end of conversion interrupt */

  (void @near (*)())0x8200,
  TIM4_UPD_OVF_IRQHandler, /* irq23 - TIM4 Update/Overflow interrupt */

  (void @near (*)())0x8200,
  EEPROM_EEC_IRQHandler, /* irq24 - FLASH interrupt */


};

 

[Jatagan 0]

Только начал юзать STM8. Перепиливаю с AVR под STM8.

 

Вся проблема в AVR. Вылезла в 2014 году... До этого, а конкретно с 2009 года проблем не было, совсем...

Одно и тоже изделие, штампуется серийно с 2010, а с 2009 год отработал прототип. Выполняет функцию УСО, и по RS485 связана с ПК. Везде гальванразвязка, как с картами расширения, так и в конвертере. Несколько источников питания (сеть питается отдельно, поле отдельно, мало того, 220В подается на промежуточные реле, сухой контакт от отдельного БП через оптроны на МК через резисторы), экранированные кабели, короче, все по взрослому. И все было хорошо и в AVR-ах я души не чаял, считал их идеальными контроллерами, и на то были основания, до 2014 года...

 

Суть проблемы: Периодически перестает работать UART, причем только на передачу, прием проходит, обрабатывается, программа не сбоит, в карты расширение данные забрасывает, но, TxD молчит, как рыба об лед. Помогает только полная перезагрузка. Видимо новым AVR-ам не нравится как гупают пускатели... Причем, контроллеры, которые были куплены до 2014 работают стабильно, годами, в этом же устройстве и в тех же условиях.

 

Просматривая ветку, заметил холивар на предмет AVR против STM8. Улыбнуло, особенно когда обсуждали производительность... А чего она стоит, эта производительность, если железяка не надежна, и боится луюбого чиха... Впрочем, для домашнего применения самое то.

 

Да, кстати, сторожевой таймер на AVR-х так себе, зависает наглухо, пришлось сделать на 555 отдельный супервазер.

 

Схему и печатку пришлось шибко переработать... Усложнив ее... Здорово усложнив...

 

По этой причине перехожу на STM8S. Производитель обещает работоспособность в условиях максимально приближенным к концу света))) Проверим, в ПСУ есть такие условия!

 

Посмотрим, на сколько STM8-ка надежна.

[Eddy_Em 2]

Посмотрим, насколько STM8-ка надежна.

Вполне надежна. Но лучше уж сразу переползать на 32-битные STM32. Скажем, дешевый STM32F030 — отличная замена тем же STM8S003 (цена примерно одинакова), но с кучей плюшек впридачу. Еще советую обратить внимание на STM32F042: у него тактирование CAN и USB разнесено, поэтому это чуть ли не единственный дешевый 32-битный МК, который можно по USB подключить к компьютеру и работать с CAN-шиной.

А учитывая то, что при уникальном или мелкосерийном производстве вопрос цены компонентов обычно вообще не стоит, то можно сразу на STM32F4xx, а то и еще покруче что-нибудь.

 

STM8 же хороши лишь в условиях крупносерийного производства чего-нибудь элементарного (см. ибей со всеми этими термометрами, вольт-амперметрами и прочими штукенциями на STM8S003), когда цена комплектующих уже имеет ценообразующий фактор для всего изделия.

Изменено 17 ноября, 2016 пользователем Эдди

[vladec 12]

Но лучше уж сразу переползать на 32-битные STM32. Скажем, дешевый STM32F030 — отличная замена тем же STM8S003 (цена примерно одинакова)

Тут не все так просто. Помимо цены вопрос плотности кода на классе решаемых задач, то есть затрат программной памяти. На задачах логического программирования восьмибитник будет иметь плотность кода в разы выше тридцатидвухбитника. Если в задаче измериловка с матобработкой, тогда другое дело. А то нашим программистам довелось переводить программу для промконтроллера с Силиконовского восьмибиника (MCS-51) на STM32 (CortecsM4), так объем требуемого флеша увеличился чуть не на порядок

[rudy_b 4]

Пришлось решить несколько задач на Stm8L. В принципе нормальный проц, но в нем очень много баг, в том числе и недокументированных, борьба с которыми занимает массу времени и отнюдь не всегда может закончится победой - очень внимательно читайте errata прежде чем использовать, особенно I2C - его выходы НЕ имеют встроенных резисторов подтяжки. Ну и с распределением ресурсов и ног серьезный напряг. В этом смысле проц серьезно недоделан, и, похоже, брошен "как есть".

 

Но для простых работ с битами и АЦП вполне подходит.

[Eddy_Em 2]

нашим программистам довелось переводить программу для промконтроллера с Силиконовского восьмибиника (MCS-51) на STM32 (CortecsM4), так объем требуемого флеша увеличился чуть не на порядок

Наверняка они вместо человеческого программирования использовали какой-нибудь калокуб. А то еще и на С++ писали. Понятное дело, кода будет толпа.

Если еще и вычисления с плавающей точкой впихнуть вместо фиксированной…

 

Примерно одинаковые вещи на STM8S105 и STM32F103 у меня почти одинаковый объем флеша занимают (правда, на STM32 я для коммуникаций USB использую, а на STM8 по понятным причинам UART через переходник на PL2303).

 

в нем очень много баг, в том числе и недокументированных

Странно. Камень довольно-таки старый, и errata должна быть полной.

Но да: чем старей камень, тем больше в нем всяких недопиленностей. Чего только стоит толщина ерраты на STM32F103... А уж долбанутость с невозможностью установить внутренние подтяжки при работе пина на выход! Ну и I2C: что у STM32F103, что у ранних STM8 интерфейс настолько богат приколами, что errata по этому поводу вполне приличный объем занимает. Благо, при работе в "обычном" режиме сложностей не возникает. Но хотелось бы, конечно, чтобы I2C был так же прозрачен, как, скажем, SPI — чтобы в процессе приема-передачи не надо было вручную регистры дергать!

 

То-то китайцы на STM8, имеющем аппаратный I2C, занимаются ногодрыгом: то ли расшибли себе лоб об errata, то ли тупо скопипастили первое попавшееся решение (второе, кстати, даже более вероятно — видел я код этих самых китайцев…).

[_Pasha 0]

То-то китайцы на STM8, имеющем аппаратный I2C, занимаются ногодрыгом

Так если он меньше занимает места :laughing: то почему бы и нет

[Eddy_Em 2]

Не может I2C ногодрыгом занимать меньше места. Я уж не говорю о диких паузах...

[Andreas1 1]

Не может I2C ногодрыгом занимать меньше места. Я уж не говорю о диких паузах...

C учетом обширной ерраты вполне может. Особенно, если есть обнаружение подвиса шины и ее сброс хотя бы 9 холостыми клоками.