Xenia

MaksimYrievich, в следующий раз, когда будете задавать вопросы, называете пожалуйста компилятор! По номеру версии зачастую бывает трудно определить, с чем вы имеете дело. У компании IAR есть множество компиляторов под большой набор микропроцессоров. А к вашей версии 5.30 подходят два компилятора: EWAVR-530 и EWARM-530. И только ваш пример позволяет догадаться, что речь идет о компиляторе для ARM, т.к. у AVR такого доступа к USB-буферу нет. Поэтому для начала советую вам ознакомиться с темой "Бригада телепатов отвечает на ваши вопросы". Что касается вашего примера, то он из серии размещения переменных или массивов в заданных областях памяти. Типично такая кострукция имеет вид: __no_init UCHAR usbRxBuf[2][uSB_BUFSIZE] @ segname где segname означает имя сегмента памяти, в котором размещается переменная или массив, а __no_init обязательная в таких случаях индульгенция, разрешающая компилятору эту область не инициализировать. Если этого не разрешить, то он, скорее всего, откажется сделать такое размещение. Имена сегментов обычно запрятаны в xcl-файлах линкера, там это имя (USB_BUFFER_SECTION) и нужно искать. Поскольку компилятор не может принять в качестве segname переменную или константу, а требует явного названия в этом месте имени, то такую подмену приходится делать при помощи дефиниций прекомпилятора #define. #define __attribute__(arg) и #define IAR_SECTION(section) @ section являются такими средствами. Вторая дефиниция как раз делает такую подстановку, вставляя значок @, а затем приписывая после него то слово, что записано в ее аргументе. А первая дефиниция утрясает согласование типов (впрочем, необходимость этой конструкции мне не до конца понятна). Таким образом, массив usbRxBuf[2][uSB_BUFSIZE] размещается в том месте памяти, которая используется как буфер для USB-канала. Скорее всего, речь идет о режиме работы с двойной буферизацией данных, т.к. массив состоит из двух кусков по USB_BUFSIZE. Такая конструкция позволяет программисту напрямую обращаться к произвольному байту буфера принимаемых данных.

FARNELL запустил русский сайт www.farnell.com/ru Исходя из информации на сайте, при заказе до 18 ч по Москве отгрузка идет в тот же день. Стоимость доставки по всей России заказа весом до 10 кг - 20 евро. Вся команда поддержки, включая технических специалистов - русскоязычная. 10% скидка на первый заказ. Сравним цены FARNELL и ELINAN по моему любимому AT32UC3A1512-AUT: FARNELL: AT32UC3A1512-AUT 1: 10.22 евро 10: 7.44 евро 100: 5.84 евро Пересчитаю на рублики по курсу 45 руб за евро: 1: 459.9 руб 10: 334.8 руб 100: 262.8 руб И это при том, что на первую поставку FARNELL обещает 10%-ную скидку, которую я не учла! Вот ссылка, чтобы удостовериться в том, что цифры списала правильно: http://ru.farnell.com/jsp/search/browse.js...6locale%3Dru_RU Теперь переходим к ELINAN: В прайс-листе видим две партии. Первая партия: 1: 749.0 руб 10: 505.0 руб 100: 394.0 руб Вторая партия: 1: 810.0 руб 10: 552.0 руб 100: 437.0 руб Сравниваем и получаем, что штучный заказ (1 шт) стоит у ELINAN дороже, чем у FARNELL на 749 - 460 = 289 рублей! что в дороже на 63% Примерно тот же процент получается и при сравнении партий в 10 и 100 штук - соответственно 51% и 66%. Т.е. даже при самой оптимистичной оценке цены у ELINAN в полтора раза (!) дороже, чем FARNELL. И это еще притом, что цены я брала по самой дешевой партии, которую предлагает ELINAN. А если учесть, что в этой партии осталось нераспроданными только 55 штук, то ясно, что покупать большую партию в 100 штук, придется у ELINAN’а еще по более высокой цене второй партии. Т.е. той самой партии, где одиночная микросхема стоит 810 руб против 459.9 руб у FARNELL. Комментарий представителя ELINAN меня сейчас интересуют мало, т.к. и так легко догадаться, каков он будет - "не хочешь не покупай". А вот мнение местных электронщиков на этот счет меня сильно интересует. Мое же мнение таково, что с появлением на российском рынке иностранных компаний, торгующим по европейским ценам, присутствие на рынке таких перекупщиков, как ELINAN, сильно сократиться, т.к. последние не выдержат конкуренции.

