bugzilla

Выложите, пожалуйста, исходные коды под какой-нибудь свободной лицензией на хостинг вроде Google Code. Этим Вы можете поспособствовать развитию Вашего проекта. А вообще, уже достаточно давно есть http://sourceforge.net/projects/avrdude-gui/

Моё мнение --- ничего плохого в наличии такого раздела нет. Иногда в процессе обсуждения вполне себе тематических тем (уж извините за каламбур), разговор уходит в откровенный офф-топик, вполне полезный, замечу, для всех его участников. Чем прекращать его или, что ещё хуже, вытирать, лучше его перенести в соответствующий раздел. Возможно, если уж люди так боятся наплыва флудеров, имеет смысл запретить создание новых тем в этом разделе, а только переносить туда уже состоявшиеся треды :) З.Ы. Офф-топик --- не уменьшительное от "офф-топ". Вторая часть этого составного слова --- topic --- означает "тема". Отбрасывать "-ик" ни в коем случае нельзя, это ни разу не суффикс, это часть корня!

Никогда не видел ничего лучшего для создания PDF, чем GhostScript. Соответственно, путь такой: * всё что угодно -> ps -> pdf Иногда, впрочем, путь может сокращаться. Для просмотра у меня kpdf и okular. Адобевское поделие не использую из-за тормознутости и привязки к платформе.

Добавлю немного в копилку. Знаю, не самый лучший вариант, писалось на скорую руку, но работает. void check_encoder(void) { static uint8_t state=0; static uint8_t prevstate=0; static uint8_t prevcount=0; static uint8_t laststate=0; register uint8_t temp; temp=(PINA&0x60)<<1; if (temp==prevstate) { if (prevcount<4) { prevcount++; } if (prevcount!=3) { return; } } else { prevcount = 0; prevstate = temp; return; } if (laststate==prevstate) return; laststate=prevstate; switch (prevstate&0xc0) { case 0xc0: { if (state==4) { if (value>VALUEMIN) { value--; } } if (state==5) { if (value<VALUEMAX) { value++; } } state = 1; } break; case 0x00: { if ((state==1) || (state==3)) state++; } break; case 0x40: { if (state==1) state=3; if (state==2) state=5; } break; } } -- WBR, Andrew

Не совсем понимаю, о каких именно переменных идёт речь. Обращение к count повлиять на результат наврядки может, а к captured я обращаюсь тогда уже, когда прерывание запрещено его же обработчиком. Что у меня ещё есть — так это таймер 0, который срабатывает довольно редко, всё, что он делает — устанавливает флажок в 1. Кроме того, обработчик UART, но через UART ничего в данном случае не шло. Измеряемый сигнал может быть довольно коротким, более того, он зависит от ШИМа, выдаваемого как раз таймером 1, соответственно, четыре измерения за раз не сделаешь: 0а. ШИМовский выход выставляется в 1 0б. Срабатывает прерывание от таймера 1, но на входе АЦП ещё ничего нет, соответственно, необходима задержка, реализуемая на таймере 2 1. Срабатывает прерывание от таймера 2, обработчик запускает АЦП (на осциллограмме это видно как тонкий импульс 1->0->1) 2. Когда АЦП что-то намерял, забираем результат и ждём дальше. К сожалению так сделать, скорее всего не получится — для этого надо будет как-то засинхронизировать таймеры 1 и 2, чтобы второе, третье и т.д. прерывания от таймера 2 происходили с периодом таймера 1. У меня ATmega16 на 16МГц, но здесь эти данные не особо важны. Компилятор, очевидно, avr-gcc (hi, aesok!). -- WBR, Andrew

