adnega

Попробывал код из сообщения #8. Все работает и в симуляторе (Keil) и в железе (STM32F103T8U6)!

#include "stm32f10x_map.h" #define RCC_APB1ENR_TIM4EN ((u32)(2)) #define RCC_APB2ENR_IOPAEN ((u32)(2)) #define RCC_APB2ENR_IOPBEN ((u32)(3)) #define RCC_APB2ENR_AFIOEN ((u32)(0)) #define RCC_CFGR_ADCPRE ((u32)(14)) #define RCC_CFGR_PPRE1 ((u32)(8)) #define AF_PP_50 ((u32)(11)) #define CFG_PIN7 ((u32)(28)) #define TIM_CCER_CC1E ((u32)(0)) #define TIM_CCER_CC2E ((u32)(4)) #define OC_MODE_PWM1 ((u32)(6)) #define TIM_CCMR1_OC1M ((u32)(4)) #define TIM_CCMR1_OC2M ((u32)(12)) #define TIM_CR1_CEN ((u32)(0)) #define TIM_CR1_ARPE ((u32)(7)) int main() { RCC->AHBENR=0; RCC->APB1ENR= (1<<RCC_APB1ENR_TIM4EN); RCC->APB2ENR= (1<<RCC_APB2ENR_IOPAEN) |(1<<RCC_APB2ENR_IOPBEN) |(1<<RCC_APB2ENR_AFIOEN); RCC->CFGR= (3<<RCC_CFGR_ADCPRE) |(4<<RCC_CFGR_PPRE1); GPIOB->CRL=(AF_PP_50<<CFG_PIN7); // T4_C2 TIM4->ARR=(12000000/75000)-1; // запись периода TIM4->PSC=0; // запись базы TIM4->CCR1=10; // длительность импульса DIM0 TIM4->CCR2=20; // длительность импульса DIM1 TIM4->CCER= (1<<TIM_CCER_CC1E) |(1<<TIM_CCER_CC2E); // разрешить первый и второй выходы сравнения TIM4->CCMR1= (OC_MODE_PWM1<<TIM_CCMR1_OC1M) // режим ШИМ для первого канала |(OC_MODE_PWM1<<TIM_CCMR1_OC2M); // режим ШИМ для второго канала TIM4->CNT=0; TIM4->CR2=0; TIM4->CR1= (1<<TIM_CR1_CEN) // разрешить счет |(1<<TIM_CR1_ARPE); // разрешить автоматическую перезагрузку while(1); } В Keil даже симулируется... АХТУНГ! А есть ли четвертый таймер у 103T8?

А в регистре RCC_APB2ENR бит AFIO_EN установлен?

А MOXA, например, 3 и 4 любит под RS-485 задействовать: N - 4-wire - 2-wire 1 - TxD+(B) - x 2 - TxD-(A) - x 3 - RxD+(B) - Data+(B) 4 - RxD-(A) - Data-(A) 5 - Gnd - Gnd

Хотелось бы узнать названия.... чтоб "реально не городить"

Можно. Если напряжения на пинах 1-4 относительно пина 5 в диапазоне от 0 до 5 вольт, то RS-485; если плюс/минус 12 вольт, то RS-232. Необходимое подручное средство - вольтметр.

Когда дойдете до тонкстей реализации... будьте аккуратны с библиотеками, предоставляемыми ST. Кому-то они нравятся (типа, можно быстро запустить какой-нить узел; тот же USB)... кто-то разочаровался и пишет код сам, заглядавая в них при необходимости. Можно читать AN, аккуратно. Я же отношусь к этому так: "можно было сделать лучше" / "демки от ST не истина в последней инстанции".

"Имелся ввиду phy-драйвер." В контексте 103 (и других тоже) серии имеем: на лапах PA11 и PA12 есть и CAN (CANRX и CANTX соответственно), и USB (USBDM и USBDP соответственно); Кроме того, есть PB8 и PB9, на которые дополнительно выведены CANRX и CANTX соответственно. Т.е. подключаем USB к PA11-PA12, CAN к PB8-PB9. в регистре AFIO_MAPR поле CAN_REMAP устанавливаем в 2. Все: физики не мешают друг другу! Кста, справедливости ради замечу, что CAN зачем-то можно отремапить на PD0-PD1... на ноги внешнего кварца... т.е. можно запускать системы с CAN на внутреннем генераторе. По-моему, бредовенько )

"В смысле не буде ли драйвер CAN мешать USB?" - конечно будет. Память у них общая... Когда работает USB, CAN будет простаивать. Допустимо ли это для Вашего случая? Судя по вопросу драйвера Вы планируете брать чьи-то. В случае самописных драйверов ситуацию можно разрулить (повторюсь, ценой простоя CAN; с учетом приоритета USB над CAN). На STM32F103T8 делал и CAN, и USB (но не одновременно) - ничего военного. Потом мне захотелось мост CAN<>USB (одновременно)... Переписал на 107 и получился мост CAN<>Ethernet ))

