aas

Доброе время суток! Я, можно сказать, начинающий схемотехник. Потребовалась мне 2 микросхемы: "6 И" в одном корпусе, и "6 И-НЕ" в одном корпусе. Из описанных выше серий это 808 и 804 соответственно. Но у нас тут принято, что вся цифровая логика CMOS из серии 74HC. Раньше в этом месте мы использовали "4 И" и "4 И-НЕ", т.е. 74HC08 и 74HC00 соответственно. Но, как оказалось, 74HC808 и 74HC804 не выпускаются TI аж с 1987 г., а другие фирмы их, похоже, никогда и не выпускали. Выпускают только 74AS808 и 74AS804 от TI и 74F808 и 74F804 от FairChild. Это все TTL, а не CMOS. :( В то же время, 74HC08 и 74HC00 и сейчас навалом, да еще и от нескольких производителей (я видел TI, NXP и, кажется, FairChild"). Откуда такой странный перекос? Есть какие-то непреодолимые сложности с выпуском 6 логических CMOS элементов в одном корпусе, которых нет при выпуске 4 элементов? Ну да, там микросхема чуть пошире, и лапок 20 вместо 16, но разве в этом может быть дело? Греться вроде как CMOS должен бы меньше, чем TTL, насколько я понимаю. Почему никто не делает CMOS вариантов 804 и 808? А то так заманчива была бы идея, засунуть всю логику в 2 корпуса вместо четырех... Спасибо за ответы!

Доброе время суток! Нет, uC-GUI используется только в двух задачах, в соответствии с тем, как в книжке написано, одна задача, собственно, интерфейса, вторая отрисовывает WM_PAINT. Я где-то читал, этот менеджер умеет только куски памяти фиксированного размера выделять. Хотя, возможно, это была устаревшая информация, документацию именно к используемой версии я столь тщательно не читал (нужную версию книжки автора системы удалось скачать буквально пару недель назад только). А тот менеджер, что я использую, я прошел его код полностью, и при условии защиты мютексом там проблем вроде не должно быть. К счастью, нет, остальное работает стабильно все. Кроме одного очень редкого глюка с GUI - иногда не отрисовывается фон окна и вместо него может вылезти кусок логотипа фирмы, который на десктопе нарисован. Это случается в среднем раз в 3-5 месяцев, и я не знаю как это отследить :(. При этом программа не виснет. А что подразумевается под областью памяти других задач? В нескольких местах у меня одна задача выделяет память, и отправляет указатель на нее в параметрах сообщения другой задаче, а другая задача эту память уже освобождает. Т.е. один кусок памяти в разное время используется разными задачами. Я вот нашел пока только то, что new[] иногда возвращает указатель на свой код вместо кода выделенной памяти. И запрещение прерываний действительно спасает от этого. Почему оно так делает, пока не знаю. Разве этому оператору нужны статические структуры данных? Опять такти, заменил я new на malloc, и все работает и без запрещения прерываний. Не пойму, в чем разница между new[] и malloc может быть для типа char? Там нету конструктора. Попробовал код этого места глянуть, но закопался, там сплошные вызовы каких-то внутренний функций библиотеки. Судя по именам, часть из них для работы с исключениями. Но кода там явно намного больше, чем просто вызов malloc. Мдаа, если я с таким столкнусь, искать, наверное, год буду, а не месяц :)

Я пока не нашел, к сожалению, где посмотреть его код (в смысле, исходник), ну и как правильно его переписать тем более. Там какой-то старый компилятор GNU ARM, еще 2007 или 2008 года, версию сейчас не помню, завтра на работе посмотрю ее... Но меня удивляет еще другое: что могло заставить разработчиков компилятора или библиотеки сделать new[] не thread-safe, если malloc уже сделан thread-safe?

Напишу чуть подробнее, что происходит. Я вытащил исходники _malloc_r, _free_r и еще чего-то из этой серии (кажется, _realloc_r и еще что-то, я посмотрел по sym и map файлам, что ко мне линкуется из этих функций, их и вытащил) в файл и прикрепил к сборке. То есть я прикрепил файл, поставил в нем настройки ка для сборки в составе newlib, и открыл макросами сборку только этих функций. Т.е. вся подсистема памяти (в объеме, в котором я ее использую, включая глобальные структуры данных) теперь берется из этого файла, а не из библиотеки. Потом включил я в ней все проверки целостности структур данных, которые еще автор оставил для режима debug, добавил свои кое-какие, в общем весь файл в ассертах, если вдруг что там было бы разрушено, сразу вылетел бы ассерт (у меня он красит низкоуровневым вызовом экран красным и останавливается на точке останова). Поставил также точки останова при возврате нулевого указателя. Более того, адрес последнего выделенного блока памяти пишется в глобальную переменную, чтобы при останове посмотреть, что это было. В общем, по этой причине в корректной работе менеджера памяти у меня сомнений нет. А вот некорректность new[] я отследил уже двумя способами, во-первых, assert сработал по нулевому указателю, который оно возвращает иногда (причем, malloc, который оно вызвало, вернул указатель нормальный. Во-вторых, assert, который сработал уже во _free_r на то, что указатель не из кучи, да и вообще нечетный (хотя должен делиться на 8). Из кучи адрес или нет, отследить у меня легко: в памяти сначала идут код и статические данные, потом стеки всех задач, потом начинается куча и до конца памяти. Причем, по этому указателю лежит текст, который там и должен лежать, т.е. который я перед этим писал по указателю, который вернул мне new[]. Стеки тоже очень большие, работают от силы на треть размера P.S. А можно подробнее, какие возможности добавились в Cortex по поиску таких вот неприятных глюков?

Доброе время суток! Имеется контроллер ARM7-TDMI-S (LPC2214), на нем многозадачное приложение C++ с оконной графической оболочкой на основе uCOS-II и uC-GUI. Размер памяти 1 мег. Исключения не используются, STL и шаблоны используются. Компилятор используется GCC. Вообще я не большой знаток C++ и вообще работы с микрокрнтроллерами, раньше программировал на Java большие веб-порталы, базы данных и т.д. Но мне от предшественника достался уже настроенный проект и среда разработки, т.е. вноси изменения, нажимай кнопочку, и компилируй, прошивай, отлаживай и т.д. С некоторых пор, когда я сильно увеличил интенсивность использование динамической памяти, около 20-30 обращений в секунду. Программа стала виснуть примерно через 2 - 20 минут работы. На локализацию причины ушло более месяца, и то я не уверен, что локализовал верно. Начал я с алгоритма распределения памяти, от предшественника досталась папка с исходниками newlib-1.16.0. Оттуда я вытащил исходник malloc и free, интересные алгоритмы, но ничего криминального я там не нашел (спасибо китайцу, их писавшему, очень подробные комментарии оставил, а также больше количество отключаемого диагностического кода!). Как и положено, еще мой предшественник переопределил вызовы, включающие мютекс при обращении к этим функциям. Поигрался я с параметрами компиляции, походил по ним отладчиком, все вроде работает там. Но потом я заметил, что некорректные адреса иногда возвращает именно вызов new[], а не malloc, причем, new[] сам вызывает malloc, и этот malloc возвращает адреса корректные, а из new[], как правило, тоже вылетают адреса корректные, те же, что malloc вернул. Но иногда вместо них вылетают нулевые указатели, а иногда даже указатели на его собственный, этого самого new[], код (судя по таблице символов), причем, не на точку входа, а куда-то на середину кода. И вот после того, как я по этому указателю что-то пишу, становится все совсем плохо :(. В общем, заменил я вызов new char[ xxx ] на malloc( xxx ), а delete[] на free(), и все вроде как заработало. Потом я вернул new[] и delete[], но стал запрещать прерывания на время их работы (макросы OS_ENTER_CRITICAL() и OS_EXIT_CRITICAL в uCOS), тоже вроде не падает (по крайней мере, еще не упало, пока я пишу это сообщение...). Вот я и не понимаю, что такого может быть в new[] и delete[], что они не работаю нормально в много задачной среде? В программе не так уж и много мест, где они вызываются. Даже оконная оболочка ими не пользуется, а обращается напрямую к malloc и free, а с ними то я проблем не нашел. STL еще, наверное, их использует, я так догадываюсь, но он тоже вызывается не так часто. Но все-таки хотелось бы иметь нормальные варианты new и delete, которые корректно конструкторы и деструкторы вызывают, ну и т.д. Правильно ли я понимаю проблему, и какие есть способы ее решить? Спасибо за ответы!

Нормально ведет себя, если через DLL от разработчика протокола. Но мой вариант с двумя чтениями на пакет тоже нормально ведет, на моем компьютере, а на более медленных пока не имел возможности потестировать. Может быть, автор DLL тоже так жде поступил, минимизировал количество обращений, и 4 мс на обращение не проблема пока, но может быть он и еще как-то хитрее сделал, увы, у меня нет исходников. Насколько я понимаю, через дополнительные провода его можно тормознуть, если что, а значит можно на большие запасы по времени не закладываться для надежности, и потому можно скорость больше. Вроде все обнюхал и прошел отладчиком вдоль и поперек, и в реальном времени через вывод логов тоже, не знаю что там неадекватного может быть. Да и работает же, если достаточно быстрая реакция. Ну а медленная реакция если, по 3 проводам не тормознешь поток все равно. Да вроде если читать быстро, оно не имеет проблем, и система сама не дает буфер более 4 К поставить. Пока буфер не переполнен, все хорошо, ну а если переполнен, ошибка сразу, или CRC или потерянный пакет выскакивает. Хотя, тут как-то странно все, у меня и дома и на работе XP, правда, на работе XP home русская, а дома XP professional английская. Обе регулярно одновляются. Но окошки настройки параметров порта принципиально разные. На работе окно где много параметров в выпадающих списках, в том числе и размер порта, а дома в окне 2 каких-то слайдера непонятного назначения типа "больше-меньше", вроде тоже размер буфера определяют, но в каких единицах они неясно.

Доброе время суток! Ситуация такая: имеем прибор, который умеет соединяться с ПК через RS232 и USB. Собственно, эти 2 интерфейса, это 2 UART-выхода процессора, которые идут на соответствующие микросхемы-мосты. Разработчики прибора написали в сове время консоль для его настройки, которая взаимодействует с прибором по протоколу WAKE (который тут, как я понимаю, хорошо известен). Консоль написана на Python + dll, написанная автором (как я догадываюсь) этого самого WAKE. Скорость установили аж 115200, хотя RS232-шнур имеет всего 3 жилы, т.е. какое-то управление потоком отсутствует, один конец гонит байты, другой их ловит, как успевает. Но с короткими командами и на не самых древних компах все работает вполне. Теперь тут, уже у меня, возникла задача сделать сначала средство выкачивания из прибора данных, иногда немаленьких (десятки килобайт). Я для упражнения сначала реализовал на этом же Python соответствующие функции. Это как бы расширение протокола получилось на передачу длинных данных, они все идут с одной командой и циклическим счетчиком пакетов. Вроде работает (собственно, в одну сторону это еще до меня начато было, была функция выкачать на ПК скриншот с прибора). Но поскольку следующая задача - перенести пользовательский интерфейс на ПК или планшетник под андроидом, я написал реализацию этого самого WAKE на Java. И вот тут я наткнулся на неприятный сюрприз: с COM-портом все работает хорошо, а вот с USB (т.е. виртуальный COM через драйвер FT232) иногда запрос чтения из него до 4 мс занимает! Т.е. читать по одному байту в цикле не вариант совершенно, входной буфер переполняется и кранты. Соптимизировал я до чтения одного пакета за 2 приема (сначала читаем FEND+адрес+длину данных (или без адреса в моем случае), потом данные+ CRC, это, конечно, если обошлись без стаффинга), только тогда заработало на скорости порта 115200. Ну то есть на моем компьютере, не первой свежести, конечно, (Pentium E2180, двухядерный 2 ГГц) вроде с запасом работает, но у метрологов (которые основные портебители продукции) могут быть еще более древние компы + параллельно в браузерах крутиться могут какие-нибудь флеш-рекламы... А мне потом еще и на Андройде это все гонять, а там железо еще слабее... На всякий случай, из Java я обращаюсь к портам через библиотеку jSSC. Понижать скорость не вариант, ибо "хватило ума" у меня сначала доработать прошивку и отправить заказчиками уже несколько приборов с обещанием дослать потом софт для ПК, а они все ушли с зашитой скоростью 115200, и с этой скоростью оно гонит пакеты без всяких промежутков. Подозреваю, есть решение у автора протокола WAKE в его dll-ках, но их исходников я не нашел :(. Почему так происходит и что делать? Один вариант я сам придумал - самому буферизовывать порт и читать всегда за один прием все что есть. Есть ли еще варианты? Спасибо за ответы!

Доброе время суток! Я новичок в микроэлектронике, потому прошу прощения, если вопрос глупый. Имеем JTAG-адаптер MT-Link 5.0 (так написано на его печатной плате) и программный пакет J-Link ARM V4.14a фирмы SEGGER. Все это работало исправно несколько лет, пока не сгорел этот самый MT-Link (так и не понял я, почему, внутри взорвался конденсатор на входе с USB, сгорела дорожка одна и мертв, как минимум, преобразователь с 5 на 3.3 вольт (если я правильно понял назначение этой микросхемы)). Я нашел в интернете сайт производителя MT-System, но там предлагается уже только адаптер версии 8 (интересно, оно отличается от 5 только прошивкой?). Вопрос: если его купить, оно срастется с имеющимся программным обеспечением? Спасибо за ответы!

Доброе время суток! Вопрос, в некотором роде, в продолжение темы http://electronix.ru/forum/index.php?showtopic=105864 Предыстория такая: У меня неплохое образование (МФТИ, прикладной математик), кандидатская степень в области IT ( Информационные системы, базы данных, поиск данных...) и опыт работы в области создания интернет порталов, систем документооборота, и т.д., даже есть сертификат Java-программера от Sun. Но карьера как-то не шла, наконец, я выдохся от постоянной гонки и скачков с места на место, заболел и пришлось уехать из Москвы домой, в, скажем так, теплый южный город с некогда мощной приборостроительной промышленностью, развалины которой до сих пор еще как-то дымятся :). Собственно, среди этих развалин я и попытался обосноваться, взявшись за работу, весьма далекую от всего того, чем я занимался раньше - программирование микроконтрроллеров высокоточных приборов. К моему удивлению, занятие это понравилось мне гораздо больше, чем все, чем я занимался раньше. ну то есть у меня всегда было хобби, визиться с железками (автомобили, жд дрезины, и много что еще), а тут как бы прозшло сращение хобби и профессии, да и квалификация прежняя не так чтобы совсем ненужна оказалась - старый программист, он в любой области старый программист, а непрерывно учиться по ходу жизни программисту не привыкать, ибо в нашей отрасли технология часто устаревает раньше, чем ты ее хорошо освоишь :). Я даже не думал раньше, что работа может стать любимым занятием (с почти отвращением вспоминаю свои предыдущие работы, даже диссертацию) :). Ну и карьерный рост вдруг пошел - за год работы я начальник проекта с предложением готовиться на пост директора... Ну то есть я понимаю, что это не от моих сверхспособностей, а просто на безрыбье и рак - рыба: людей, катастрофически не хватает, уже сейчас самый молодой мой подчиненный старше меня на 10 лет, все, кто реально ведет разработку, уже пенсионеры, а молодых в принципе нет и не предвидется - система технического образования в нашем городе коррумпирована максимально чудовищно и ее уровень катастрофически низок, насколько я знаю. И вот, казалось бы, все идет хорошо, но есть одна проблема - я остро ощущаю недостаток квалификации! На момент прихода на эту фирму все, что я знал в электронике - принцип работы p-n - перехода, а также pnp и npn транзисторов. Сейчас умею читать даташиты, понимаю цифровые схемы и несложные аналоговые, могу еще в P-CAD подсветить какой-нибудь провод или дорожку, и посмотреть, куда они идут. Знаю также немного ассемблер ARM, C++, умею прошивать контроллеры некоторые... Но уже встал вопрос уметь самому проектировать и разводить платы, а аткже проектировать архитектуру сложных приборов (правильная разводка земель, экранов и т.д. Приборы, которые мы создаем, имеют класс точности 0.01. Итого, вопрос: с каких книжек начать самообразование? Я понимаю, что со сменой кввалификации я уже несколько опоздал - возраст 37 лет уже :(((. К тому же есть семья и ребенок, т.е. в дауншифтинг не уйдешь уже. Но у меня весьма высокая подготовка по математике и физике (одна из лучших, что возможны в России в рамках высшего образования - красный диплом в МФТИ), но совсем нет подготовки в микроэлектронике, как аналоговой, так и цифровой. Английского языка не боюсь, но по-русски читать все-таки менее утомительно для меня. Спасибо за советы!

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

У нас примерно так и сделано, и все работает. Единственно, __attribute__((section(".section_my"))) стоит в конце, после определения переменной. используем GNU ARM, и компилятор, и линковщик

В общем после длительных экспериментов ввел я с горя в список путей поиска исходников ввел корень диска "D:\" и поставил галочку смотреть также подпапки. Хотел посмотреть, как долго это чудо будет шерстить диск по десяткам тысяч каталогов и не рухнет ли от переполнения. А оно.... ....НАШЛО ИСХОДНИКИ!!! И даже там, где надо! потом я снял галочку "искать в подпапках", но оно все равно находит исходники в корне. Я ничего совсем не понял, почему так, вот какие каталоги в результате у меня оказались в настройках: 9.gif Верхний пункт, это и есть каталог D:\ В то же время в elf-файле пути к исходникам проставлены от корня проекта, т.е. он где-то внутри почему-то сам дописывает путь к корню проекта и потом только ищет файл, наверное...

Нет, объектные файлы не попали, да и вычищал я промежуточные файлы все при пересборках, разумеется. Насчет баг-репорта незнаю, ибо до замены жесткого диска все работало. Единственно, там подверсия (номер сборки) Java отличается, но тогда непонятно, почему eclipse эти файлы открывает без проблем для редактирования, и даже когда я на брекпоинт кликаю, открывается нормально исходик. Не хочет только открывать, когда оно останавливается на брейкпоинте и когда кликаешь на стек тоже не открывает (то есть не находт исходник, хотя пишешь в заголовке окна и правильное название файла, и правильный номер строки, и в стеке для каждой точки).

Поставил я последнюю версию Eclipse+CDT (называется Juno которая), доставл туда последнюю же версию плагина GDB Hardware Debuging, Переустановил GNUARM в другой каталог, скачал проект с SVN, версия, которая точно нормально отлаживалась, настроил компиляцию и отладку и... тот же самый глюк: отладчик не хочет открывать исходники :(((( Что еще это может быть? Уже совсем голову сломал, не понимаю, в чем дело: до падения жесткого диска и системы все работало, исходники легко находились :(((

Путь указывал, не помогает :(. В elf-файле там пути все стоят от корня проекта. Я пытался и корень проекта указать, и непоследственно папку файла, все равно не помогает. По опыту работы с отладчиком Java (тоже в эклипсе, разумеется), там достаточно указать корень дерева папок с исходниками, и отладчик сам находил файл, а тут вроде все указано, да и не менялось в сравнении с тем, как было раньше, а не находит уже :( Путь к корню workspace изменился, да. Внутри workspace путь не менялся, да и прописывал я пути ему и в настройках отладчика для проекта и непосредственно в оне, которое открывается по кнопке "указать путь к файлу". В упор не видит он ни один файл с исходниками :( Забыл дописать. Кирилицы ни в одном пути нет