Посмотрела прайс-лист компании - фигня какая-то. Для AT32UC3A1128-AUT и AT32UC3A1512-AUT указаны сразу две позиции с одинаковым описанием ("подробнее"), но ценой, отличающей аж на 50 рубликов. Или вот: AT32UC3A1256-AUT 1: 810.00 10: 558.00 25: 483.00 100: 367.00 AT32UC3A1512-AUT 1: 746.00 25: 444.00 100: 403.00 - цена за МК с вдвое меньшим размером flash установлена ДОРОЖЕ (!), чем за его собрата с большим размером памяти. И снова примерно на те же самые загадочные 50 рубликов. И как вообще понимать запись о том, что наличие на складе "1174 штуки + 3 недели"? Это три недели они эти миросхемы у себя на складе искать будут? Да за 3 недели из Америки можно заказ оформить и получить! Я уж лучше пойду в Терраэлектронику сразу же на месте куплю себе AT32UC3B0256-A2UT за 312 руб 63 копейки http://www.terraelectronica.ru/catalog.php...e=2&PageS=1 чем буду ждать 3 недели, чтобы купить то же самое в Элитане за 609 руб.

Zlumd, спасибо! Я попала впросак, поскольку у меня AT32UC3A0, у которого всего этого набора нет. И я не слишком вникала с различия между сериями после буквы A. Другие серии меня не заинтересовали, т.к. у них не было Ethernet-контроллера. Теперь же я скачала даташит на AT32UC3A3 и увидела, что вы были правы.

Простите, но где вы всё это увидели у AT32uc3? Что-то я в упор не вижу, где бы это упоминалось в его даташите. Не подскажите ли, какими словами там описано наличие этого?

Совместимость более новой версии с более старшей - это прямая совместимость, а не обратная. Причем такая соместимость, как правило, почти всегда бывает реализована. IAR в таких случаях сам предлагает провести конверсию старого проекта в новый. А если все-таки что-то перестает компилироваться, то надо разбираться конкретно с каждой из ошибок, на которые жалуется компилятор.

Насколько я поняла, автор сабжа собрался не сопроцессор делать, а просто поставить внутри персонального компьютера второй процессор, "заточенный" под арифметику с плавающей точкой. Однако нынешние x86-процессора при 3 ГГц и так работают настолько шустро, что становится проблемой найти в качестве второго процессора такой, который бы мог составить конкуренцию первому. Ведь если такое преимущество окажется не слишком разительным, то проще (а главное дешевле!) было бы купить банальную двухпроцессорную материнку. С другой стороны, работать с основной памятью через PCI-шину сопроцессор не сможет, а точнее, такая работа была бы неэффективной, поскольку затормозила бы работу сопроцессора на операциях чтения и записи в память. Стало быть речь идет не о сопроцессоре, а об одноплатном компьютере, т.к. сопроцессор придется снабжать и собственной памятью команд и данных. Меня же в этой ситуации больше интересует вопрос о том, какие существуют в мире (микро)процессоры, способные работать с плавающей арифметикой в разы быстрее, чем, скажем, Pentium-4 или Core Duo на предельных частотах. Причем речь идет об аппаратной работе с числами не короче double (8 байт), а лучше long double (16 байт). А так, если требования к точности не очень большие (данные типа float), то можно юзать процессор видеокарты. Где-то я читала, что продвинутые видеокарты (кажется от AMD) уже позиционировались, как потенциальные вычислители. Понятно, что покупка такой видеокарты окажется в несколько раз дешевле изготовления собственного сопроцессора, а производительность видеопроцессоров на старших моделях видеокарт отнюдь не хилая.

