DpInRock

Паять ничего не надо. Параллельно лампочке в туалете: 1. Сирена 90 dB, 30kHz (тридцать). А около себя держите кота или собаку. Если они бегают туда-сюда - туалет занят. 2. Ноутбук без аккумулятора, но с вайфай. По своему роутеру смотрите, если комп в сети - значит занято. Кстати, заодно и сервис. Не надо с собой литературу носить. 3. Поставить стол и стул около туалета с ноутбуком. Если занято, есть чем заняться. 4. Просто поставить стул без ноутбука. А ноутбук брать с собой (кто ж в туалет без ноута ходит?)

Прочитайте пост xenia. Яснее быть не может. Выдернуть руками 2 штекера. Из материнки. Потом вставить обратно. Но только на соседнее место каждый.

10k замените на 1k 1%.

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

Ничего нормального не вижу. Вами управляют конфигурационные файлы.

Samba, например. Либо, если вы программист, напишите свой загрузчик. Там очень простой интерфейс по 232. Примерно 40 значащих строк на паскале.

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

Насколько подробней? При анализе помогает знание того, чем занимается процессор в то или иное время. Постоянный READ означает, что процессор все время читает нечто из внешней памяти. Какой именно - неизвестно. Требуется анализ других сигналов. Кроме того, если вы собрались отлаживать плату, то совершенно кошерно - закачать себе даташит. Там в подробностях рассказано, что именно делает этот процессор после подачи на него питания. Глава называется Boot. Пересказывать ее тут нет никакого смысла. -- Кстати, из даташита можно будет всязть и настоящие наименования сигналов. Ибо что такое READ можно только догадываться.

Там еще небольшая кучка сигналов имеется. В частности, выборка кристалла. На линиях данных что-то должно быть. Ну, а описанная вами ситуация (сигнал READ идет постоянно) скорее всего не соответствует действительности.

Ну или так. Хотя чисто лично я отладку всегда держу вместе с боевым кодом. Не делю. Ну чисто вот по жизни. Изменение кода требует проверки программы. Ибо чудеса никто не отменял. Поэтому я лично код не меняю. А отладка через посл. порт отнимает очень мало ресурсов.

Нет. Он звучит так: Как написать собственную функцию printf с выводом на ... (comport, экран ) нужное подчеркнуть.

Ага. Объясняю. Обычно время интегрирования сигнала датчика лежит в районе 300 мс. Это длительность слова Hello. Для пожарных датчиков контролируется сопротивление шлейфа 2.2 - 5.4 килоома. Обрыв - это более 16 ком, КЗ = менее 100 ом. Для охранных также контролируется 10%% изменение установившегося значения. Но это можно отбросить. У человека пожарные дымовые датчики. Ни о каких миллисекндах речи не идет и идти не может. Прикинтье длину проводов, емкость и количество 50 герцовых наводок от перфораторов, лифтов и прочего. Для более точного анализа требуется знать какой "приемно-контрольный прибор" (это ключевое слово для гугла и охранника) установлен в доме.

Закоротите провода резистором 5.6Kна входе. Потом режьте. http://labofbiznes.ru/psd_shlf_pog.html

На момент проверки - вся память стерта. Имеется только образ загружаемых программ. То, что память (неиспользуемая) содержит ФФ -проверено. Линукс стартует впервые.

Интересует алгоритм проверки NAND на плохие блоки. Есть такая проблема. Линукс использует NAND для загрузки, а остаток под диск. Процессор Да Винчи от Техас загружает загрузчик линукса (U-boot), который грузит линукс (Монтависта). NAND имеет сигнал готовности, подключенный к процессору неким стандартным образом. Вот если его снаружи закоротить на землю, то Да Винчи не грузит начальный загрузчик. Если дать процессору загрузить начальный загрузчик и чтоб запустился U-boot, а потом закоротить готовность, то U-boot останавливается (после убирания закоротки - продолжает как ни в чем не бывало). Но. Далее запускается линукс и в процессе работы сканирует эту NAND на бэдблоки. Так вот. В этот момент ему глубоко наплевать на состояние сигнала готовности. Он сканирует, находит пару-тройку блоков и идет себе дальше, монтирует на флэшке диск и прочая. Т.е. работает в свое удовольствие. Работу приложения с этим диском я не проверял, ибо совершенно не разбираюсь в линуксе, да и средств таких у меня нет. --- Отчего возник вопрос. Бэд блоки, который находит линукс на старте временами разные. Временами их много (до 1000). Временами их нет вовсе. Проверка флэшки руками (своей программой) не выявила блоков, которые повреждены или больше не записываются. Косвенно это подтверждается тем, что я все-таки Линукс пишу в эту флэшку своими средствами. И при старте оно проверяет контрольные суммы и говорить - ОК. -- Флэшка NAND01G-B2B от StM Проц - TMS320D6443.

