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

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

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

По iWRAPу удавалось достигать только 27КБайт/с, и то нестабильно... Означает. Насчёт подводных камней не скажу, но, чувствую что скоро сам буду их изучать... Про скорость блюгиги: http://electronix.ru/forum/index.php?showtopic=29507

Думаю что килобИты с килобАЙтами ещё никто попутать не успел... Слава богу... А число 180, если внимательно смотреть, относится к воооообще старой версии фирмвари, и, следовательно, обосновывать им 22Кб/с не логично. Предположим что пропускная способность ограничена упомянутым блю-гигой числом 300КБит/с, что относится к фирмваре 2.0.2. Предположим что мы его даже поооооочти достигли. Тогда появляется ещё один вопрос - почему же на модулях WT11 и WT12, которые описываются блю-гигой как BlueTooth 2.0 (а не 1.х) пропускная способность такая же?

хм... загадочно! WT12 блюгига раскручивает как BT2.0... Странновато, и немного пугающе, что и там такие проблемы... Вчера удалось достичь скорости 26.9 Кб/с за счёт не совсем корректной обработки CTS... Но, результат нестабильный... Ещё нашёл в старой доке по iWRAPу следующее: Сейчас одновременно пытаюсь двигаться в двух направлениях: перепрошивка модуля, и отключение escape sequence. Как получу результаты - напишу. P.S. И что, больше блютуз никто не гонял?

Возникла и у меня необходимость достичь максимальной скорости между двумя Wrap Thor -ами... Ситуация до боли похожа - один модуль на компе, а второй на LPC-хе... При стандартной скорости УАРТ-а в 115200 достигалась скорость непрерывной однонаправленной асинхронной передачи в 10-11 Кбайт/с. Скорость увеличил до 230400 - получил примерно 20-21 КБайт/с... Увеличил скорость до 460800 - получил порядка 24-х Кбайт/с. Дальнейшее увеличение скорости УАРТа до 921600 не привело к увеличению скорости передачи. Передача осуществляется по SPP (разумеется). Судя по БлюТузной спецификации скорость асинхронной передачи должна достигать ~700 КБит/с. Предположим, что за вычетом служебной информации это будет 500 КБит/с то есть около 60 КБайт/с. То есть получается, что практически достигаемая скорость значительно меньше теоретической. В данных тестах использую: Передаю данные блоками по 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

Кстати, не так то всё просто... В последнее время у них ужесточилась политика с регистрацией... Теперь они не хотят регистрировать с всяких-там @mail.ru и @yandex.ru... Требуют корпоративный мыл...

хм... У меня появилась проблема со схожими симптомами, но, похоже, что с другими причинами. Подключаю я через 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. Помогите, плиз!

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

Зачёт! Сам неделю назад становился на эти же грабли. Самое обидное, что в UM на LPC 213x написан !!! очень красивый!!! пример как нужно работать с I2C. И в нём сами филипсовцы не снимают STA бит. Гады!

Так, а если не секрет, в нормальном рабочем режиме он не должен быть на том же уровне что и земля? Так ведь?

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

Добрый день! Тренировал отправку СМС согласно мэнуалу "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")); Однако, хотелось бы знать - в чём проблема? И каким образом можно проверять готовность модема посылать СМСки?

Очень интересная идея! Посмотрел я описание SC16IS740 и других, и общие идеи мне понравились. Для совоупления с BlueGiga более всего подходит SC16IS740 - в нём меньше всего лишних ног. Однако, я не смог найти его в Украине (искал только chipfind-ом). Если не сложно, подскажите: 1) кто кроме NXP производит SPI2UART мосты? 2) где их можно приобрести на территории Украины?

Понятно! Спасибо за разъяснение! Скорость - не основная проблема. Проблема в отсутствии свободных UARTов... Приходится один UART контроллера делить между двумя модулями, и переключаться между ними с помощью ключей... Как при этом не провтыкать данные от одного из модулей ещё не до конца ясно. Но ничего, прийдётся прорываться :).