Убрали бы вы от греха подальше подключения такого рода. Тем более, что у вас есть Delphi. Вставьте хидер #include <setupapi.h> в котором все эти функции определены и рабоотайте спокойно (буквы A заодно уберёте). По крайней мере будет полная уверенность, что параметры функций пересылаются правильно. И еще хотелось бы знать, на каком C-компиляторе вы работаете.

С буквой W идут функции, у которых стринговый аргумент widechar, т.е. такой, когда символ занимает два байта вместо одного. Только обычно комилятор сам решает, с буквой A ему выбирать функцию или с буквой W, а программист эти буквы не пишет, а только в опциях устанавливает то, с какого рода символами он работает. А на счет вашего вопроса вот тут почитайте, может поможет: http://borland.xportal.ru/forum/printview....f9c7e2ae9c64f9e

Верное замечание! Формат %d для вывода в char-переменные не годится. А формат %hd далеко не все компиляторы поддерживают. Надежнее, да и ближе к стандарту, завести переменные типа int (хотя бы временные), а том из них скопировать в char.

Если это char, да еще и знаковый, то возражений у меня нет. Я же имела в виду, что выражение if (0xC0 >> 2 == 0xF0) было бы расценено IAR-компилятором как ложное, а if (0xC0 >> 2 == 0x30) как истинное. P.S. IAR-компилятор для AVR8 понимает int, как двухбайтное знаковое целое, несмотря на то, что регистры имеют разрядность один байт.

С чего бы вдруг 0xC0 быть байтом? Запись 0xC0 означает лишь шестандцатеричную форму записи, но никак не ограничение одним байтом. Думаете, что 0x00C0 другое число? - Нет, то же самое! Константы такого рода считаются, как int-значения, а не char. А int это обычно 2 байта, а не один. Причем даже для 8-битных микропроцессоров (AVR). Поэтому старший бит у этого числа нулевой. А потому 0xC0 >> 2 == 0x30;

sscanf(Edit_IP->Text.c_str(), "%d.%d.%d.%d", &IP_server[0], &IP_server[1], &IP_server[2], &IP_server[3]);

На такие вопросы здесь отвечать запрещают. Я сегодня дала ответ (в тему http://electronix.ru/forum/index.php?showtopic=62289 , поскольку с 3.10A та же проблема), но его сразу же потёрли модераторы.

Я уже объясняла, что сложности с набитыми мусором булевскими переменными возникают исключительно при проведении булевских операций над ними, что заставляет компилятор во имя эффективности использовать только младший бит этого числа. Однако при проверке булевой переменной (например для ветвления по оператору if) такой проблемы не возникает, и тут компилятор проверяет переменную "честно". Это потому, что поверка одного бита "стоит" ровно столько же, сколько проверка всех битов - тестирование регистра на нулевое значение занимает столько же инструкций, как и тестирование одного его бита. А вот булевские операции (типа ! ~ ^ & |) над одним битом производятся элементарно, а над мусорными переменными нет. //B = 13 if (B == true) printf("true\n"); else printf("false\n"); - тут B тестируется на ненулевое значение, а потому ЛЮБОЕ ненулевое значение B напечатает true. B = !B; if (B == true) printf("true\n"); else printf("false\n"); - а тут операция B = !B компилируется экономно - инверсией младшего бита. Можно было бы сразу инвертировать все биты числа, но мусор от этого останется мусором, но в false не превратится. Попробуйте сами вместо компилятора оттранслировать B = !B. Тогда поймете, что без ветвления по if/else этого сделать нельзя. //Избавляемся от мусора if (B) B = true; else B = false; Избавляться от мусора короче так: B = B ? true : false;

В каждом компиляторе работа с bool может быть организована по-разному. Ваш компилятор очевидно конверсию в bool производит на этапе присваивания, а работает с bool-переменными, используя только их младший бит. Такой подход эффекитивен при компиляции, т.к. упрощает булевские операции, позволяя делать их "не глядя". В противном случае приведение типа пришлось бы делать при каждой булевской операции с ее использованием. Таким образом "мусор" не мешает работе программы, поскольку все остальные биты, кроме младшего, в работе не участвуют.

Да, по нынешнему времени борландовский раскрас кнопок выглядит анахронизмом. Но надо понимать, что раскрашивали их в пору Windows 3.1, когда родное оформление графических элементов было довольно-таки убогим. И в те времена такие кнопки почитались за шик :). Но в более поздних версиях Windows навели марафет. Тут не только тени, но и целый набор централизованно выбираемых стилей. После этого борландовский раскрас выглядит уже скромно, а у кое-кого вызывает неадекватную реакцию :). Но ведь не беремся же мы за молоток, когда видим микросхемы в DIP-корпусе? :) А при програмировании и того проще - если хочется иметь Windows-ский псевдотрехмерный раскрас, то достаточно выполнить: EnableCtl3d(true); А если хочешь заказать старые кнопки, то выполняешь: EnableBWCC(true); Т.е. в том и другом случае осуществляешь заказ того, что хочешь. А если не заказывать ничего из этого, то кнопки получатся стандартными, такими, как они выглядят на родных виндоусовских диалогах.