Гвозди из таких людей делать. Или шурупы.

Это МНЕ они видны явно. А юзеру линукса они могут быть вообще не видны. И могут как не проявляться совсем, так и проявляться постоянно. -- А редкие зависания, по моему опыту, связаны только с программой. Обычно, когда разводишь по первому разу - стараешься соблюсти. Потом разводишь абы как. Один черт работает.

Чтобы убрать вопросы разводки - коротните последовательные резисторы сверху проводком. Давно когда-то имел траблы связанные с этими резисторами. (То ли непропай, то ли что - разбираться до конца не стал). Первым делом их коротнул и все заработало. С тех пор ставлю эти резисторы, если заказчик на этом настаивает. Т.е. делаю все без резисторов. Влючая DDR2. Клок развожу игреком. Все остальное - как попало, но с воротами по длине 10 мм. Ну и к слову. Один из заказчиков который настоял на резюках щас мучается тем, что эти сборки 0204 у него не умеют паять и ему их приходится у каждой третьей платы перепаивать... (Правда в данном случае неработа выражается в стабильных глюках памяти, типа, кототящие адресные линии, коротящие данные и прочая. Один из глюков, котоый по виду напоминает ваш - это мпладщая половина памяти работает и в старших адресах. И при попытках линукса что-то себя выделить в врехних адресах приводит к убийству младших.-- после чего все висит мертво.)

STMFD http://www.gaw.ru/html.cgi/txt/doc/micros/...arm/ldm_stm.htm LDR http://www.gaw.ru/html.cgi/txt/doc/micros/...arm/lds_str.htm Мышка не работает?

TFT экраны могут снабжаться, разумеется, разным интерфейсом. Но только RGB bynthatqc дает реальный прямой доступ к цвету. И разрядность этого интерфеса сразу скажет о его глубине. Вместо даташита вполне можно найти сервис мануал на этот телефон. Который найти вполне себе можно. На самом шлейфе этого телефона написан его партнамбер. Тоже можно поискать. У продавцов запчастей тоже можно спросить (такой экран стоит примерно 600 руб). P.S. Формулировка вопроса - трудное дело. И если человек не прилагает к этому усилий, то вопрос обязательно будет глупым. И это, разумеется, не зависит от степени интеллекта вопрошающего, а зависит исключительно от его ЧСВ (lurkmore.ru)

http://www.gaw.ru/html.cgi/txt/doc/micros/...m_arm/field.htm http://www.gaw.ru/html.cgi/txt/doc/micros/...asm_arm/app.htm

Вам кроме даташита ничьи советы не помогут. Можно было бы поинтересоваться количеством свободных контактов у дисплея, и из этого делать вывод. Можно практически, найдя свободные (условно свободные, которые на земле или на плюсе) контакты подавать на них статические уровни и смотреть как меняется яркость конкретных составляющих. Если меняется в соостветствии с этими уровнями, то дисплей 24 разрядный. Это к примеру. Как сделать без даташита. Но для этого нужно много чего еще, чего у вас нет. Посему и этот совет вам не под силу осуществить. Значит остается даташит. --- P.S. Южный парк - замечательный мультик. Закаляет чувство юмора.

http://www.gaw.ru/html.cgi/txt/doc/micros/..._arm/survey.htm

Вот скачаете даташит на дисплей и узнаете.

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