[Kosta 0]

хмм, собирался на "супердешевые" киты с STM32 поглядеть... и призадумался, однако не погонюсь за журавлем в небе а да приступлю к киту на LPC2368 тем более, что он на столе %-). Возможно UART c DMA одновременно мне и не понадобится но MAC ethernet и/или USB с наличием встроенного DAC, как раз подойдут.

 

Имхо лучше не бороться с недостатками в описаниях при том что цель устройства будет замена AVR USB с некоторым потенциалом для расширения, и времени на его реализацию ровно столько, сколько останется от основного проекта. Собственно и к AVR USB претензий никаких, но тащить USB длиннее 5м не дешевле интегрированного Ethernet разъема + ETH PHY, а RS232 тяжко стало найти на непромышленных компах (спасибо Интел :) )

[VslavX 0]

хмм, собирался на "супердешевые" киты с STM32 поглядеть... и призадумался, однако не погонюсь за журавлем в небе а да приступлю к киту на LPC2368 тем более, что он на столе %-). Возможно UART c DMA одновременно мне и не понадобится но MAC ethernet и/или USB с наличием встроенного DAC, как раз подойдут.

А вот Ethernet MAC, судя по документации, у STM32 лучше чем у LPC17 (скорее он ближе по возможностям к новому EMAC LPC18) - он сам может IP/TCP/UDP суммы считать, но практического опыта с EMAC STM32 у меня пока нету. А из LPC лучше уже смотреть на LPC17 - как более новые архитектурно, менее жрущие и более быстрые, мне 17-ые нравятся намного больше чем 21/23/24-ые. По ножкам на 99.9% совместимы с LPC23 - есть вероятность, что можно просто чип в ките заменить, если будет такое желание.

 

[VslavX 0]

Сейчас разбираюсь с Low-Power Modes у STM32F100. Мне надо чтобы устройство спало все время в Stop Mode, просыпалось раз в секунду от RTC, выполняло ряд несложных проверок и снова засыпало. Обнаружены такие факты:

 

- для пробуждения надо дополнительно шаманить с контроллером внешних прерываний EXTI

- выход из Stop Mode по события от RTC _ТОЛЬКО_ по прерыванию/событию ALARM - то есть секундное событие не пробуждает

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

- настраиваются эти регистры несколько тактов LSE (32768) - то есть относительно долго, и проц все это время в Run Mode , то есть жрет энергию

 

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

 

P.S. ИМХО, библиотечка от ST содержит ошибку в RTC_GetCounter() - что будет если 32-битный RT-счетчик тикнет между моментами считывания его 16-разрядных половинок и будет перенос в его старшие 16 разрядов?

 

 

[svl.soft 0]

Контроллеры Kinetis от Freescale пробовали? Рекомендую, STM и NXP курят в стороне. Kinetis и по цене дешевле, характеристики и функционал впечатляет.

[ZiB 0]

Сейчас разбираюсь с Low-Power Modes у STM32F100. Мне надо чтобы устройство спало все время в Stop Mode, просыпалось раз в секунду от RTC

Не подойдет ли пробуждение мк от сторожевого таймера?

[VslavX 0]

Не подойдет ли пробуждение мк от сторожевого таймера?

IWDG пробуждение не поддерживает - только сброс, что не очень хорошо, так как хочется состояние программы и внешних портов сохранять таки. А WWDG он тактируется от PCLK1, значит все время PCLK1 должно быть активно. И уже реализован вариант на RTC_ALARM. Но все равно - спасибо за идею!

 

Контроллеры Kinetis от Freescale пробовали? Рекомендую, STM и NXP курят в стороне. Kinetis и по цене дешевле, характеристики и функционал впечатляет.

Да, кинетиксы впечатляют, но, по моей информации, в младших/средних моделях они не дешевле. По цене К30/40 против STM32F100 не играют.

 

[topkin 0]