Hello all. Необходимо по прерыванию от таймера #1 запускать через 40µs АЦП, данные накапливать, причём процедура эта должна проводиться 4 раза, результат усредняться. Столкнулся с тем, что иногда выпадают значения. При это последовательность усреднённых результатов выглядит так: 675, 675, 675, 675, 506, 675, 675… Очевидно, что одно из четырёх измерений возвращает 0. Подцепился осциллографом к PB4, обнаружил, что /иногда/ длительность измерения равна 44µs против 68µs. ISR(TIMER1_COMPA_vect) { TCNT2 = -80; TCCR2 = _BV(CS21); PORTB |= _BV(4); TIFR |= _BV(TOV2); TIMSK |= _BV(TOIE2); } ISR(TIMER2_OVF_vect) { TIMSK &= ~(_BV(TOIE2)); set_bit(ADCSRA, ADSC); ADCSRA |= _BV(ADIE)/*|_BV(ADIF)*/; PORTB ^= _BV(4); PORTB ^= _BV(4); TCCR2 = 0; } ISR(ADC_vect) { captured+=ADCW; PORTB &= ~(_BV(4)); ADCSRA &= ~(_BV(ADIE)); (count==3)?(TIMSK &= (~(_BV(OCIE1A)))):0; count++; } static void ioinit(void) { /* ... */ ADMUX=0; ADCSRA = _BV(ADEN)|_BV(ADSC)|_BV(ADIF)|7; /* ... */ set_sleep_mode(SLEEP_MODE_IDLE); /* ... */ } Запускаю измерения следующим образом: count=0; captured=0; TIFR |= _BV(OCF1A); TIMSK |= (_BV(OCIE1A)); while(count<4) { sleep_mode(); }; captured>>=2; Ниже: жёлтый — сигнал с PB4, голубой — измеряемый сигнал. — обычное измерение. — "неправильное" Больше в программе ниоткуда обращения к АЦП не происходят, всё "крутится" исключительно здесь. Куда копать? В крайнем случае, посоветуйте, как правильнее всего отбрасывать эти "промахи"? Заранее спасибо. UPDATE #1: Удалось получить статистику неверных измерений. Здесь точка — нормальное измерение (значение>=10), 1:2 — измерение, вернувшее 1 при count==2. ................................................1:2 ................................................2:3 ...............................................0:3 ................................................1:0 ................................................1:1 ...............................................1:1 ................................................1:2 ................................................1:3 ...............................................1:3 ................................................1:0 ................................................0:1 ...............................................0:1 ................................................1:2 ................................................1:3 ...............................................1:3 ................................................1:0 ................................................0:1 ...............................................0:1 ................................................1:2 ................................................1:3 ...............................................1:3 ................................................1:0 ................................................0:1 ................................................1:2 ................................................1:3 ................................................0:0 ................................................1:1 ................................................1:2 ................................................1:3 ................................................1:0 ................................................1:1 ...............................................3:1 UPDATE #2: Временно решил проблему следующим способом: register volatile int8_t last0 asm("r7"); ISR(ADC_vect) { register uint16_t now=ADCW; register uint8_t now0 = (now < 4); PORTB &= ~(_BV(4)); ADCSRA &= ~(_BV(ADIE)); if (!now0 || last0) { captured += now; (count==3)?(TIMSK &= (~(_BV(OCIE1A)))):0; count++; } last0 = now0; } Но вообще хотелось бы узнать мнение сообщества по поводу причин столь странного поведения. -- WBR, Andrew

4.2 Если *некоторые* недопрограммы под недоОС, написанные недопрограммистами, не умеют пользоваться тем, что есть, это их индивидуальные интимные проблемы. Кроме того, никто не отменял независящие от вендора реализации работы с Unicode. Вещи, которые, насколько я знаю, *невозможно* сделать в 9х, — это юникодные заголовки окон, юникодный ввод с клавиатуры (без использования "кодовых страниц"), юникод в терминале. Всё остальное можно либо реализовать самому, используя имеющееся API, либо положиться на реализацию от кого-либо ещё, а таких немало: MSLU (от вендора), GLib и компания, Qt. -- WBR, Andrew

Как ни странно, в аврах приоритетов гораздо больше, чем 2… Для EEPROM и ADC битовость наоборот более удобна, ибо позволяет производить проверку завершения операции одной командой. -- WBR, Andrew

Пример из книги "Beautiful Code" (O'Reilly), автор кода Henry S. Warren, Jr. Правда, на сях, но не думаю, что сие есть проблема: int pop(uint32_t x) { x = x - ((x >> 1) & 0x55555555); x = (x & 0x33333333) + ((x >> 2) & 0x33333333); x = (x + (x >> 4)) & 0x0F0F0F0F; x = x + (x >> 8); x = x + (x >> 16); return x & 0x0000003F; } Считает биты в 32-битном слове, пользуясь принципом "divide and conquer". Правда, из кода это не очень-то видно. -- WBR, Andrew

GPL-то GPL-ем, но люди хотят, чтобы проектом реально занимались, а не так, чтобы месяц покрутили и забросили. -- WBR, Andrew

Авторы VMLAB сообщают, что готовится к выпуску новая версия VMLAB, в которой будут исправлены некоторые баги со времён последнего релиза. В ответ на вопрос о том, возможно ли открытие исходных кодов, авторы опасаются, что не будет людей, которые будут заниматься разработкой, или же что кто-то "унесёт" исходники: Так что прошу народ высказаться по теме. P.S. Да, я пользуюсь VMLAB'ом. Это один из тех немногих вменяемых симуляторов|отладчиков, которые я когда-либо видел. И я хотел бы, чтобы он развивался. Чтобы фиксились баги. Чтобы он был портабельным, потому как использование его через WINE несколько неудобно. Чтобы он наконец научился понимать формат ELF в его AVR'овской инкарнации. Чтобы много чего нового в нём появилось. -- WBR, Andrew

А он и так не является компилятором C. В C нет возможности писать вещи вроде PORTA.0=1, нет конструкции interrupt[wtf] и ещё много чего. Даже в C99. Поэтому только avr-gcc. -- WBR, Andrew

Можно работать не только в разных потоках, но и в разных процессах при применении некоторой эквилибристики. Естественно, механизмы синхронизации никто не отменял.

Вас кто-то жестоко наколол :-) Билдер написан на Билдере, т.е. VCL. Ну или, что то же самое, на дельфях, точно не смотрел. Но никак не Qt. Не использовать. Ибо среда ущербная by design. Интеграция с Qt сделана просто ужасно глючно, кроме того, платная, поэтому лучше вообще без оной. А если без оной, то есть куча более других вариантов в плане IDE кроме VS. Под win32 есть Dev-Cpp – это из наиболее простых вариантов. Существует QDevelop. Заточен специально под Qt, на нём же и написан. Под более другие ОСи сред навалом.

RGB могут передаваться и параллельно, да. -- WBR, Andrew