Tarbal

Причем в случае Андроида портировать тоже Линукс :)

На каком процессоре будет бежать программа? Что говорит echo $PATH Про префикс компиллятора. Он не имеет ничего общего с опцией префикс и указывается при компиляции. Вот такой командой я строю кернел. make ARCH=arm CROSS_COMPILE=arm-cortexa8-linux-gnueabi- uImage Указана архитектира ARCH= и префикс для компилятора CROSS_COMPILE=. Это значит, что будет использован компилятор arm-cortexa8-linux-gnueabi-gcc, библиотекарь arm-cortexa8-linux-gnueabi-ar и т.д.. PATH должен содержать местоположение этих компилятора, линкера, библиотекаря и т.д.. Я раньше приводил вам весь список. Для компиляции в пользовательской моде вещи отличаются. Вот посмотрие документ: http://landley.net/ols/ols2007/tutorial.txt

Положим одна транзакция 100 бит. Значит при 80% загрузке в секунду приходит 8000 сообщений. А сколько у вас прерываний случается?

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

Уточните насчет программных прерываний. Может все-таки это реальные прерывания вызванные железом? Если так, то число прерываний должно совпадать с числом принятых сообщений, переданых сообщений и еще какой-нибудь байды, которая разрешена. В контроллере CAN должен быть регистр маски прерывания. Вам следует разрешить в нем только прерывания относящиеся к делу. С передачей сообщений бывает следующая проблема. Флаг прерывания установлен всегда, пока буфер передатчика пуст. Иногда бывает флаг, что гасится тем или иным способом и не восстанавливается до следующей передачи. В устройстве могут присутствовать оба механизма. В первом случае необходимо маскировать прерывание передатчика в обработчике и разрешать, когда есть что передать.

Поищите в этом треде. Три фреймворка здесь обсуждались. http://electronix.ru/forum/index.php?showtopic=113476 ZIO должен быть серьёзным. Один из авторов соавтор библии линуксовских драйверов. Однако фреймворк не панацея от всех проблем и при переносе системы вы столкнетесь с проблемами, которых фреймворком не решить. Фреймворки работают для драйверов устройств, которые вы хотите подключить к работающей системе. Есть много драйверов, с которыми фреймворк вам не поможет. Я бы вам посоветовал не переносить систему с платформы на платформу, а найти работающую платформу на том процессоре, что вы планируете использовать. Следующим шагом научиться строить кернел для этой платформы. Далее изучить индивидуальный файл для этой платформы, где определена только ее конфигурация для ОМАП2 и ОМАП3 это файлы из: arch/arm/mach-omap2/ Для Биглборда машинный файл board-omap3beagle.c лежит здесь. board-omap3evm.c для мистралевского борда на AM3715. Здесь создаются все устройства, которые вы собираетесь использовать. С дисплеем можно попасть в струю если есть возможность выбирать. Для проекта, что я работаю сейчас мы нашли дисплей,что обошлись без драйвера. Я только добавил видео моду для нужного разрешения (1024х600). I2C, SPI, GPIO драйверы писать не надо. все уже есть. Правда если вы хотите подключить какой-нибудь чип, использующий скажем I2C, то вам придется писать драйвер (а то и не один) для поддержки всей остальной части чипа. Хорошие новости. Множество драйверов уже реализовано. Иногда поддержка производителя чипа дает коды драйверов.

Кстати предложенный Проффессором вариант тоже работает: http://www.megalithia.com/sounds/tech/piezo/fetamp.html И даже патентован: http://www.google.com/patents/US20040164647 А музыканты на заряд вообще плевать хотели :) http://www.openmusiclabs.com/learning/sensors/piezos/

Если бы мне предстояло решать эту задачу, то я бы начал с предложенной Профессором схемы. Преимущества: 1. Симметричный сигнал сильно помехоустойчив 2. Простота 3. Естественность при подключении питания. 4. Симметричный сигнал погасит наводку 50 герц, которая зачастую бывает между землями. Недостатки: 1. Завал верхних частот. Возможно его можно будет вытянуть. Ведь виниловые пластинки не использовали преобразователей заряда, но качество звука с пьезо датчика было вполне достойным и на верхних частотах. Какой спектр надо обеспечить? Шум предусилителя обеспечивается полупроводниками в большей мере чем резисторами. А если хочется частотно-независимого сигнала, то поставить два транзистора с общей базой. Тока не усилит, но по напряжению можно неплохо поднять. В принципе можно добавить эмиттерный повторитель. Но схема сложнее выходит. К тому же ток преобразует в напряжение, но надо будет проинтегрировать в конце для получения сигнала пропорционального заряду. Схема такая: в коллектор включается линия с нагрузочным резистором на другом конце. С коллектора идет делитель на землю. База подключена к средней точке делителя. Между базой и емлей ставится конденсатор. Последовательно с эмиттером резистор на землю. Собрать две такие схемы и между эмиттерами включить датчик. C питанием нет проблем и симметричный выход налицо.

