quarter2

Вопрос к разработчикам scmRTOS: 1. почему исходники не содержат __watchdog_reset() хотя бы через #define ? каждый раз после апдейта приходится практически во всех файлах после while и for вставлять __watchdog_reset() 2. было бы неплохо внести дополнения в описание класса process: template<TPriority pr, size_t stack_size, size_t rstack_size> class process : public TBaseProcess { public: INLINE_PROCESS_CTOR process(); int StackFree() { word Free = 0; for(;;) { // stack always has non-0xAB items. if( Stack[Free] != 0xAB ) return Free; ++Free; } } int StackUsed() { return stack_size - StackFree(); } OS_PROCESS static void exec(); private: stack_item_t Stack [stack_size/sizeof(stack_item_t)]; stack_item_t RStack[rstack_size/sizeof(stack_item_t)]; }; template<TPriority pr, uint16_t stack_size, uint16_t rstack_size> process<pr, stack_size, rstack_size>::process() : TBaseProcess( &Stack[stack_size/sizeof(stack_item_t)] , &RStack[rstack_size/sizeof(stack_item_t)] , pr , reinterpret_cast<void (*)()>(exec) #if scmRTOS_DEBUG_ENABLE == 1 , Stack , RStack #endif ) { stack_item_t *pDst = Stack; word Size = StackPointer - Stack; while(Size) { *pDst++ = 0xAB; --Size; } } т.к. StackUsed() и StackFree() очень сильно помогают при отладке

На IAR EWAVR только что откомпилил простенькую программку с записью в ЕЕПРОМ, при это файл eeprom.s90 в проект не включал. В дебаг-режиме увидел, что линкер точно подставляет в выходной код строки из C:\Program Files\IAR Systems\Embedded Workbench 5.5\avr\src\lib\eeprom.s90 Нет, в прерываниях __eprom-переменные не использую. При этом ЕЕПРОМ случайным образом, то пишется правильно, то с ошибками. Если включаю в проект файл eeprom.s90, в котором отключаются прерывания - данные в ЕЕПРОМ пишутся абсолютно правильно.

Про пример из даташита - согласен. В примере как раз прерывания отключаются на время запуска процесса записи в ЕЕПРОМ. Но в файле eeprom.s90 как раз прерывания отключаются на время окончания записи в ЕЕПРОМ: ;---------------------------------------------------------- ; ?eewait ; ; Wait for previous eeprom write operation to complete ; ; SIZE: 6 bytes RSEG CODE:CODE:NOROOT(1) ?eewait: CLI SBIS EECR,EEWE ; Loop until previous write is completed RET OUT SREG,T0 RJMP ?eewait Неправильно. Все переменные, которые объявлены ключевым словом __eeprom при компиляции для работы с областью памяти ЕЕПРОМ используют файл eeprom.s90 Если бы не наступал на эти грабли - не поднимал бы вопрос. Без запрещения прерываний на время окончания записи есть вероятность некорректной записи данных в область ЕЕПРОМ

The following example shows how this can be used to avoid interrupts during the timed EEPROM write sequence /* disable interrupts during timed sequence */ __disable_interrupt(); EECR |= (1<<EEMWE); /* start EEPROM write */ EECR |= (1<<EEWE); SREG = cSREG; /* restore SREG value (I-bit) */ Есть ни что иное, как запрещение прерываний на время окончания записи в ЕЕПРОМ Время записи в ЕЕПРОМ в Atmega128 согласно тому же даташиту: Table 2. EEPROM Programming Time EEPROM Write (from CPU) = 8.5 ms В IAR EWAVR 5.50 в файле eeprom.s90 нет запрещений прерываний на время ожидания окончания записи в ЕЕПРОМ

проблема есть реально, если на время записи в еепром не запрещать прерывание - данные могут записаться некорректно. после того как начал использовать вышеприведённый файл - проблема устранилась. вот здесь этот вопрос обсуждается http://electronix.ru/forum/lofiversion/index.php/t16140.html http://electronix.ru/forum/index.php?showt...amp;#entry71028 Вот пример записи в еепром из даташита на Atmega128: Assembly Code Example in r16, SREG ; store SREG value cli ; disable interrupts during timed sequence sbi EECR, EEMWE ; start EEPROM write sbi EECR, EEWE out SREG, r16 ; restore SREG value (I-bit) C Code Example char cSREG; cSREG = SREG; /* store SREG value */ /* disable interrupts during timed sequence */ __disable_interrupt(); EECR |= (1<<EEMWE); /* start EEPROM write */ EECR |= (1<<EEWE); SREG = cSREG; /* restore SREG value (I-bit) */