Полусофтовый вариант (на стр. 11 есть соответствующее предупреждение). Если нужен день недели (автоматически рассчитываемый по дате), то лучше делать иначе - в счетчике RTC держать и дату и время (аппаратно). Получать значения при необходимости. Формулы выше.

Есть смысл посмотреть Connectivity Line STM32F105/107 Хотя, можно завести питание с USB на ногу. Если напряжение есть, то активен USB, иначе CAN. CAN физически подключить на отремапленные ноги.

Если на вход какого-то элемента подать сигнал "x", то на выходе получим "X". Если "y", то - "Y". А если подать линейную комбинацию ax+by, где a, b - постоянные коэффициенты, то на выходе линейного элемента получим aX+bY. То, что Вы имели ввиду называется реактивный элемент) Вопрос определений, но мы друг друга поняли. Реактивный элемент позволяет накапливать энергию. Если добавить к типичному ШИМу дроссель, то можно довольно-таки неплохо поддерживать постоянный ток с пульсациями, зависящими от частоты ШИМ и индуктивности дросселя. Такой сигнал уже не страшно гонять по проводам. И яркость получается "честная" (уже интегрированная). Как Вы справедливо заметили, проблемы будут при управлении яркостью нескольких источников. Если автору темы интересно это направление, то можно обсудить детали (как калибровать диммер; повторяемость; стабильность от номиналов, температуры, питающего напряжения). Если же нужно управлять яркостью светодиода на плате (например, для индикации загрузки ядра, канала связи и т.п.), то в дебри можно и не вдаваться.

У понятия "линейный элемент" есть довольно строгое определение. Дроссель - линейный элемент. ШИМ это когда светодиод на полную катушку горит, а потом на полную катушку не горит? Если делать это быстро, то те фотончики, которые успел испустить светодиод разложат химию в нашем глазу не полностью, а частично. И часть эта зависит от времени испускания фотончиков. А от объема разложившейся химии наше восприятие яркости? Мне в этом контексте мыслить? А ничего страшного не случится при использовании типовой схемы и 10 метров провода? Просто, затеял подсветку потолка делать - помех боюсь...

Мучают смутные сомнения, но вряд ли "ток прямо пропрционален заполнению" со всеми вытекающими. Два дня назад экспериментировал со схемой: ШИМ включает NPN-транзистор (схема ОЭ). Эмиттер через 50 Ом на землю. Коллектор через дроссель на светодиод (6 светодиодов). Светодиод через еще 50 Ом на +12В. К коллектору анодом диод. Катодом диод на место соединения светодиода и второго резистора. При прямолинейном заполнении ШИМ, мультик показывает неравномерное изменение тока светодиода (типа, логарифм)! Впрочем, как и осциллограф.

ВАХ светодиода представляем мысленно. В нужном нам участке это как раз логарифм. При линейном увеличении длительности импульса ШИМ линейно увеличивается напряжение. А ток логарифмически. Моща, я так понимаю, будет ~t*exp(t). В некоторой степени яркость прямопропорциональна мощности (если КПД не меняется). Поэтому что-то логарифмическое и получается. По глазу: там где значительный динамический диапазон и сложная система АРУ без логарифмического масштаба не обойтись. Ощущение яркости управляемых светодиодов будет зависеть от яркости фона. Одно дело полумрак, другое прямые солнечные лучи. Сам сейчас озадачен ШИМ регулировкой яркости светодиодов. При малых токах, яркость регилируется ступеньками... При низких напряжениях вообще не горит... Хочу табличку набросать - графически оно всяко удобнее представлять. Потом табличку в софт. Табличка чисто субъективная получится. + Да. Еще ВАХ светодиода (полупроводник в конце концов) прилично зависит от температуры. Это тоже надо учитывать. В начале делал ШИМ-регулировку тока, в принципе и мощность можно посчитать... но хоца ведь по-лехше)

Эээ... походу это я всех смутил. Заветные три буквы фигурировали в коде, который выложил в посте #2. Правильнее будет заменить CRC на CS. Добавлю: опыт показывает, что говорить о CRC-16 без явного указания начального значения, порождающего полинома, и прочих преобразований, иногда не имеет смысла (ибо реализаций CRC-16 много). В соответствующее поле UDP заносится контрольная сумма. Посмотрел у Таненбаума ("Компьютерные сети"): "Контрольная сумма UDP не является обязательной. Если она не подсчитывается, ее значение равно 0 (настоящая нулевая контрольная сумма кодируется всеми единицами). Отключать функцию подсчета контрольной суммы глупо, за исключением одного случая - когда нужна высокая производительность." С http://www.opennet.ru/docs/RUS/tcpip/#c5_udp : "Если поле "Контрольная сумма" UDP-заголовка содержит нулевое значение, это означает, что источник UDP-пакета контрольную сумму не подсчитывал, и приемник выполнять ее проверку не должен. Некоторые реализации протокола UDP (например, в SunOS - клоне ОС UNIX от Sun Microsystems) контрольную сумму не подсчитывают в принципе, полагаясь на возможности контроля целостности данных, реализованные в протоколах сетевого уровня (например, в Ethernet)."

