Xenia

Прежде чем "писать софт" надо разбираться в деле. Ведь не приходит же в голову кому-попало писать программу по бухучету, если он ни бельмеса не смыслит в бухгалтерии? Между тем электроэнцефалография - сложнейшая область медицины (я бы даже сказала - биофизики), которая на порядки сложнее бухгалтерии. Разве что только компьютерная томография ее сложнее. И отнюдь не только к получению частотного спектра сигнала сводятся задачи ЭЭГ. Большая часть этих задач связана с многомерным корреляционным анализом, посредством которого строится пространственная карта электрической активности мозга. А эта задача отнюдь не для реального времени. Не говоря уже о том, что сама по себе требует сложных и порой продолжительных расчетов, несмотря на нынешнее высокое быстродействие компьютеров. А большинство алгоритмов представляют собой ноу-хау, над которым работали десятилетиями. Замах автора топика подобен желанию папы Карло вырезать из полена скрипку и сыграть на ней как Паганини :). Или желанию умельца дяди Васи построить из консервных банок космический корабль и слетать на нем на Марс :). При этом первый никогда не учился музыке, а второй никогда не учился рассчитывать космические трактории. Современный же электроэнцифалограф (тот самый, что стоит 100 тыс . евро) скорее похож на космический корабль, чем на транзисторный приемник в мыльнице. Между тем, как ничто не мешает заниматься авиамоделизмом или в музыкальном кружке, точно так же можно строить и самодельные ЭЭГ. При этом четко отдавая себе отчет, что твое творение - любительское. Что до Марса оно не долетит и с настоящим космическим кораблем соперничать не сможет. И если подходить к делу релистично, но самодельный ЭЭГ- вещь достаточно полезная. Только полезная в том случае, когда есть конкретный интерес к делу, а не ставится задача воспроизвести промышленный прибор с целью сэкономить деньги. Все это я пишу потому, что ... сама строила домашний ЭЭГ и была среди энтузиастов проекта OpenEEG (впрочем я и сейчас себя считаю его энтузиасткой :)). Да, этот проект явно любительский. А матерые электронщики даже посмеются над теми конструкциями, что там предлагаются. Например, ЭЭГ на 8 отведений, построенный на ... ATmega8 :) (используется АЦП, встроенный в этот МК). Все это по сравнению с промышленным ЭЭГ выглядит, как детекторный приемник по отношению с радиокомбайну от Sony. Но если ваша задача достаточно конкретна (т.е. когда цель не в том, чтобы агрегат построить, а в том, для чего он вам нужен), то и любительская конструкция вполне может сослужить вам хорошую службу. Скажем, если вам нужно радио для того, чтобы послушать последние новости или прогноз погоды, то и самый простенький самодельный радиоприемник решит вашу задачу в отсутствие радиокомбайна от Sony. Меня же на ЭЭГ потянула задача регистрации ИСС (Изменённое Состояние Сознания), а потому мне хватило и одного отведения, а для связи с компьютером - обычного RS232. И тут действительно вполне можно было бы обойтись вычислением амплитуд каждого из ритмов (альфа, бета и т.д.), хотя я пошла другим путем. Но и этого своего ЭЭГ-любительства мне за глаза хватило, чтобы осознать грандиозность настоящего промышленного ЭЭГ. Конечно современного типа, а не 10-15 летней давности, которого можно приобрести на барахолке среди списанного медицинского оборудования. P.S. На мой взгляд, самая большая сложность в ЭЭГ состоит в банальнейшей вещи - борьбе с вездесущей сетевой наводкой 50 Гц, подавить которую далеко не просто, учитывая близость к ней частот биоритмов мозга.

ADS1298 для этой цели лучше подойдет. Матлаб не годится для систем реального времени - он слишком медлителен для такого большого объема работы. Вот если бы у вас было 8, а не 256 отведений, то это еще куда не шло. На компе. Боюсь, вы не поспеете записывать эти данные на диск, даже если вам удастся их быстро передать в компьютер. Про расчеты в реальном времени тут и речи быть не может. Разве что некоторые из каналов при большом прореживании успеете показывать на экране монитора, чтобы оператор не скучал. Все расчеты делаются в off-time, когда данные доступны в записи. Вы что же, и программу такую рассчитываете сами написать? :) У меня такое мнение, что вы не отдаете себя отчет в том, за что беретесь. Вам этого не сделать никогда! :) Это только делетантам кажется, что ЭЭГ это просто. Скажите, а где собираете добывать электроды? Сами сделаете? Не смешите!