Может быть вопрос немного не в тему, но не хочется создавать товый топик. Как scmRTOS относится к записи данных в EEPROM? Ведь для корректной записи в EEPROM необходимо отключать прерывания на несколько милисекунд. Я использую специально для этих целей файл eeprom.s90 Не окажет ли это влияние на работу операционки? eeprom.rar

Всем доброго времени суток! Кто-нибудь запускал scmRTOS на XMEGA ? У меня без проблем scmRTOS работает на atmega128. Хочу развести плату под atXmega256, но нет уверенности, что scmRTOS сможет работать на этом кристале. Пробую свои проекты с scmRTOS (работающие на atmega128) откомпилировать (IAR EWAVR 5.50) под Xmega256. Пока что результаты отрицательные.

МК (TX) ... резистор ... стабилитрон 3,3В на корпус ... SIM300D (RX) А вот это я упустил. Инициализировал УАРТ до появления единицы на СТАТУСе. Обязательно учту на будущее. Но всё равно остаётся опасение, что опять произойдёт что-то с этим модулем, когда его будет пользователь юзать. ОЧЕНЬ большие опасения. встроенную зарядку SIMа я не использую, т.к. очень много нареканий вычитал об этой функции в СИМ300 Ещё я с PWRKEY не совсем корректно работал (подключал его напрямую к микроконтроллеру Atmega128L) Мне подсказали, что желательно через транзистор подключать PWRKEY к модулю (как в рекомендациях: транзистор в схеме с открытым коллектором).

Я уже и через транзистор пробовал согласно SIM300C_AN_REFSCH.pdf и на "землю" PWRKEY садил напрямую - результат один: модуль исправно (с первого раза) запускается только при питании SIM300 не выше чем 3,6В (до этого на 4 вольтах стартовал всегда с первого раза в течении месяца). И такая ситуация уже с пятым модулем повторяется: месц отработал и впадает в ступор. Перепрошивка версией 1008B14SIM300D32_SST34HF3284.bif ситуацию не исправляет.

1. Процессор запитан 3,3В 2. PWRKEY подключен напрямую к микроконтроллеру Atmega128L.

У меня уже 5-й модуль (SIM300D) подряд обнаруживает проблемы с запуском. А именно: модуль собран согласно рекомендациям SIM300C_AN_REFSCH.pdf, питается от стабилизатора LM2576ADJ напряжением 4В. Через месяц нормальной работы модуля он вдруг начинает запускаться сигналом PWRKEY раза с 10-20. Потом вообще отказывается запускаться. Повторюсь это уже пятый модуль показывает такое поведение. Теперь модуль можно запустить только дёрнув PWRKEY на пониженном питании 3,6В - модуль запустится с первого раза. Далее я поднимаю напряжение до 4В для устойчивой работы модема. До следующего перезапуска модем работает просто идеально. Модули постоянно берём в Гамме в Киеве. С модулями SIM300C таких казусов обнаружено небыло.

К методике В.Якименко добавлю одно уточнение. at+cipccon=2 OK Передаем данные at+cipsend > text for file 12345 SEND OK ТЕПЕРЬ (ОБЯЗАТЕЛЬНО!!!) НУЖНО ЗАКРЫТЬ СОЕДИНЕНИЕ: AT+CIPCLOSE и только после этого давать команду at+cipccon=1 OK Ещё одни грабли, на которые я наступил: если по команде at+cifsr вы не получили адреса типа: 88.214.93.220, а что-то вроде 10.34.34.65 т.е. начинающиеся с 10 - значит ваш GSM-оператор не способен для СИМ300 обеспечить серверное соединение (только клиентское, т.е. вы можете подсоединиться к кому-то, а к вам никто не сможет) В этом случае нужно менять оператора. Я так и сделал. Теперь работаю с FTP-сервером без проблем.

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

Что удивительного в том, что модуль нужно выключить? В SIM300DZ, если POWERKEY уже припаян, то его уже от земли не отделить, а устройство уже спаяно не в одном экземпляре. Просто спрашиваю: как в моём случае корректно выключить модуль? PWRKEY-ем я не дёргал. POWERKEY на земле, просто выключал питающее напряжение. Само собой модуль слетел. При этом месяц проработал. Сейчас пытаюсь модуль выключать командой AT+CPOWD=1, но он просто перезапускается. Вчера после перепрошивки целый вечер работал нормально (с командой AT+CPOWD=1). Сегодня утром перестал запускаться, пока не перепрошил очередной раз и не понизил питание до 3.62В. Сейчас ещё пока работает. Версия софта: 1008B12SIM300D32_SST34HF3284 прошил: 1008B14SIM300D32_SST34HF3284.bif

