Перейти к содержанию

АдскийОдуванчик

Участник
  • Публикаций

    17
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о АдскийОдуванчик

  • Звание
    Участник
  1. провода и подпайка к LQFP64

    Спасибо, ребята! Посмотрев на картинку понял что моя проблема - это совсем не проблема. Теперь буду ждать доставку всего заказанного, молиться, и паять.
  2. провода и подпайка к LQFP64

    Добрый день, уважаемые форумчане! Прошло уже около 10 лет с тех пор как я держал в руках паяльник. И вот, мой старый и добрый HDD Samsung S1 Mini со всеми семейными фотками стал отбрасывать копыта. Его ЮСБ интерфейс пришёл в негодность - при попытке чтения с диска диск теряется как устройство. И на просторах интернета я нашёл решение от людей встречавшихся с подобной проблемой - выпаивать JM20335 и вместо него впаивать кабель/разъём Parallel ATA. А дальше разбираться как со стандартным битым диском. Проблема в одном - JM20335 исполнен в корпусе LQFP64, и на чуть более чем 1 см приходится 16 ножек. Вместо которых придётся паять провода. Стал искать провода с малым сечением, и наткнулся на 0.1 - 0.2 мм Solderable Enamelled Copper Wire. По русски "паябельные эмалированные медные провода". Подскажите пожалуйста, гарантирует ли эта эмаль изоляцию между проводами? И если есть на примете какие-то альтернативные решения для подпайки к мелким пинам - подскажите плиз.
  3. ПО для модулей BlueGiga

    Цитата(EDMOS @ Sep 11 2007, 12:55) насколько я понял теорию, модули с iWRAP работают сугубо через RFCOMM, а у него ограничение 700 с чем-то кбит\с. в то же время мануалы гласят: EDR за счёт хитрой модуляции позволяет достичь 2 и выше Мбит\с. По iWRAPу удавалось достигать только 27КБайт/с, и то нестабильно... Цитата(EDMOS @ Sep 11 2007, 12:55) означает ли совокупность двух вышеприведённых фактов, что желаемую скорость я получу только используя HCI? какие подводные камни меня при этом могут ожидать? Означает. Насчёт подводных камней не скажу, но, чувствую что скоро сам буду их изучать... Про скорость блюгиги: http://electronix.ru/forum/index.php?showtopic=29507
  4. Как получить 300 Kbit/sec по Bluetooth?

    Цитата(rezident @ Sep 6 2007, 21:21) Вы килобиты с килоБайтами как часто путаете? То вам нужно то уже 100кБайт/с=800кбит/с или у вас как-то по-другому? В то же время сами выдаете 22кБайт/с=176кбит/с что больше половины от изначально желаемых 300 кбит/с и близко к упомянутым Адским Одуванчиком 180кбит/с или опять я неправильно посчитал? Думаю что килобИты с килобАЙтами ещё никто попутать не успел... Слава богу... А число 180, если внимательно смотреть, относится к воооообще старой версии фирмвари, и, следовательно, обосновывать им 22Кб/с не логично. Предположим что пропускная способность ограничена упомянутым блю-гигой числом 300КБит/с, что относится к фирмваре 2.0.2. Предположим что мы его даже поооооочти достигли. Тогда появляется ещё один вопрос - почему же на модулях WT11 и WT12, которые описываются блю-гигой как BlueTooth 2.0 (а не 1.х) пропускная способность такая же?
  5. Как получить 300 Kbit/sec по Bluetooth?

    Цитата(subver @ Sep 5 2007, 04:47) У меня тоже максимум было 24 кбайт/сек, на скорости порта 460800 модуль WT12 хм... загадочно! WT12 блюгига раскручивает как BT2.0... Странновато, и немного пугающе, что и там такие проблемы... Вчера удалось достичь скорости 26.9 Кб/с за счёт не совсем корректной обработки CTS... Но, результат нестабильный... Ещё нашёл в старой доке по iWRAPу следующее: Цитата4.5 300kbps Throughput The throughput of iWRAP has been dramatically increased. The maximum throughput with iWRAP 2.0.2 version is around 300kbps when ASCII interface 2.0.0 was able to produce only 180kbps. However to achieve this throughput the use of DTR signaling is needed. Сейчас одновременно пытаюсь двигаться в двух направлениях: перепрошивка модуля, и отключение escape sequence. Как получу результаты - напишу. P.S. И что, больше блютуз никто не гонял?
  6. Как получить 300 Kbit/sec по Bluetooth?

    Возникла и у меня необходимость достичь максимальной скорости между двумя Wrap Thor -ами... Ситуация до боли похожа - один модуль на компе, а второй на LPC-хе... При стандартной скорости УАРТ-а в 115200 достигалась скорость непрерывной однонаправленной асинхронной передачи в 10-11 Кбайт/с. Скорость увеличил до 230400 - получил примерно 20-21 КБайт/с... Увеличил скорость до 460800 - получил порядка 24-х Кбайт/с. Дальнейшее увеличение скорости УАРТа до 921600 не привело к увеличению скорости передачи. Передача осуществляется по SPP (разумеется). Судя по БлюТузной спецификации скорость асинхронной передачи должна достигать ~700 КБит/с. Предположим, что за вычетом служебной информации это будет 500 КБит/с то есть около 60 КБайт/с. То есть получается, что практически достигаемая скорость значительно меньше теоретической. В данных тестах использую: ЦитатаWRAP THOR AI (version 2.0.2 build 519 $) Copyright © 2003-2005 Bluegiga Technologies Inc. Compiled on Apr 8 2005 18:58:04 - DoppelBOCK version 1.1.0 build 210 (2/2c) - Bluetooth version 1.2, Power class 1 - Firmware version 1503 Передаю данные блоками по 256 байт, проверяя CTS между блоками: Кодwhile(1) {   передал 256 байт;   while (!CTS) {;} } Кто нибудь может теоретически объяснить полученное мною ограничение скорости, или опровергнуть его? Есть ли какие-нибудь варианты как скорость увеличить? Вызываю всех на дискуссию! В дополнение опишу грабли, на которые я успешно наступал во время баловства с WrapThor-ом, и некоторые другие встретившиеся проблемы, во избежание наступления на них кем-либо ещё... 1) Стандартный PC-шный COM-port ограничил меня 115200. Пришлось использовать Serial-over-USB. Милый переходничок PL-2303 снял данное ограничение. Удалось запустить Wrap Thor на 921600. 2) MAX3232, подтягивающий УАРТ до RS-232, имеет ограничение по скорости... Это то ли 230400, то ли 460800... Для больших скоростей я использовал MAX3237. Кстати, может кто-то подскажет какие ещё есть альтернативы MAX3237? 3) В связи с двумя выше описанными причинами я неоднократно загонял WRAP THOR в состояние в котором я не мог до него достучаться (он ждал 460800, а хардварная обвязка допускала не более 230400). К моему большому сожалению подключаться к нему по SPI чтобы стирать настройки было некогда и нечем... На этот случай родилось следующее решение: SET CONTROL INIT SET CONTROL BAUD 115200,8n1
  7. ПО для модулей BlueGiga

    Цитата(Starick @ Feb 1 2007, 17:43) Сейчас тоже юзаю модули BlueGiga, WT11. Хорошие штучки. А скачать всю инфу и ПО по ним и для них на сайте-производителя. Только нужно зарегестрироваться, и они через пару рабочих деньков высылают логин и пароль. Мне выслали через день. На счет серии WT 1x, они могут идти с так называемой iWRAP оболочкой , так и "голый" HCI. Кстати, не так то всё просто... В последнее время у них ужесточилась политика с регистрацией... Теперь они не хотят регистрировать с всяких-там @mail.ru и @yandex.ru... Требуют корпоративный мыл...
  8. MAX3100

    хм... У меня появилась проблема со схожими симптомами, но, похоже, что с другими причинами. Подключаю я через max3100 блютузку... Пытаюсь на оную послать строку: INQUIRY 5 NAME#d#a. В результате, после получения символа #0a блютузка отдаёт мне строку, которую она получила, и говорит что в ней синтаксическая ошибка. Посмотрев на строку, я согласился. INUR AE#a(два пробела) То есть, до блютузки дошли первый, и все чётные символы... А нечётные ушли в небытие... Посылка осуществляется по spi-ному прерыванию следующим образом: (изначально запихнули read config и из ответа получили R и T) Если T то посылаем (write data) Иначе посылаем dummy_write (write data с битом nTE = 1) Трассировка показала на следующее поведение: шаг 1) T=1, посылаем "I" (0x8249) шаг 2) T=1, посылаем "N"(0x824E) шаг 3) T=1, посылаем "Q"(0x8251) <<--<<--<<-- шаг 4) T=0, посылаем dummy write (0x8600) шаг 5) T=0, посылаем dummy write (0x8600) шаг 6) T=0, посылаем dummy write (0x8600) шаг 7) T=0, посылаем dummy write (0x8600) шаг 8) T=1, посылаем "U"(0x8255) шаг 9) T=1, посылаем "I"(0x8249) <<--<<--<<-- шаг 10) T=0, посылаем dummy write (0x8600) шаг 11) T=0, посылаем dummy write (0x8600) шаг 12) T=1, посылаем "R"(0x8252) шаг 13) T=1, посылаем "Y"(0x8259) <<--<<--<<-- шаг 14) T=0, посылаем dummy write (0x8600) шаг 15) T=0, посылаем dummy write (0x8600) шаг 16) T=1, посылаем " "(0x8220) шаг 17) T=1, посылаем "5"(0x8235) <<--<<--<<-- шаг 18) T=0, посылаем dummy write (0x8600) шаг 19) T=0, посылаем dummy write (0x8600) шаг 20) T=1, посылаем " "(0x8220) шаг 21) T=1, посылаем "N"(0x824E) <<--<<--<<-- шаг 22) T=0, посылаем dummy write (0x8600) шаг 23) T=0, посылаем dummy write (0x8600) шаг 24) T=1, посылаем "A"(0x8241) шаг 25) T=1, посылаем "M"(0x824D) <<--<<--<<-- шаг 26) T=0, посылаем dummy write (0x8600) шаг 27) T=1, посылаем "E"(0x8245) шаг 28) T=1, посылаем "#d"(0x820d) <<--<<--<<-- шаг 29) T=0, посылаем dummy write (0x8600) шаг 30) T=0, посылаем dummy write (0x8600) шаг 31) T=1, посылаем "#a"(0x820a) Посылки помеченные (<<--<<--<<--) не дошли до блютуза... Долго думал в чём причина... Пробовал вместо записи 0x8600 делать чтение 0х0000, однако результат был таким же самым... Есть ли у вас какие-либо варианты решения или обоснования причины данной проблемы? Наверняка кто-то уже успешно запускал MAX3100. Помогите, плиз!
  9. SIM508

    Подключил SIM508 по SIRF. Начали сыпаться 4-е и 9-е сообщения... Возникли вопросы... 1) Почему-то постоянно валит 9-ое сообщение... Зачем оно вообще нужно? 2) В какой последовательности правильно инициализировать GPS (колд старт)? И через сколько ждать координаты (id=2)? По-поводу мэнуала - одни маты... Понять по нему (с нуля) как с GPS работать - не детская задача...
  10. i2c в lpc2378

    Цитата(Ivan_Kov @ Mar 6 2007, 09:42) Все дело оказалось в том, что я не снимал флаг STA (старт) регистра I2CON. Поэтому после передачи адреса, контроллер i2c передавал повторный сигнал старта. В мануале очень подробно описана процедура работы с i2c, но необходимость снятия этого флага не упоминается прямо, лишь косвенно. Это меня и сбило с толку. Зачёт! Сам неделю назад становился на эти же грабли. Самое обидное, что в UM на LPC 213x написан !!! очень красивый!!! пример как нужно работать с I2C. И в нём сами филипсовцы не снимают STA бит. Гады!
  11. Debug port в LPC2134

    Цитата(etoja @ Apr 13 2007, 13:02) TDO легко выжигается при передёргивании разъёма JTAG при включенном питании процессора и MT-Linka. Для уменьшения вероятности такого события рекомендуется следующая схема между MT-Link и контактами JTAG процессора: Так, а если не секрет, в нормальном рабочем режиме он не должен быть на том же уровне что и земля? Так ведь?
  12. Debug port в LPC2134

    Сегодня, после долгой и успешной работы MT-Link с LPC2134 появились проблемы. При прошивке IAR стал кричать что core id = 0. Начал всё щупать. Кабель живой, все контакты где надо... Кроме TDO. По какой-то магии TDO на проце оказался прямо завязан на землю. Тестер радостно пищал... Я злостно матерился... SUBJ: Сигнал TDO на LPC 2134 законтачен на землю (внутри самого LPC 2134). В чём может быть причина? Или может это нормально, а дураком являюсь я сам? Подскажите пожалуйста! Если у кого-нить есть рабочие LPCхи, померяйте, пжлст, сопротивление между TDO и землёй в выключенном состоянии...
  13. SIM300C/SIM508 +CME ERROR: 769

    Добрый день! Тренировал отправку СМС согласно мэнуалу "SIM300 Application Notes_v1.2.pdf" и столкнулся с проблемой: команда AT+CSMP отвечает ошибкой "+CME ERROR: 769". В мануале по AT коммандам нашёл оччень скромное описание ошибки: "unable to get control of required module" которое мне совершенно не прояснило суть проблемы. Данная ошибка проявляется только в первые 40-80 секунд работы модема, а после этого пропадает. Сейчас добавил простой цикл, проверяющий, когда данная ошибка пропадёт. do {//Waiting for magic response SendATCommand("AT+CSMP?"); } while (CheckATResponse("+CME ERROR: 769")); Однако, хотелось бы знать - в чём проблема? И каким образом можно проверять готовность модема посылать СМСки?
  14. SPI в BlueGiga

    Цитата(globalist @ Mar 29 2007, 10:44) А если и свободного порта нет, тогда применяйте I2C/SPI -> UART SC16IS740,750,752,760,762, отличие в скорости и количестве портов. Вот ссылки: http://www.standardics.nxp.com/products/br...uart.irda.gpio/ http://www.standardics.nxp.com/literature/...t.irda.gpio.pdf Очень интересная идея! Посмотрел я описание SC16IS740 и других, и общие идеи мне понравились. Для совоупления с BlueGiga более всего подходит SC16IS740 - в нём меньше всего лишних ног. Однако, я не смог найти его в Украине (искал только chipfind-ом). Если не сложно, подскажите: 1) кто кроме NXP производит SPI2UART мосты? 2) где их можно приобрести на территории Украины?
  15. SPI в BlueGiga

    Цитата(globalist @ Mar 27 2007, 23:37) Ха! Вот теперь понятно. В первый раз Вы не совсем корректно задали вопрос. И из-за этого все предыдущие ответы можете забыть. Я изначально так понял, что Вы спрашиваете можно ли в модулях BlueGiga использовать SPI для связи с модулем. Естесственно ответ был - можно. Теперь я понял по приведенному примеру, что Вас интересует можно ли использовать SPI при работе с iWRAP. Тогда ответ другой - нельзя! Во всяком случае так говорит документация к iWRAP. Если же Вы решите разбираться с HCI уровнем - можете работать с SPI. Кстати, последний firmware позволяет работать со скоростью до ~260000 bps при настройках PC порта UART: 460800,8n1 Half-duplex transmission Escape sequence disabled (если, конечно, чипсет поддерживает) - так может быть SPI не так уж и нужен? Понятно! Спасибо за разъяснение! Скорость - не основная проблема. Проблема в отсутствии свободных UARTов... Приходится один UART контроллера делить между двумя модулями, и переключаться между ними с помощью ключей... Как при этом не провтыкать данные от одного из модулей ещё не до конца ясно. Но ничего, прийдётся прорываться .