_Bill, похоже на то, что ваш алгоритм даст неправильный ответ, если обе строки изначально тождественны. При этом, когда flash-строка дойдет до своего нуля, rеsult обнулится (сработает условие !*pp), отбросив этот вариант, как не являющийся совпадением - а это неправильно.

А вы патчи к нему прикладывали? http://supp.iar.com/Updates/?product=EWSTM8

Знаю два варианта решения вашей проблемы: 1) Завести себе в ОЗУ "мусорную" строку, которая будет использоваться сразу под множество целей. Тогда не "OK" там постоянно будет лежать, а разные вещи, по мере надобности. Или скажем sprintf() на эту строку будет работать. Или чтобы какие-то сообщения там формировать. Короче говоря, создаете себе буфер на вывод, а используете его не всегда по назначению, но и для ОЗУвления ПЗУшных констант :). 2) Более элегантный метод, в котором необходимое для дела место в ОЗУ временно занимается у стека. Для этого создайте блок и заводите в нем место для временной строки: c8 __flash *OKin = "OK"; ............. main() { ............. { // открываем блок char ozu[3]; // создаем локальный массив на стеке, принадлежащий ОЗУ strcpy_P( ozu, OKin); // копируем строковую константу из ПЗУ в ОЗУ result = strstr( str_buff, ozu); // выполняем функцию strstr() полностью на ОЗУшных аргументах } // закрываем блок, в результате чего локальный массив ozu[] исчезнет, вернув свою память стеку ............ }

При таком заполнении flоat-переменной union { float fVal; unsigned char bytes[4]; } value; value.bytes[0] = data[4]; value.bytes[1] = data[3]; value.bytes[2] = data[6]; value.bytes[3] = data[5]; может оказаться, что вы записали в него "нечисло". Т.к. далеко не любая комбинация битов является валидным значением float. А бедняга printf начинает конверировать инвалидное число в десятичное и сходит с ума :). Мой совет: ... потренируйтесь на нулях :)

Ну вот опять Atmel у вас оказался виноват :) Это проблема не столь аппаратная, сколько логическая. Указанная проблема будет возникать во всех случая, когда числовой адрес памяти не уникален. Т.е. тогда, когда существует более одного адресных пространств, в которых имеется своя собственная нумерация. При этом числового значения указателя оказывается недостаточно для того, чтобы однозначно определить, к какого рода памяти он относится. Очевидно, совершенно та же самая проблема возникнет, если вместо указателя на flash-память использовать указатель на eeprom-память. В этом случае функция strstr() тоже откажется работать правильно. Точнее говоря, она-то отработает правильно, только символы возьмет не из той памяти, которую хотелось бы. А гарвардская архитетура тут только при том, что во многих своих реализациях допускает наличие двух адресных пространств (памяти программ и памяти данных), которые допускают перекрытие по номерам ячеек. Но если оба вида памяти разместить в одном адресном пространстве без перекрытия, то указанная проблема исчезнет. Как, например, не возникает такая проблема у компьютеров IBM PC, у которых в младших адресах расположено ПЗУ, а выше его ОЗУ. Однако в тех случаях, когда команды обращения к ОЗУ и ПЗУ разные, указанная проблема встает в полный рост. И тут разделением адресов горю не поможешь. Хочешь, не хочешь, а код функций, работающих с разными видами памяти, окажется тоже разным. Поэтому сишным переопределением типа указателей проблема не решается. А гарвардская архитектура становится виноватой :) в тот самый момент, как только у процессора появляются РАЗНЫЕ команды обращения к ОЗУ и к ПЗУ. В тех же случаях, когда между этими обращениями нет разницы, подобная проблема не возникает.