Успеха вам.

Могу подтвердить, что он докопался до причин и устранил их.

Емкость подключать к инвертирующему входу не доводилось. Хотя допускаю, что может возбудиться. Спорить не буду.

1. Операционный усилитель в линейном режиме изменяет потенциал инвертирующего входа так, чтобы он был равен потенциалу неинвертирующего входа. 2. Входной ток ОУ настолько мал, что его считают нулевым. Исходя из этих двух замечаний устройством с токовым входом будет только устройство c источником непосрeдственно подключенным к инвертирующему входу. Источник, подключенный через резистор будет представлен током, через этот резистор, а значит (через закон Ома) напряжением, приложенным к этому резистору. Отсюда легко получить коэффициент усиления инвертирующего усилителя на ОУ (по напряжению). Можно другими словами. Измеритель тока имеет нулевое сопротивление. Кстати верхние частоты не будут ослаблены только если нулевое сопротивление нагрузки. Ток есть, а изменения напряжения нет. Конденсатор может влиять на напряжение, а не на ток. Про самовозбуждение это вы преувеличили. Никогда не видел чтобы интегратор самовозбудился. Кстати со времен К140УД1 и К140УД2 ни разу не видел, чтобы линейная схема на ОУ возбуждалась. Хотите расскажу от чего возбуждаются усилители?

Последнее сообщение показывает как формируется запрос. Там такая система. Есть несколько обработчиков событий. Один из них DM (device монитор или менеджер чего-то судя по букве М). Все его события начинаются DM_.... одно из них DM_LINK_POLICY_KEEP_PARKED запрос зайти в парк моду. Надо сформировать запрос и послать его. В коде есть множество примеров -- там это делается сплошь и рядом для других DM_ запросов. В обработчике стоит switch(event) и case DM_LINK_POLICY_KEEP_PARKED: делает всю работу. Не рекомендую копировать содержимое case в то место где надо сделать парк. Правильно сформировать запрос и послать его. На здоровье! Да. Без этого форума разрабатывать было-бы кисло :) Там есть подфорумы. Один из них тест, где надо попробовать как получается писать. Еще есть подфорум с правилами. При регистрации некоторые по ошибке вводят имя типа CSR, полагая, что это имя под которым будет форум у них. На самом деле это имя под корорым они будут на форуме. Зачастую на простой вопрос они не отвечают, но я нашел способ спрашивать так чтобы ответили. Я спрашивал в каком документе про это можно почитать :) Успехов

Так вы не знаете чем отличается инвертирующий усилитель от усилителя тока.

Боюсь, что ничего не получится.