Программа живет в среде операционной системы, подобно тому, как человек живет в городе. API в этом смысле выступает, как "коммунальные услуги", предостявляемые программе совершенно бесплатно, в отличие от гражданина, который подобные услуги оплачивает из свого кармана. Услуги, предоставляемые операционной системой программе, чем-то схожи с водопроводом, отоплением, канализацией, сетью магазинов и т.п. Программа, отстаивающая свою независимость от платформы, подобна маняьку, который овощи выращивает на подоконнике в цветочных горшках, воду собирает с крыши, отапливается буржуйкой или по-черному, а по малой и большой нужде ходит в яму, выкопанную посреди комнаты :). От такой "независимости" вреда куда больше, чем в зависимости от операционной системы, которая предоставляет столько возможностей, что глаза буквально разбегаются. А операционная система Windows в этом смысле самая щедрая. OWL-библиотека лишь группирует средства API вокруг определенного пользовательского элемента. Например класс TButton описывает кнопку, в котором функции-члены класса позволяют делать с этой кнопкой всё, на что кнопка в принципе способна. Т.е. тут есть и функции, утапливающие эту кнопку, и опредляющие надпись или картинку на ее поверхности, и функции автоматически делающие ее активной или неактивной в зависимости от любого условия. Кроме того есть множество функций, которые сами выполняются при каких-то ситуациях с этой кнопкой, например, когда на нее наведена мыщь, или по ней этой мышью кликнули один раз, дважды, или нажали над ней правую кнопку мыши, активировали табулятором и т.п. Сюда же относятся и функции, которые запускаются, если окно, на котором изображена эта кнопка, именило свои габариты (например, было растянуто), изменилось разрешение экрана или масштаб диалоговых элементов, или пользователь сменил палитру рабочего стола. Кроме того, дилоговое окно, которое, в свою очередь, представлено своим классом (TDialog) тоже всегда находится в курсе, что происходит с элементами, на нем расположенноми. Поэтому устанавливая кнопке класс TButton, мы тем самым делаем ее управляемой от диалогового окна, делая возможными групповые операции типа "когда одну из кнопок нажимаем, ранее нажатая выскакивает". Перечислять возможные ситуации можно очень долго, но главный плюс в том, что все эти функции, определяющие реакцию стандарной кнопки на "раздражение" уже написаны. А программист лишь доопределяет эти функции (дописывает или заменяет на свои) в том случае, когда стандартная реакция кнопки его не устраивает. Надо признать, что подобным же образом организованы пользовательские классы и в Qt, и во многих других библиотеках классов. Т.е. это отнюдь не изобретение Борланда, а сложившаяся тенденция использования графических элементов в условиях, когда программисту становится сложным предусмотреть все возможные ситуации, которые могут реально возникнуть. Кроме того это чрезвычайно сильно облегчает написание программы, поскольку программу можно строить из стандартных кубиков, занимаясь модернизацией кубика только в тех случаях, когда в этом возникает острая необходимость. Понятно, что самый компактный и экономичный способ существования получится, если ездить общественным транспортом, а не заниматься содержанием лошади, заготовкой ей сена и т.п. :) Времена натурального хозяйства давно прошли. И в отношении к компьютерной среде, в том числе.