Функция strstr() работает только на нормальной памяти (RAM), но не на flash. А уж тем более не может работать, когда один аргумент во flash, а другой в RAM. Таковы уж издержки гарвардской архитектуры. Поэтому обман этой функции с помощью переименования типов указателей у вас не пройдет. Функция не заработает, поскольку на такую ситуацию она не рассчитана. Поэтому скопируйте лучше flash в RAM, например, с помощью функции strcpy_P(), а потом уже запускайте strstr() на полностью RAM-строках. Хотя слово "ОК" настолько коротко, что проще его завести сразу в RAM, потери будут минимальными.

Нельзя ли поточнее указать ссылочку? А то не нашла я кипижа. Эта информация уже с бородой. С тех пор, как начался выпуск ATmega48A/ATmega88A/ATmega168A, производство МК без постфикса "А" прекращено. Тоже произошло со многими другими типами, например с ATtiny2313, которую тоже заменили на ATtiny2313A.

Вчера вышел новый сервис-пак к EWSTM8 №3 (№2 пропущен - не существует) - SP-EWSTM8-1103.exe http://supp.iar.com/Updates/?product=EWSTM8 Модифицирует версию до 1.10.3. Выложила на FTP в ту же папку, где лежит инсталлятор. Что там конкретно исправили, написано крайне невразумительно: "corrects a number of problems in the 1.10.0 release", а когда читаешь релиз-нотес http://supp.iar.com/FilesPublic/UPDINFO/00..._notes.ENU.html , то и там непонятно, заменили компилятор или нет. Не плохо бы это проверить тем, кто тут на компиляцию жаловался.

А откеда у вас студия AVR32 Studio 2.6? На сайте последняя из раздающихся - 2.5.

Если это IAR C/C++ компилятор, то не надо - компилятор сам вставит необходимый код, а если это IAR ассемблер, то надо вставлять вручную.

AVR32UC3С будет содержать Ethernet или нет? Недавно вышел подробный анонс AVR32 UC3 microcontrollers ( http://atmel.com/dyn/resources/prod_documents/doc7919.pdf ) И хоть это уже релиз G (а внутри написано H), он примечателен тем, что открыл подробности будущей серии AVR32UC3С (с буковкой C на конце) Смотрю на табличку "Product Selector Guide" (на стр. 15) и вижу у серии UC3C среди периферии Ethernet/MAC. Читаю описание серии на странице 14 - никакого Ethernet'а нет и в помине: The AVR UC3 C Series is designed for industrial and automotive control applications, including high-speed communication and motor control. The devices feature single or dual CAN interfaces, a full speed USB with OTG, NAND flash and SDRAM interface, PWM with dead-time insertion, two 1.5 MSPS 12-bit ADC with 16 channels and dual sample-and-hold circuitry for synchronized sampling of 2 signals, two 1.5 12-bit analog DAC with dual outputs. Designed with the multi-layered AVR32 databus, 68 KB on-chip SRAM with triple high-speed interfaces, and multichannel Peripheral and memory to memory DMA controller, the AT32UC3C offers outstanding data throughput. The AT32UC3C Peripheral Event System provides a connection between on-chip peripherals to off-load the CPU, reduces power consumption and provides a deterministic response to external and internal events. В прошлом релизе ( http://www.ebv.com/fileadmin/products/Prod...32_Brochure.pdf ) Ethernet/MAC был только у серии A (UC3A), а у других серий его не было. А вот сейчас Ethernet появился в табличке и у серии C (UC3C). Это опечатка или решение компании добавить Ethernet в промышленный МК?

"Отметить все сообщения прочитанными" тоже не удается - всё остается как было.

Причины очевидны. В эпоху капитализма торговцы имеют приоритет над электронщиками :). Электронщики - кто такие? - Инженеры. А торговцы - Предприниматели! Купцы, одним словом. В одном месте по-дешевле купил, а в другом по-дороже продал - вот тебе и навар. А электронику при этом и можно вовсе не знать :). А тут какой-то инженеришка вздумал карикатуры на предпринимателей выставлять. К ногтю его! :)

