jcxz

Счётчики эл.энергии - вообще мимо кассы. В наших например кроме GSM, ещё и RS485, CAN, Ethernet, ZigBee, PLC, RF; возможность одновременной работы по нескольким протоколам; ретрансляция (опрос группы счётчиков через один канал связи с центром); одновременная работа с несколькими центрами сбора/учёта по разным каналам; опрос чужих устройств, по Modbus на RS485; ведение кучи журналов событий; AES; многотарифный учёт; ПКЭ (расчёт показателей качества эл-энергии); всякие анализы токов в нуле (для борьбы с хищениями); удалённое отключение/подключение потребителей по превышениям мощности или потреблённой энергии; и многое-многое другое..... Товарищ просто не знает что такое настоящий счётчик. Он думает счётчик - это то, что у него в щитке на лестничной площадке стоит

Из часов берёте время, преобразуете его в секунды, выделяете текущее смещение относительно начала года, сравниваете с точками перехода, если находится в летнем интервале - прибавляете величину смещения летнего времени. Таким образом - при переходе зима<->лето часы в RTC не модифицируются (readonly). У меня так в наших счётчиках сделано - так служба времени работает. Главная идея - время в RTC-часах - read only, не записывается не при переходе зима<->лето, ни даже при корректировках (корректируется всегда дельта, которая потом прибавляется ко времени считанному из RTC). Так можно безопасно и просто работать с RTC. PS: Имхо - не в тот раздел написали - к IAR эта тема перпендикулярна. PPS: В Незалэжной есть летнее время?

Это справедливо если у вас нет испытаний на помехозащищённость/помехоэмиссию, нет ВЧ-радиочастотных цепей и пр. с чем приходится делать много итераций и переразводок.

Эх! где-то у меня валяются даже ez430-rf2500. Хотя никогда с ними не работал. Работал c CC2480 и CC2530 (ZigBee). А какова цена вопроса?

ТС уже озвучил цену вопроса (см. ниже) Так что не понимаю - чего тут народ так возбудился уже 3-ю страницу подряд?? После первого сообщения уже были ясно, что ТС - ни денег за душой никаких не имеет, ни понятия о профессиональной разработке (это когда с неё люди живут). Простой любитель-теоретик, который и компилятор-то запускает так только, чтобы побаловаться в свободное время. Цель у него - не реализация конкретной задачи - AKA - выпуск реального продукта, а пустое теоретизирование, создание сферического коня в вакууме, никому не нужного. Хотя-бы пару лет работы в реальных проектах лечат этот недуг. :1111493779:

Я работал. Как впрочем и с 1298. Какого рода помощь нужна?

ОС не "сидит постоянно в режиме обработчика прерывания". Cortex-M под ОС находится или в handler- или в thread-mode. И, если это знать, то проблем с Cortex-ядром при перезагрузке быть не должно. У меня рестарт хоть из под ОС хоть без - работает нормально (за исключением вышеописаной проблемы с периферией). Проблемы могут быть только в периферии.

А Вы уверены, что Ваш ISR успевает считать FIFO до прихода след. слова? Если Вы настроили срабатывание при полном заполнении FIFO, то у Вас времени всего - одно слово. Совет - сделайте срабатывание прерывания на половине FIFO. Ну и конечно - по уму в программе должен быть контроль переполнения. Это как-бы по дефолту должно предусматриваться в корректно написанном ПО.

И в Корее студенты не любят делать курсовые, а любят халяву.... :santa2:

Добавлю свои 5 копеек касательно сброса периферии: Только что напоролся на проблему в LPC1758 с UART1 с включённым аппаратным управлением потока (в составе UART1 имеются CTS/RTS). И проявилась она именно при рестарте прошивки обычным переходом на вектор сброса (ну естественно с выполнением всех условий по переключению режимов thread->handler, текущего стека и пр.). А именно: если включено управление потоком (UART1 сам формирует RTS) и FIFO заполнилось до уровня установки RTS-стоп и в этот момент выполнить рестарт, а после рестарта идёт отключение всей периферии с последующим включением и инициализацией, в том числе - сброс FIFO через FCR, то после этого после включения управления потоком опять, RTS остаётся в состоянии "стоп" хотя FIFO пуст. И никакие сбросы UART, отключения его питания в PCONP - не помогают. Не помогает даже снижение FIFO-level до низкого уровня. Единственный способ - отключить временно FlowControl, принять N байт в FIFO до его заполнения до того уровня FIFO, который был ранее и только после этого опять включить - после этого начинает работать. А если сделать аппаратный сброс CPU (например - через WDT), то проблемы не возникает. Похоже в составе UART есть триггер, который устанавливается при превышении заполненности FIFO выше уровня и сбрасывается только при понижении в обратную сторону, а командами очистки FIFO - не сбрасывается. Ещё аналогичная проблема была у меня давно на техасском CC5502 с FIFO DMA-каналов: при программном сбросе, если в этот момент в FIFO были данные (DMA-канал успел выполнить чтение источника, но не успел выполнить запись), DMA-контроллер запрещается, но не сбрасывается. И, при последующем его разрешении, при старте передачи, перед пересылаемыми данными вылазили те застрявшие байты. FIFO DMA-канала программно недоступна и сбросить её нельзя. Так что пришлось при старте ПО, вначале делать одну фиктивную транзакцию (чтобы "продуть" FIFO), и только потом запускать канал в работу.

Сомневаюсь, что таковой существует. Ибо называться он будет: "USB-хост" ;) Не нужен ТСу хост. Как тут уже здраво посоветовали - ему нужно использовать PS/2. Не уверен, но где-то мельком слышал, что клавы "USB"/"PS/2" при втыкании их в один из этих интерфейсов, определяют куда их воткнули и начинают работать по соотв. интерфейсу. Хотя это надо проверить. В любом случае - PS/2 много проще будет и, если автору надо решать практическую задачу, а не чтобы "наработаться", то имеет смысл остановиться на PS/2.

Изучив матчасть Вы как раз и узнаете зачем там он нужен, а у вас - не нужен. Учимся отличать препроцессор от си-компилятора.

Откройте даташит на CPU - там всё это есть. Возьмите библиотеку для работы с GPIO.

Это кто этот дефакто установил? Если у меня есть CPU (с флешем на борту), в нём есть уникальный ID экземпляра. Создаю MAC комбинацией некоей const части (выделенной мне или самозахваченной мной) и другой части, полученной из ID CPU. И где мне тут упёрлась эта дефакто-EEPROM? Не буду. См. выше. Всё это нелегальные варианты и ничего не гарантируют.

Слэши при переносе строк в си не нужны ни в какую сторону. Учите матчасть!

Интересно, чем это проще? 1.VID PID USB - всё на что он влияет, это на работу дров (и конфликты) на конкретном локальном ПК. 2.MAC - в конкретной локальной сети. Как бы сеть подразумевает обычно более чем один ПК (девайс), соответственно, произведя нехитрые математические умозаключения, получаем что вероятность ситуации N2 больше.

Эх, жаль, поздно заметил этот пост! Интересно - хакнул товарищ или не хакнул? Если считать прошивку возможно, и если возможно считать какие-то ключевые данные (не важно где они хранятся - там-же или в другой ИС), то есть шанс решить задачу. Изучить систему команд и архитектуру данного CPU, найти симулятор для оного (или аналог с эмулятором) или даже написать свой. А может даже к этому можно подключиться эмулятором. Ну и пройтись отладчиком по прошивке, разобраться. Даже если ключевые данные зашифрованы с привязкой к уникальному ID чипа, найти место где они дешифруются и анализируются. Но это уже думаю за пределами компетенции типичного хацкера. А отдать профи это сделать - как раз и будет стоить как сама машина. Как минимум ;)