К сожалению я давно не работал с CSR. Все собираюсь купить BlueLab. У них на сайте есть инструкции как подключится к их поддержке. http://news.csr.com/ http://read.pudn.com/downloads158/ebook/70...-to-BlueLab.pdf Найдите пункт 3.1 на 7 странице или 3.2 на 11. Там есть подгруппа c.p.b.bluelab. В ней и спросите ваш вопрос. Можно сначала поискать. Не исключено, что кто-то спрашивал. Там инженеры CSR в реальном времени как на форуме отвечают на вопросы. Я уверен, что есть функция для ввода в один из энергосберегаютхих режимов. Кстати если у вас есть пример их апликации хедсета, то вы можете найти вход в энергосберегающий режим. Я не помню какой из них используется снифинг или park (там третий был, но забыл как называется). Вот несколько ответов с ленты: "ran" <ran@ran> wrote in message news:44f70570@ukrbcsr01.... > > 1. what is the reason it didn't enter park mode? > > 2. is it because I need to do some changes in the spp master's code ? and if > so - what kind of changes? > > 3.what kind of message request or information it sends to the other chip > when i configered it as DM_LINK_POLICY_KEEP_PARKED ? > You need to send a DM_HCI_WRITE_LP_SETTINGS on the master with the park bit enabled in link_policy_settings. As you don't want it to initiate park, set the dm_policy to 0. By default, the Connection Library sets the policy to allow Sniff and RoleSwitch. The reason it does not allow park is that there are many Bluetooth chipsets on the market which do not implement park correctly (because it's so tricky to get right!). In fact, the Bluetooth SIG are planning to remove it from future specs. Can I suggest you use sniff? Chris. ------------------------------------------------------------------ "ran" <ran@ran> wrote in message news:44fbf27f@ukrbcsr01.... > Hi, > 1. I took a look at the lp table and I saw there is just two states : active > and sniff . is it possible to add park to this table? The LP table does not support park. As I said in my last email, we don't recommend the use of park. > 2. I measured the currents at lp sniff state . at the ssp slave (spp dev B) > the currents indicated that it enter deep sleep( 0.9mA) but at the ssp > master (spp dev a) it didnt enter deep sleep (5mA). > why ssp master doesn't enter deep sleep at the sniff state. 5mA implies the chip is in sniff, but has not entered deep sleep for some reason. Obvious suggestion is to check PSKEY_DEEP_SLEEP_STATE. By default, SPP is likely to disable sleep to prevent bytes being lost on the UART. Chris. ----------------------------------------- sharpbull wrote: > Nobody cares this question.Maybe my question remain obscure? > "sharpbull" <[email protected]> дÈëÏûÏ¢ÐÂÎÅ:447660a8@ukrbcsr01.... >> Hello all! >> I use BlueLab3.4.2 to develop spp application.The chip is BC4 EXT.I want my spp module can enter park mode then the master device can connect with more spp module.But I find some code to do this has been delete in BlueLab3.4.2.In BlueLab2.8,some function can be called to do park.Why? >> I want to know how can I realize this function with BlueLab3.4.2. >> Thanks for your help! >> sharp >> > > Park mode has been all but officially deprecated from the Bluetooth specification... or there has at least been discussion to that end. That being said, you're right, park mode is still a valid and legal low power mode in the latest version of the Bluetooth specification. There are placeholders to support park mode is in BlueLab and in the header files. However, park mode has not been added to the standard released libraries. It is possible for you to add the support to the the code since the primitives and other state variables are there as placeholders in the header files. Cheers, Ken ----------------------------------------------------------- Ken Steck wrote: > Park mode has been all but officially deprecated from the Bluetooth > specification... or there has at least been discussion to that end. It's not been officially deprecated, but at the last spec meeting I went to, every mention of park mode was accompanied by giggling. You may interpret this observation any way you want. - Steven ------------------------------------------------------ > I am writing an application based on the Spp_slave example in Bluelab 2.8. > I really need to be able to park the device and then unpark the device from > the master (I am using a single board computer running win CE to act as the > master). When I set the max_intval and min_intval values in config.c in the > spp_common directory, the device appears to panic after a connection has > occurred (the SBC can't successfully disconnect from the device). > By setting the panic action to reset you can verify whether the device really does panic. Can you confirm that the device is reset after this panic condition occurs. Alternatively you might try running the app in the debugger as then you'll be able to work out exactly where its panicking. > After reading the Bluestack documentation I noticed that the Device Manager > can be configured to try to keep the device in park mode when there is no > ACL data being sent. > This is true but the spp app runs on top of the CM and this does not use this feature, it explicitly puts the device into the requested mode. > I was wondering if you can tell me what happens when > the device is put in park mode (I haven't been able to see anything about it > in the Bluelab documentation). > The link is parked (assuming the other end also supports park mode and has it enabled!) I'm afraid if you want a more specific answer you'll have to ask a more specific question > Also I was wondering if the Connection > Manager is set up so that when no ACL data is being sent it tries to keep > the link in park mode. > No the CM does not see the data and does not know when it is being sent. When you put data into the RFCOMM buffer BlueStack automatically unparks the link to send the data.. It then sends an event to the CM telling it the link is now active and the CM then tries to park the link (after a small timeout has expired) ------------------------------------------------- I try to configure bc03-mm board to enter in parked mode with Bluelab 2.95. When a ACL connection is established i send the following command, but blueStactk returns an error in DM_HCI_WRITE_LP_SETTINGS_COMPLETE. The error code is -29875 or unsignned 35661. I can't find this value in bluetooth specification. Can anybody help me? Thanks. MAKE_PRIM_T(DM_HCI_WRITE_LP_SETTINGS); prim->bd_addr = *addr; prim->link_policy_settings = 0x0008; prim->dm_policy = DM_LINK_POLICY_KEEP_PARKED; prim->u.park_settings.max_interval=1000; prim->u.park_settings.min_interval=100; prim->u.park_settings.park_idle_time=100; VmSendBlueStackPrim(DM_PRIM,prim); Там море информации. Настоятельно рекомендуют не пользоваться Парк модой. Говорят, что лучше Сниф. Рассказывают, что на конференциях по Блутусу упоминание о Парк моде вызывает хихиканье в зале. Поговаривали о том, чтобы убрать эту моду вообще. Может уже убрали.