Контроллеры Kinetis от Freescale пробовали? Рекомендую, STM и NXP курят в стороне. Kinetis и по цене дешевле, характеристики и функционал впечатляет.

 

Дык Kinetis это Cortex-M4, а тут все же ветка про Cortex-M3.

А что с доступностью? При быстром поиске нескольких позиций в efind ничего толком нет

[aT-DeviLru 0]

Дык Kinetis это Cortex-M4, а тут все же ветка про Cortex-M3.

А что с доступностью? При быстром поиске нескольких позиций в efind ничего толком нет

KWIKSTIK-K40 можно заказать в efo.ru, цена: 52,50$ + доставка 4-5 недели; в elitan.ru тоже есть, но чуть подороже.

Но, имхо, для изучения Cortex-M4 лучше подождать отладочную плату - STM32F4DISCOVERY, во-первых, дешевле и доступнее, во-вторых, есть модуль FPU.

[AHTOXA 14]

- выход из Stop Mode по события от RTC _ТОЛЬКО_ по прерыванию/событию ALARM - то есть секундное событие не пробуждает

...

- настраиваются эти регистры несколько тактов LSE (32768) - то есть относительно долго, и проц все это время в Run Mode , то есть жрет энергию

Разве есть выход из STOP по RTC alarm? Судя по RM0041 (таблица 11), выход из STOP только по прерыванию/событию от EXTI. Кроме того, я не понял, при чём тут LSE (32768), когда

When exiting Stop mode by issuing an interrupt or a wakeup event, the HSI RC oscillator is

selected as system clock.

Это я что-то не так прочитал, или вы открыли недокументированные возможности? (Мне бы просыпание из STOP по аларму RTC очччень бы пригодилось!)

[VslavX 0]

Разве есть выход из STOP по RTC alarm? Судя по RM0041 (таблица 11), выход из STOP только по прерыванию/событию от EXTI.

Правильно - выход по EXTI. Если посмотрите на трассировку входов EXTI, то увидите что EXTI17 подключена именно к RTC ALARM и генерируется по вектору "position 41 at 0x000000E4". А вот секундное прерывание RTC к EXTI не подключено и поэтому по ALARM выходить из стопа можно, а по секундному - нет.

 

Кроме того, я не понял, при чём тут LSE (32768), когда

ИМХО, тут есть два разных тактовых домена - один это тактирование прескайлера и счетчика времени - туда же подвязаны регистры компаратора аларма, и второй домен - это PCLK - тактирование схем доступа с регистрам RTC со стороны периферийной шины. Вот и введена специальная схема синхронизации и настройки регистров. И длится эта настройка, в лучшем случае, два такта частоты тактирования регистров времени, а не PCLK. А тактирование регистров времени осуществляется от LSE (часовой кварц там висит) - с периодом порядка 30мкс. Вот и получается, что работая на 8MГц HSI надо все равно ждать 60мкс, пока регистры аларма синхронизируются и настроятся.

 

Это я что-то не так прочитал, или вы открыли недокументированные возможности? (Мне бы просыпание из STOP по аларму RTC очччень бы пригодилось!)

Все с алармом получилось, просыпается каждую секунду, проц жрет в сумме около 30мкА - но у меня там еще АЦП активизируется/калибруется каждый просып. Так что - нет никаких реальных препятствий (индийская документация, конечно, не фонтан, но ведь у нас форум есть :)) к выходу из стопа по аларму.

[AHTOXA 14]

Так что - нет никаких реальных препятствий ... к выходу из стопа по аларму.

Спасибо за разъяснения, буду пробовать!