Есть выходы таймеров (впрочем Вам уже посоветовал уважаемый aaarrr). Если их не хватает (или трудно получить с них нужную частоту по каким-то причинам), то есть всякие McASP/McBSP и пр. периферия с источниками периодических сигналов. Причём - это касается всех МК, а DSP - так в большей степени. Даже если не вспоминать о неоптимальности и затратах производительности на такое ISR+GPIO, то можно хотя-бы подумать о джиттере и как он повлияет на работу АЦП? А в DSP прерывания и оптимальная работа алгоритмов цифровой обработки - вещи несовместимые, во многих местах вообще лучше запрещать прерывания надолго. Так что джиттер будет БОЛЬШОЙ. Вот именно - это потому, что ищете в исходниках, а не в мануалах. Для OMAP-L137 достаточно открыть "OMAP-L137 Applications Processor. System Reference Guide" разделы "Device Clocking" и "Phase-Locked Loop Controller (PLLC)" как всё становится предельно понятно - что и откуда. Всё подробно расписано, с разными схемами. Я работал с L137, но для L138 думаю имеется аналогичный документ. PS: Вообще - как только вижу "прерывания, дёргать ногой GPIO", это почти однозначный признак чайника. Ибо сразу видно - незнание работы периферии и нежелание изучать её. Ещё другой характерный признак - нехватка таймеров CPU (и это при том, что их там штук под 10-ок). С большой уверенностью можно сделать прогноз, что всё в "проге" построено на куче прерываний от этих таймеров с ногодрыгом через GPIO внутри. Почему-то я в своих проектах умудряюсь обходиться одним, в редких случаях - двумя таймерами (конечно за исключением тех случаев, когда таймер обеспечивает тактирование какой-то другой периферии, внутренней (типа DMA) или внешней (какие-то чипы через вых. пин таймера)).

Да ну, правда что-ль? ;) Интересно - как тогда пашет тот мой USB-COM, в котором только две bulk-точки? А ведь как-то умудряется на 230400, а местами и на 460800 работать! CP210x А что мешает драйверу периодически (раз в неск. мс) опрашивать эти самые bulk-точки, а в CP210x иметь буфер на несколько размеров bulk-точки? Конечно - если есть интеррапт, то оно вроде как само. Но не надо забывать, что любые транзакции, с любыми типами точек (и даже interrupt и isochronous), инициирует хост-драйвер. Точно также и драйвер конкретного устройства может периодически инициировать транзакции со своими bulk-точками. Ну конечно когда ему выдадут ресурс времени в соответствии с приоритетом.

И что-ж - вы собираетесь именно GPIO дёргать? В прерывании? Если так - вам следует пересмотреть архитектуру системы. Как уже ответили - открыть мануал и читать, читать, читать... И скачивать в первую очередь нужно не примеры, а мануалы на периферию и CPU.

В даташите на WT12 сказано, что его можно сбросить подав сигнал BREAK через UART. Но что-то никак не получается. Пином RESET сбрасывается и командой RESET - тож, а вот BREAK-ом - увы - не реагирует. Уж и 2сек подавал. :((( Кто-нить сталкивался с такой проблемой?

Вот! я же слышал где-то звон, но не помнил где он ;) Как я помню стратегию bulk - она самая низкоприоритетная, но одна точка может занимать весь канал и обеспечивать 100% скорости всей USB-FS при отсутствии передач по другим точкам. 19*64=1216 - как раз полные 100% скорости USB. А фрагментацию должен стек осуществлять. Стек от LPC умеет её делать, и для Control-кадров тоже.

Я уже конечно давно не работал с CDC, но по-моему скорей всего ТС просто не разобрался со своим стеком. Когда я работал с CDC (на стеке LPC и его CPU), никаких таких потерь не было. Вообще. API для юзера там позволяло отправлять и большие блоки (они разбивались внутри стека). Уведомление о завершении передачи от стека (и подкачка новых данных) там было сделано через callback-вызовы. У меня сейчас в комп воткнуты два разных (с разными дровами) USB-COM. В обоих имеется только по два bulk-эндпоинта. Никаких интеррапт. Не уверен, но возможно FS позволяет несколько транзакций с одной bulk-точкой за один 1мс-фрейм. Надо читать описание USB. PS: Нет, сорри - в одном из CDC-устройств имеется одна интеррапт-точка. Но размер её == 2байта с интервалом 1мс. А значит - в ней только какие-то статусы передаются.

Я думаю ТС-у и невдомёк, что Cortex-M3 может опционально выравнивать стек на 8 при выполнении стекинга (при прерывании). А всё потому, что "не читатель, а писатель..." :smile3046:

Часто для этого не обязательно менять CPU, а достаточно оптимизировать ПО....