Handsfree обязан иметь echo cancelation. Задача echo cancelation предотвратить прохождение того сигнала с микрофона, который только что был передан на громкоговоритель.

Знаю я, что КНИ низким будет, я просто вам вернул вашу фразу :) А по поводу усиления тока и напряжения почитайте здесь: http://en.wikipedia.org/wiki/Current-to-voltage_converter Вот преобразователь тока в напряжение: http://upload.wikimedia.org/wikipedia/en/e...Classic_300.jpg

Я когда-то делал это на CSR. Тогда это был BlueCore 01 и 02. Процедура была простая. К параллельному порту PC (тогда все PC имели порт принтера) подключались пять проводов, которые шли к SPI BlueCore. CSR поставляет программу BlueFlash, которая позволяет заливать апликации в BlueCore. Фирма, где я работал, купила BlueLab у CSR. Это позвлило иметь доступ ко множеству документов, скрытых на сайте CSR. Кроме того там есть множество рабочих апликаций на все случаи жизни. Там же скачиваются и инструменты для работы с BlueLab. Если название не изменилось, то набор инструментов называется Bluesuite, а программа, для записи апликации на чип называется BlueFlash. Она берет апликацию в специальном формате. Однако BlueLab компилятор настроен на генерацию выходного файла в нужном формате.

Внесу ясность. ООС через конденсатор в ОУ называется интегратор. И сделано оно для того, чтобы интегрировать входной ток. Потому как интеграл тока есть заряд. Но при наличии резистора R оно интегрирует напряжение, а вот если его убрать, то тогда будет ток. Резистор почему-то названный нагрузкой, ставят в интеграторах для ограничения дрейфа нуля, потому как при огромном усилении ОУ с разомкнутой ООС, дрейф может наинтегрироваться огого как. По сути это преобразователь заряда в напряжение. Но при наличии резистора R оно интегрирует напряжение, а вот если его убрать, то тогда будет ток. По сути это преобразователь заряда в напряжение. Формула, связывающая заряд, емкость и напряжение, показывает, что напряжение на выходе пьезодатчика пропорционально заряду. А значит усиление напряжения тоже подходит для измерения величины заряда. В режиме короткого замыкания, полагаю, высокочастотная составляющая сигнала будет менее ослаблена. Однако о ширине спектра речи не было. Если нужна простая схема, то лучше чем предложил Профессор не найти. Тем более, что пьезодатчики проигрывателей, работая на полевой транзистор давали неплохие высокие частоты. Алексашка, будем инженерами? Какой коэффициент нелинейных искажений у преобразователя заряда? Ведь операционный усилитель собран из сильно нелинейных транзисторов. :a14:

А вы перечитайте второе сообщение треда и увидите, что меня как раз это и напрягло.

Вот статья про эмиттерный повторитель говорит, что вторая гармоника 5*10^-5, а третья 5*10^-8. http://citeseerx.ist.psu.edu/viewdoc/downl...p1&type=pdf В полевике есть эффект подложки, который вносит нелинейность Судя по статье это будет 1.32% для второй гармоники. Однако при тех маленьких уровнях сигнала, что нам надо передавать, нелинейность будет значительно ниже. Но если это будет чрезвычайно принципиально, то в статье есть методы борьбы с нелинейностью. http://www.google.ca/url?sa=t&rct=j&am...b2I&cad=rja Об усилении заряда: Если надо измерять заряд, то надо сначала конвертитовать его в напряжение. Или хотябы ток конвертитовать в напряжение.

Из линейности истокового повторителя следует линейность такого усилителя напряжения: http://www.talkingelectronics.com/projects...es/image019.gif

Абсолютно ничто не линейно. Полевик нелинейный, а схема на полевике с отрицательной обратной связью линейна. Вы ведь не будете возражать, что данная схема линейна: http://upload.wikimedia.org/wikipedia/comm...ollower.svg.png

Куда ушли те времена, когда требовалось мастерство? Немерянной вычислительной силой можно все что угодно проломить. Зачем нам C++? Давайте сразу Java использовать.