На Ватком OWLNext не ставится. Вот здесь - http://owlnext.sourceforge.net/prebuild.html - представлены уже скомпилированные библиотеки для всех поддерживаемых комиляторов. На практике выбираешь одну из них и с ней работаешь. Ничего инсталлировать не надо, просто добавляешь подходящую библиотеку (это один единственный файл!) в директорий LIB, где хранятся родные библиотеки компилятора, а папку OWL со специфическими хидерами кладешь в директорий INCLUDE, где хранятся родные хидера компилятора (папку при этом вытрясать не надо - так в своей папке пусть и лежат). Вот и все! По сравнению с этим, Qt - это монстр какой-то! Важно понимать, что OWLNext это надстройка над операционной системой Windows, организованная в виде пользовательских классов, опирающихcя на ее API. А Qt - автономное государство в государстве (анклав), где практически всё реализуется исходя из примитивов. В этом-то и причины как переносимости Qt на неродственные платформы, так и огромного веса её библиотек. Для сравнения, статическая билиотека OWLNext весит меньше 4-х мегабайт, а реально добавляемый к программе код - около 600-800 килобайт.

Я использую Buider 6 или еще более древний Borland C++ 5.02 (релиз 1997 года еще до эпохи Билдеров). В данном случае новизна самого компилятора вещь второстепенная, т.к. новая OWLnext (последняя версия обновилась в этом месяце) знает о особенностях современных Windows (включая Vista) всё, что нужно знать. Не знаю точно как обстоит дело с Buider 6 сейчас, но за Borland C++ 5.02 нынче никто не цепляется, т.к. сама компания Borland этим делом давно не занимается (сначала передала права CodeGear, а потом Embacadero), а последним наплевать на права Borland'а на продукт 12-летней давности. Что же касается меня лично, то у меня имеются официальные лицензии на Borland C++ 3.0, Borland C++ 4.5, Borland C++ 5.02, Buider 6, CodeGear RAD Studio 2007 (все версии покупались с большой скидкой, как апгрейды к более ранним). А кто покупал первый Borland C++ 3.0 уже никто не помнит, давно было. Но если так остро стоит вопрос о бесплатности компилятора - используйте gcc, он бесплатен по определению.

OWLnext http://owlnext.sourceforge.net/ Маленькая и компактная библиотека классов для GUI-интерфейса под Windows. Компилится на всех компиляторах компании Borland (откуда она, кстати, когда-то произошла) и ее приемниках (в том числе и RAD Studio 2009 года), всех версиях MS C++ Studio (включая 2008 года) и gcc. Удовлетворяет требованию бесплатности. Рекомендую всем, кому нужна обозримая версия, в исходниках которой можно разобраться.

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

А как же тогда им удается точно позиционировать головку, если они не шаговые? Я сама смотрела - там двигатель крутит червяк, как у мясорубки :), по которому ползает крючок головкодержателя. Ведь компьютеру же удается смещать ее с трека на трек? Аналоговым регулятором напряжения или тока управлять таким процессом просто невозможно, поскольку там трение покоя приличное - с места труднее сдвигать.

Серокой, вы, как я поняла, занимаетесь запуском того двигателя, который диски крутит. А могли бы вы сказать хоть несколько слов о том двигателе, который двигает головку? Как устроен тот узел? Там что, шаговый двигатель? Как он управляется? Мне самой в этом разбираться сложновато, а вы уже дисковод раскурочили. Может заодно что-то и про тот двигатель сможете сказать? А то мне нужен слабосильный шаговый. Сначала думала из старого матричного принтера достать, но тот электричества много жрет. А из флоповода или CD-привода было бы в самый раз.

6 день - пьёте пиво. :)