Яркости чего? Светодиода? Лампы накаливания?

Если в поле CRC будет 0, то windows-socket, вроде, примет пакет. Если CRC будет неверна, то пакет отбросится?

#define UDP_PACKET_SIZE 8 #define IP_UDP 17 // псевдозаголовок crc=UDP_PACKET_SIZE+sizeof(sAUDIO_PACKET)+IP_UDP +(((DWORD)dst_ip[0]<<8)|dst_ip[1]) +(((DWORD)dst_ip[2]<<8)|dst_ip[3]) +(((DWORD)src_ip[0]<<8)|src_ip[1]) +(((DWORD)src_ip[2]<<8)|src_ip[3]); // заголовок for(j=0;j<((UDP_PACKET_SIZE+sizeof(sAUDIO_PACKET)+1)>>1);j++) crc+=(bl0_data[j*2+1+ETH_PACKET_SIZE+IP_PACKET_SIZE] +((DWORD)bl0_data[j*2+0+ETH_PACKET_SIZE+IP_PACKET_SIZE]<<8)); crc=(crc+(crc>>16))^0xFFFF; http://www.opennet.ru/docs/RUS/tcpip udp->crc=SWAPBYTES(crc); В поле CRC UDP заносим 0. Сначала считаем сумму псевдозаголвка (тип пакета 17 + размер данных пакета IP (размер заголовка UDP+размер данных UDP)) + IP адреса источника и получателя. Потом к полученной сумме добавляем все данные IP пакета (т.е. заголовок UDP и данные UDP). Затем добавляем переполнение и инвертируем содержимое CRC bl0_data[ETH_PACKET_SIZE+IP_PACKET_SIZE] - начало пакета UDP Можно почитать http://www.opennet.ru/docs/RUS/tcpip/

Или eBOX какой-нить...

MAX3232. На меге8 я делал мониторилку сетевого напряжения с записью на карту. Дык, при скорости 16 байт в секунду все прекрасно работало. Железо-то есть какое под рукой? Могу поделится исходниками для меги8, правда, они на асме.

) Вряд ли он Вам подойдет. Без буферизации 115200 бод при полной нагрузке "ниасились". Готовьтесь к тому, что часть данных от станка может быть потеряна. Кроме этого, у автора статьи очень не хороший подход: "...микросхема MAX232 рассчитана на напряжение питания 5 В, однако, как показала практика, сохраняет работоспособность при 3.3 В...". Даташит на MAX232 регламентирует: напряжение питания 5 Вольт! Будьте бдительны. Желаю скорейшего разочарования (без обид).

Из литературы: Мартин Тревор. Микроконтроллеры ARM7. Семейство LPC2000 компании Philips. В сети легко найти, если что у меня тоже есть (могу на почту кинуть). Прелесть книжки, что она тонкая. Однако есть опечатки, неточности. Контроллер прерываний не тот, который теперь в LPC2478. Читать интересно. Лучше любой книги даташит на конкретный контроллер) Правда, они на английском. Есть "типа перевод даташитов на русский" от Редькина, но его тут крепко ругают) Если нужно срочно, то можно прямо сейчас поставить среду разработки Keil uVision (www.keil.com) - там неплохой симулятор. Поднять консоль, поморгать светодиодом сможете достаточно быстро.

Только не надо думать, что это монстр какой-то. По сути любой МК это ядро и периферия. Периферия на Меге Вас же не пугает. В АРМах даже еще проще - регистры, как правило, 32-битные. Например, для настройки таймера в Меге надо выбрать делитель битиками в регистре (степень двойки, причем не всякая), затем записать младший байт счетчика, после этого старший (или наоборот?). В АРМе пиши 32-битный делитель в один регистр, 32-битный счетчик в другой - все просто. С ядром проблем быть не должно, ибо весь код на C. Помню как запустил первую моргалку светодиода на LPC2148 - радости не было предела. По личному опыту: самое "страшное" в АРМах, это питание 3.3В! Но к нему быстро привыкаешь) При мне три человека так или иначе перешли на АРМ (правда с моим участием). Один аж с PICов)... как говорится "ушел и не вернулся" + Да, и корпуса у АРМов "сложные" - хотя для них платы дома тоже можно сделать

Зачотное объяснение! "Чисто конкретно" согласен на все 100. Интересно, должна ли эта система стоить дорого? Окупаемость возможна? Будет ли доступна подобная система широкому кругу потребителей?