Нужно микроконтроллером выключить корректно модуль, а то уже замахался его перепрошивать И ещё ... Модуль на 3.78В работал в течении месяца исправно. После перепрошивки включился, но постоянно рестартовал после регистрации в сети. Поднял до 3.92В - вообще не запускался. Сейчас стабильно работает на 3.62В и выше не разрешает поднимать - сразу начинает рестартовать. Может лыжи не едут или ... ?

У меня модуль SIM300DZ S2-1019B-F000A. Поверкей на земле. Месяц модуль работал как часы, а 3 дня назад начал включаться только на 10-20 раз (STATUS не поднимал и всё). С помощью SIM FUT V1.10.exe и прошивки 1008B14SIM300D32_SST34HF3284.bif перепрошил модуль, но у меня так же при выключении модуля коммандой (AT+CPOWD) пропадает статус и модуль через пару секунд снова врубается. И мне почему-то не до смеха.

В качестве ТСР-сервера я использую программу Hercules. Получается, что "пинговать" нужно не только со стороны устройства (с периодичностью не более минуты), но и со стороны сервера? Я думаю, что это тоже не даст гарантии, что сервер мобильного оператора не отрубит связь с моим сервером. В Европе такого поведения мобильные операторы себе не позволяют. Но у нас - это норма.

Согласен. Модем отвечает: STATUS: CONNECT OK - это значит, что между модемом и сервером провайдера соединение есть (здесь на модем грешить нельзя), а вот то, что между сервером провайдера и моим связь обрывается - нужно передать большой привет нашему КИЕВСТАРУ. При переподключении они за предыдущее подключение округлят использованный трафик до 20КБт и за новое подключение ещё срубят денежку. МОЛОДЦЫ! Р.S. После установления связи я отсылаю на сервер один байт каждую минуту - при этом картина с затыком в передаче данных остаётся прежней.

Нет. Передатчика нет. Есть на борту только GPS-приёмник. Правда уровень сигнала на модеме СИМ300 довольно низкий (AT+CSQ 7,0). Но подобный глюк нельзя объяснить низким уровнем входного сигнала (IMHO). Может кто встречался с таким поведением модема и знает почему может возникать такая ситуация?

После установления GPRS-связи на модеме СИМ300Д - с сервером идёт нормальная передача данных как с сервера, так и с модема. Объёмы данных небольшие (десятки байт в 3-4 минуты как с одной так и с другой стороны). Каждые 15 секунд я даю команду: AT+CIPSTATUS. Модем отвечает: STATUS: CONNECT OK В один прекрасный момент передача данных прекращается: модем не может ни принять данные от сервера ни отослать. При этом на запрос AT+CIPSTATUS он исправно отвечает каждые 15 секунд: STATUS: CONNECT OK Усложняю задачу - вообще выключаю сервер. Модему всё равно - он продолжает отвечать, что STATUS: CONNECT OK на все АТ команды он исправно отвечат - т.е. он не завис. Это не единичный опыт (т.е. не случайный результат). Ответы типа: у Вас глючный модем рассмотрю как новогоднюю шутку. :) Кто-нибудь сталкивался с такой проблемой?

Proteus не может корректно работать с командой sleep. При выполнении программы: доходит до команды sleep (при этом работает таймер 0 на прерывание по сравнению) и из этой команды уже не выходит. Даже после того как сработал таймер 0 (появился флаг о сравнении содержимого таймера с установленным числом) - proteus из sleep не выходит. В AVR-studio эта же прошивка работает без проблем. В проекте использована Atmega128.

Всем привет! Решил подключить к компу устройство с контроллером ISP1581 посредством стандартных классов USB устройств (Ethernet Networking Control Model), а точнее USB-Ethernet. Т.е. чтобы комп "видел" моё устройство как Ethernet карту и соответственно работал с ним через специальные драйвера этого класса. Стандартная поставка Windows не включает в себя такие драйвера. Если и есть такие драйвера, то только под законченные девайсы (например Кавасаки-контроллеры). Кто-нибудь сталкивался с такой задачей? Где можно найти такие драйвера и описание к ним? Или хотя бы описание протокола конкретных драйверов?