Всё гораздо проще. Стринги в языке C по определению заканчиваются нулем, который сам за символ не считается (нуль-терминированная строка). Отсюда следует очевидное следствие - строка символов не может содержать нуля, а буде такой в строку ставлен, то это привело бы лишь к тому, что строка стала бы короче, будучи обрезанной по первому же встреченному нулю. То же касается функции strlen(), определяющей длину стринга. Она возвращает не число сиволов, которые вы туда понатыкали, а число ненулевых символов, начиная с нуля. Поэтому конструкция: WriteFile(COMport, bufwr, strlen(bufwr), &temp, &overlappedwr); так же оказывается завязана на функцию strlen(), поскольку именно она вычисляет число передаваемых байт. Отсюда и ваша ошибка. Исправлять положение следует явным указанием числа передаваемых байт. Элегантным способом реализации которого может быть вариант создания специальной функции, помещающей байт в буфер, вместо механического копирования. Такая функция добавляла бы байт, одновременно инкрементируя счетчик. Этот же счетчик впоследствии использовался бы при сбросе буфера на вывод, после которого счетчик обнулялся. Например так: // глобальные переменные: char bufwr[1024]; int counter = 0; void PushBuffer( char symbol) { bufwr[counter++] = symbol; } При желании эту функцию можно объявить inline, тем самым превратив ее в прямую подстановку. А обнуление counter вставить в WriteThread() после успешного завершения передачи. А саму передачу производить так: WriteFile(COMport, bufwr, counter, &temp, &overlappedwr); Соответственно этому, пихать байты в буфер следует не так: for(unsigned char icd=0;icd<10;icd++){bufwr[icd]=comand[icd]; а вот так: for(unsigned char icd=0;icd<10;icd++) PushBuffer(comand[icd]);

Господин Клейн! Почему бы вам не выложить ваш архив на местный FTP, благо вы имеете к нему доступ? Если ваш ответ отрицательный, то спрошу, как вы отнесетесь к тому, если это сделает кто-то другой?

А где вы этот ComPort3.1 раздобыли? Никак в Bulder C++ 6 такого компонента не найду...

Ничего подобного - исходники библиотек лежат в \scr\lib\, где с ними можно ознакомиться. А при желании даже перекомпилировать библиотеку по своему вкусу. Если у вас нет исходников, то это означает только то, что вы пользуетесь EV или KS версией компилятора, а не FULL.

Это влияет на учет числа принимаемых/отсылаемых байт. Пока МК в прерывании висит на ожидании, новые поступающие по UART байты не учитываются, пропадая всуе. А потом говорится, что байты де пропали. Если ожидания там нет, то и ожидать нечего. Советую ради теста закоментарить ожидания и посмотреть как это скажется на скорости. А вообще-то программы взаимной пересылки между обоими UART'ами так не пишут. Никаких ожиданий быть не должно, а нужна буферизация. Т.е. в прерывании от поступления байта этот байт пишется в (самодельный) FIFO, из которого потом второй UART тоже по прерыванию (на этот раз от опустошения передатчика) забирает байты для передачи. В случае необходимости перекрестной пересылки - заводят два таких буфера для очередей на передачу для каждого из UART. И перехватывают 4 прерывания - по готовности передатчика и наличию в приемнике по каждому UART. Принимаемые байты пишутся в буфера очередей с одновременным разрешением прерывания по опустошению передатчика своего соседа. А в своем прерывании по опустошению передатчика забираешь байт из своего буфера и отсылаешь его. Если же буфер пуст, то маскируешь собственное прерывание по опустошению. Разрешать его будет сосед, когда запишет для тебя что-то в буфер. Где-то так.

Наклейку я первым делом содрала - нет под ней винта.

А кто подскажет, как можно (обратимо) открыть мышку? http://t2.gstatic.com/images?q=tbn:Rlq6vZA...ter/mouse_l.jpg Никаких винтиков снизу не вижу, а курочить жесткими методами жалко. Могу, конечно, новую купить, но эту жалко - привыкла к ней. И поломка там скорее всего ерундовая - после того, как чай на нее пролила, перестала работать левая кнопка, остальное в полном порядке.

Так у вас же ОЖИДАНИЯ торчат в процедурах обработки прерываний! - Вещь невиданная. И еще хотите, чтобы прерывания обрабатывались с большой скоростью.

А мне всегда казалось, что размер кучи не определяют, а задают в проекте (там же, где задаются размеры стека/ов). Так зачем же определять, да еще и с помощью библиотечной функции, то, что заранее жестко задано?

Посмотрите тему, которая на форуме уже обуждалась: "Вейвлеты, что, зачем, как" http://electronix.ru/forum/index.php?showtopic=70368