[let's see 0]

Добавлю, кое-что от себя. Достаточно близко познакомился с LPC. Посидел пару дней с Atmel SAM3X. STM не трогал. Меня НЕ интересует ни цена, ни скорострельность, ни многое еще чего. Меня интересует целостный дезайн, сопровождение/поддержка разработчика и прочие, тому подобные, мелочи.

Начну с СЭМа. Какое удовольствие я получал от него...целых 2 дня, пока не стал исследовать TWI(I2C). Ну чем они думали??? Все направлено на то, чтобы все было сделано за тебя, даже если тебе это не надо или вообще не устраивает! Пример: NACK от slave вызывае АВТОМАТИЧЕСКИЙ STOP от мастера. Представьте себе настолько умный автомобиль, который сам останавливается на красный свет! Даже если у вас есть веские причины поступить иначе... Короче, я закрыл СЭМа, а жалко.

К LPC у меня масса претензий, ну кроме I2C, классика, как было замечено выше. Таймер только таймер, PWM с ним не выйдет без прерываний, несмотря на то, что есть matching pins. UART и CAN: NXP "изобрел" прерывания по фронту!Привожу заключение моей переписки со службой поддержки

-----Original Message-----

From: [email protected] [mailto:[email protected]] On Behalf Of TS Case email replies

Subject: RE: NXP Semiconductors Case #00013167: THRE Interrupt ref:_00D20NBgb._500D0KUEPm:ref

 

I agree that it is not clear how the interrupt behaves when the UART is first initialized and has no data in the FIFO. I will recommend that it gets updated on the next revision of the document. One advantage to doing this way is that when you initialize the UART you don't immediately get an interrupt for no reason since you know that there is no data in it. Your routine may not need to use the UART immediately so why have an interrupt going off in your system. I could see this being more of an issue then not getting one.

 

The CAN peripherals use buffers and not a FIFO. They indicate whether or not the buffer is available to use. The Transmit interrupt comes up cleared = 0 and the interrupt only occurs when a message is successfully sent and then it gets set = 1. So when you initialize the CAN you will not get an interrupt because you have not sent anything.

 

I cannot say if all the peripherals work this way since we have so many in our devices but as a designer I would not make an interrupt behave such that when it comes out of reset you get an interrupt before you use the peripheral. It would be detrimental to real time systems.

 

Regards

 

Tech Support

 

-----------------------------------------

Quote: " One advantage to doing this way is that when you initialize the UART you don't immediately get an interrupt for no reason since you know that there is no data in it"

Isn't that what masking is for? While I do not need to transmit data I can just mask this interrupt via THRE Interrupt Enable bit in the Interrupt Enable Register.

Quote: " ...as a designer I would not make an interrupt behave such that when it comes out of reset you get an interrupt before you use the peripheral."

Does UART come up after reset with THRE interrupt enabled? If the answer is "YES", " I could see this being more of an issue..."

 

You are actually confirming my scare that CAN TX uses the edge interrupt as well. Sorry to hear that.

Комментарии излишни...

 

Добавлю еще один недостаток: качество кода, примеров, знание принципов программирования, языка С отавляет, мягко говоря, желать...Понятия bit-field, enum NXP незнакомы, количество "magic number" зашкаливает... Простие меня электрики, но это ваш стиль. Другими словами, софтвер НЕПРОФЕССИОНАЛЕН!

Да, и вайла описания битое у NXP нет! У Atmel с этим серьезных проблем не обнаружил.

 

Был бы рад подобной информации о STM и TI...

Спасибо.

[DogPawlowa 0]

UART и CAN: NXP "изобрел" прерывания по фронту!

Я скорее на стороне производителя, есть реалии - не он делает железо под наши программы, а мы пишем программы под его железо.

[let's see 0]

Я скорее на стороне производителя, есть реалии - не он делает железо под наши программы, а мы пишем программы под его железо.

- А Вы сексом заниматься любите?

- Да, конечно! Особенно стоя и в гамаке!

 

 

 

[HHIMERA 0]

Есть и другой вариант...

Скупите вы этот ненавистный NXP... целиком и полностью... и на правах хозяина диктуйте свои правила...

ИМХО... ситуация напоминает "все шагают не в ногу, только товарищ прапорщик"...