kovalio

эту старую тему нашёл поиском, т.к. тоже озадачился вопросом использования флагов в программе. оказывается, Event Bits (or flags) and Event Groups: Available From FreeRTOS V8.0.0

up! подскажите плиз! DP1205 - передатчик работает (судя по ТВ-тюнеру). Приёмник иногда (намного реже, чем происходит передача) принимает правильный pattern и даже начинает наполнять буфер. Но данные там оказываются совсем не те, что передавались. По сути - случайные числа. В какую сторону копать? Настройки брал из аппноутов со своими корректировками... Кто-нибудь сталкивался?

в общем, впаял новый контроллер на новую плату, проект тот же самый, житаг ice тот же самый, и всё заработало (вроде бы..... тьфу х 3). причины произошедшего мне не совсем понятны :( PS. совместимость с м103 отключена, связь не теряется, проект со всеми настройками и версия ИАРа те же самые. PPS. да, вот ещё вспомнил - когда была эта проблема, то пробовал прошить тестовой программкой мегу64 - так вот, IAR прошивал код, не ругался никак, но в окне Disassembly вместо реального кода были сплошные 0xFFFF и программа соответсвенно не выполнялась (ногами не дрыгала). быть может, просто день неудачный был?

Было работающее устройство на ATmega128 (проработало полгода примерно). Когда вносил правки в исходник (добавлял новые функции) произошло замыкание, сгорела мега, самодельный jtag ice (натурально так горел, с дымом и лопнувшим корпусом на Мега16). Всё перепаял, собрал новый jtag, из архива достал предыдущую версию проекта (которая работала)... При отладке (точнее, ещё при прошивке) ИАР говорит The stack 'CStack' is filled to 100% (2200 bytes used out of 2200). The warning threshold is set to 90%. The stack 'RStack' is filled to 100% (140 bytes used out of 140). The warning threshold is set to 90%. и прога работать соответственно отказывается. в чём проблема? это у меня программный глюк (что имхо маловероятно - проект-то был рабочий) или аппаратный (новая мега/ новый житаг)? подскажите плиз!

угу, не выходит каменный цветок просто думал может есть какая-нибудь прошивка хитрая или ещё что....

у меня miniICE - тот что на базе меги16. да точно, IAR здесь не при чём - мега2560 не поддерживается самим отладчиком :(

Решил попробовать Мегу2560. Иар 4.20А говорит "Target CPU not supported by JTAG driver". скачивать 4.30? или ещё что можно сделать?

а быть может вес лучше мерять через усилие на упругой мембране? тогда можно посмотреть в сторону датчика fss1500 и аналогичных...

спасибо всем, принявшим участие в обсуждении! немного поменял алгоритм (максимально укоротил процедуру обработки прерывания по заднему фронту клока) и главное - поставил кварц побыстрее - и вот под утро всё заработало!!! всё оказалось так просто, что даже обидно - 2 ночи безвылазно просидел - по неопытности наверное :( ЗЫ. я щаслив :D PPS. всё работает точно как было и описано в первых двух ссылках - ничего товарисчи китайцы не меняли в протоколе, как говорится, "внимательно читай мануал"

я из Минска. не думаю, что Вам интересно где у нас их продают :) может в каких-нибудь магазинах.. не знаю. сюда контора прямо из Китая возит. (у нас же блин Китай - стратегический партнёр ) такс... по теме.... могу сказать теперь уже на 90% - это всё-таки бегают данные на выходе штангенциркуля, т.е. там не просто два числа по клоку идут, как было описано у капиталистов на сайте (в приницпе, 150 баксов они не просто так хотят за софт для связи).... а счастье было так близко обманули, похоже... вот считал подряд 1000 бит данных, просто, без синхронизации, проанализировал - да, вроде есть повторяющиеся участки (если кому интересно - см. присоединённый файл)... кстати, у меня ж ещё есть в единственном экземпляре шнурок для подключения этой радости к RS232 - там стоит микросхема со спиленной маркировкой, на ПИК смахивает... на её входе - данные "бегают", на выходе - стабильно. то есть там скорее всего какой-то алгоритм обработки присутствует... вроде есть упоминания некоего протокола Sylvac, но пока конкретно найти не удалось... если кто что знает - подскажите. result.rar

кстати, ещё идея пришла... я всю эту ерунду с синхронизацией затеял чтобы ненароком не попасть началом считывания уже в процесс передачи. но время посылки примерно 800 мкс, а пауза - 300 мс. разница более чем в 500 раз. соответственно и шансы попасть "не туда" 1:500. так может ну к чёрту всё это - просто взять да и тупо без всяких синхронизаций раз 100 прочитать данные по 48 бит, выкинуть лишнее... зато даже этот китайский штангенциркуль внесён в реестр средств измерений и имеет сертификат :) поэтому и взял его. как крепить - дело десятое (немцы на станки их крепят же.... ссылка в первом посте)... основная проблема - всё-таки какой там протокол обмена. если китайцы заложили туда какую-нибудь секретность (чего раньше не было), то я точно ничего не вытащу из этих данных. поэтому и нужен человек, который сам сталкивался....

спасиб за советы, но пока что всё равно не работает (хех, никогда и ничто с первого раза нормально не работает :() меня ещё вот что настораживает... по сути дела программа вклинивается в протокол обмена в случайном месте, а для того чтобы начать приём точно двух предаваемых слов и проводится процедура "синхронизации" - поиска большой паузы между сообщениями. так вот, в случае "неудачного" запроса (когда обратились в момент передачи а не в паузу), снова настраиваемся ловить паузу, и для проверки ввёл переменную troubles - она в итоге показывает, сколько было неверных попыток засинхронизироваться на одну удачную попытку чтения.. так вот, это число почему-то всё время равно 14. счётчик-то обнуляется после удачного чтения, но в следующий раз снова - 14 неудачных попыток, потом проходит чтение.. ИМХО явно что-то не так :( и ещё... на осциллографе данные всё-таки тоже "бегают". ещё есть слабая надежда что это просто последние разряды дёргаются (что вполне терпимо)... а принимаю просто неправильно и поэтому сбоит и в начале и в середине (что совсем неприемлимо)... неужели китайцы всё-таки поменяли протокол... да, и ещё - в ИАРе можно как-нибудь значение переменной сохранить в файл, в буфер обмена? решил пока что без "синхронизации" - просто получить например 1000 значений и вручную посмотреть, поанализировать... ну, получил огромный массив, вроде есть повторяющиеся участки.. распечатать бы, да вот из окошка watch не копируется никуда :( я тут через "Быстрый ответ" дописываю сообщения, а они всё в последнее добавляются. на самом деле это много сообщений :) мысли вслух насчёт алгоритма... подумалось так сделать: берём массив на сотню значений и просто их всех ловим, как перестали идти цифры - пачка кончилась, отсчитываем назад 23 значения и считаем... сейчас буду пробовать. и ещё - удивило, что почти ничего не удалось найти по теме. только вот те 2 ссылки что привёл в первом сообщении... неужели народ не пользуется? может есть какие-нибудь ещё недорогие датчики линейного пермещения, а я просто не знаю и впустую вожусь с этим штангенциркулем?

вот пока не спится (2:31) решил добавить немного инфы: если кратко в двух словах - ловим задний фронт сигнала, пытаемся выловить паузу между посылками (для этого запускаем таймер и по пришедшему переднему фронту смотрим, тикнул таймер или нет... если да - значит дальше можно считывать данные, если нет - снова пытаться поймать паузу)... ну а считываем по задним фронтам тактового сигнала... вроде несложно.... только ловится вот такая ерунда 001111101111110001111001111100001111011111100001 001111011111100001111001111101001111101111110101 101111000000011001111100000000001111000000011101 001111000000010001111000000011001111100000000101 001111100000000101111000000011101111100000000001 001111100000001001111100000000001111000000011001 001111011111100001111001111100101111001111101101 101111000000010101111000000010101111000000011001 001111100000000101111000000010001111000000010101 ... в которой распознать двоичный дополнительный код ну никак не удаётся... то ли лыжи не едут.. то ли руки... а вот и код: #include "ioavr.h" #include "intrinsics.h" #define SCALE_IDLE 1 #define SCALE_SEARCHPAUSE 2 #define SCALE_WAITPAUSE 3 #define SCALE_READDATA 4 #define SCALE_READY 5 unsigned char scale_status = SCALE_IDLE; bool scale_timer_tick = false; unsigned int troubles = 0; unsigned char data[50] = {0x00}; unsigned int i = 0; volatile unsigned char input1 = 0, input2 = 0, input3 = 0; volatile unsigned char tcnt1 = 0; #pragma vector = INT4_vect __interrupt void INT4_ISR(void) { switch (scale_status) { case SCALE_SEARCHPAUSE: //on falling edge { //configuire pin 6 to be sensitive to rising edge of signal EIMSK &= ~(1<<INT4); EICRB |= (1<<ISC41) | (1<<ISC40); EIFR |= (1<<INTF4); EIMSK |= (1<<INT4); TCNT1 = 0; //reset timer counter scale_timer_tick = false; //clear timer flag TCCR1B |= (1<<CS12) | (1<<CS10); //start timer scale_status = SCALE_WAITPAUSE; break; } case SCALE_WAITPAUSE: //on rising edge { if (scale_timer_tick) { //pause found, prepare to read 48 bits data i = 0; scale_status = SCALE_READDATA; } else { //no pause found ++troubles; //test scale_status = SCALE_SEARCHPAUSE; //go back to "SEARCH PAUSE" status } scale_timer_tick = false; //clear flag //configuire pin 6 to be sensitive to falling edge of signal EIMSK &= ~(1<<INT4); EICRB |= (1<<ISC41) | (0<<ISC40); EIFR |= (1<<INTF4); EIMSK |= (1<<INT4); break; } case SCALE_READDATA: //on falling edge { //read data three times to avoid glitches input1 = PINE; __delay_cycles(10); input2 = PINE; __delay_cycles(10); input3 = PINE; if ((input1 & (1<<PINE5)) && (input2 & (1<<PINE5)) && (input3 & (1<<PINE5))) data[i] = 1; else data[i] = 0; ++i; if (i >= 48) { troubles = 0; i = 0; scale_status = SCALE_IDLE; < breakpoint here } break; } } } #pragma vector = TIMER1_COMPA_vect __interrupt void TIMER1_COMPA_ISR(void) { PORTC = 0xFF; tcnt1 = TCNT1; scale_timer_tick = true; //set flag TCCR1B &= ~((1<<CS12) | (1<<CS10)); //stop timer PORTC = 0x00; } void init_pins(void) { //pin6 - PORTE4 - clock, pin7 - PORTE5 - data DDRE &= ~((1<<DDE4) | (1<<DDE5)); //pins 6, 7 are set as inputs PORTE |= ((1<<PORTE4) | (1<<PORTE5)); //enable pull-up resistors at pins 6, 7 //configuire pin 6 to be sensitive to falling edge of signal EIMSK &= ~(1<<INT4); EICRB |= (1<<ISC41) | (0<<ISC40); EIFR |= (1<<INTF4); EIMSK |= (0<<INT4); DDRC = 0xFF; PORTC = 0x00; } void init_scale_timer() { //set timer 1 to 100ms interval TCCR1A = 0x00; TCCR1B = (1<<WGM12) | (0<<CS12) | (0<<CS10); //CTC Timer1 mode, (OCR1A) TCCR1C = 0x00; OCR1A = 1210; //310 ms <============================ depend on system clock! TIMSK |= (1<<OCIE1A); //enable interrupt from system timer TIFR |= (1<<OCF1A); //clear flag } int main (void) { init_pins(); init_scale_timer(); __enable_interrupt(); for (;;) { if (scale_status == SCALE_IDLE) { scale_status = SCALE_SEARCHPAUSE; EIMSK |= (1<<INT4); } __delay_cycles(10000); } return 0; } может свежим взглядом какой косяк заметен?

Здравствуйте! Есть задумка подключить цифровой китайский штангенциркуль к АВРке и сделать некое подобие системы сбора информации о перемещении образца при испытаниях. В Интернете удалось найти зарубежные образцы, описания итд. Например, здесь подробно про протокол обмена: http://www.shumatech.com/support/chinese_scales.htm и здесь http://www.yadro.de/digital-scale/protocol.html вроде бы всё просто, но при реализации столкнулся с кучей проблем (как со стороны "железа" штангенциркуля, так и со стороны своей программы внутри АВРки). Если кто-нибудь уже делал что-то подобное или не лень побеседовать на эту тему - напишите плиз, а то похоже что запутался я немного, помощь нужна... самый пока что основной вопрос - постоянные ли там данные выходят из девайса.... судя по оисанию протокола - там идут два числа - абсолютное положение и относительное.. я же принимаю контроллером полнейшую мешанину из 1 и 0, которые к тому же всё время меняются :(

Также огромная просьба - поделитесь плиз FlashFileSD версии 2.х. Очень надо, на фтп не пускают, в открытом доступе не нашёл. Почтовый ящик на яндекс.ру: kovalev-ns (или в личные сообщения) заранее спасибо!