artemkad

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

Не надо прямо держать - вставил, прижал на перекос, запустил запись, дождался окончания, вынул... Впрочем, помнится в случая записи GSM-модуля (3.5 минуты), роль перекашивающей руки выполняла бытовая резинка и плече силы уходящего в бок кабеля программатора. ЗЫ. Кстати, при шаге линейки в 1.27мм и числе контактов 4-6, там как-то о длине не задумываешься...

Наверное тем, что пины в пластиковой линейке не являются жесткой конструкцией и при приложении усилия ко всему разъему каждый пин в некоторой мере пружинит индивидуально. Кроме того, в отверстии квадрат пина имеет до четырех точек контакта острыми гранями об грани металлизированного стакана.

Что конкретно в этом не серьезного или иначе говоря - в чем проблема такого решения? Мы ведь не говорим об отладочном интерфейсе, а только об интерфейсе записи где надо удержать контакт только пару десятков секунд и отверстия в которые вставлена PLS-ка это обеспечивают. Что смущает, в чем несерьезность?

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

Зачем висеть под своим весом, если можно наклонить и прижать рукой? Для 15-30 секунд записи - никаких проблем.

Странно. Обычно Sim900 достаточно железобетонный и надо очень сильно постараться что-бы он начал себя так вести. Даже жаль что не докопались - все-же любопытно что привело к такому результату. Чуйка вангует, что что-то связанное с цепями карточки, но вполне может быть и, к примеру, КЗ по разъему антенны который приводит к наводке на хреново разведенные цепи карточки ....

Во время сеанса связи модуль имеет наибольшее импульсное потребление и если в ответ на него стабилизатор выдаст импульс напряжения ниже 3.2В или выше 4.8В, это может приводить к его отключению. С точки зрения карточки - в процессе обмена с модулем он внезапно отвалился. Собственно потому и посоветовал замкнуть предохранитель - вдруг китайцы сунули туда PolySwitch который в какой-то момент отрубает питание... Выбрасывание конденсаторов и микросхемы(на самом деле 4-х супрессоров) это убирание защиты от статики в которой китайцы могли взять элементы с большой емкостью, что опять-же приведет к хрени в процессе обмена карточки с модулем. ЗЫ. Есть еще возможные проблемы в разводке цепи карточки, но это требует фото разводки платы.

Куда? Замкни накоротко входной предохранитель, выпаяй три беленьких конденсатора стоящих на картинке рядом в ближайшем углу(вроде С1,2,4), c другой стороны выпаяй 6-ти ногую микросхему стоящую рядом с сим-держателем. Проверь что изменилось...

А что это добро отвечает на AT+CGMR ? Желательно иметь, но в принципе и конденсатора микрофарад на 10мкФ хватит.

Странный лог - ATE0 нет, но эха не наблюдается. 1. Дайте весь лог обмена. 2. Включите отчет о регистрации в сети At+CREG=1 или At+CREG=2 Подключите осциллограф к питанию модуля и проверьте нет ли провалов или выбросов напряжения в момент передачи USSD. А лучше вообще подключить модуль к литиевому АКБ... ЗЫ, И да, надеюсь команды модулю передаются 3В, а не 5В?

Телепатов и ясновидящих тут точно нет...

А я бы сказал - костыль. Вот именно. В каком-то смысле - да. За такт читается 8 слов которые при длине конвейера в 16 тактов за цикл успевает в пике затянуть до 128 слов. Вот только есть там куча "ма-а-аленьких" нюансов... В общем, если не вдаваться в подробности, без изначальной работы оптимизатора это эффективно работает с вероятностью 50/50... Само собой не смешно. Это заставляет задуматься, что не все то золото что блестит и суперскаляр с ООО или без это на самом деле игра на разности скоростей работы памяти и процессора. Более того, они показывают хоть какую-то эффективность для циклических алгоритмов целиком влезающим в кэш. Как только линейный участок кода становится крупнее L1 кэша, весь паровоз начинает упираться в скорость обмена между памятью и кэшем и на все остальные супернавороченные примочки ЦП кладется громадный болт.

Странное утверждение - суперскаляр это процессор способный одновременно выполнять несколько инструкций. OoO это всего лишь одна из особенностей суперскалярной архитектуры(наравне с переименованием регистров и объединением нескольких команд в одну инструкцию). Иначе говоря, все процессора с ОоО являются суперскалярами, но не все суперскаляры имеют ОоО. Назови модель с 512 битами? Первый ОоО это 1966 год (IBM360/91)

С этими игрушками - вряд-ли. Тут слишком много внимания уделено красоте навигации и мало практического смысла.

Именно так. Вот только если инструкции размещены удачно, то к моменту закачки аргументы их уже будут доступны, что приведет к минимальному времени исполнения, а если "как придется" - время исполнения тоже будет "как придется". Так вот, удачной расстановкой как раз и занимается оптимизатор кода. Что в Си, что в Форте и порядок там очень важен. Опять-же, я тут еще не вспомнил ту "мелочь", что это все речь о загрузке из кэша - если кэш-промах, и надо тянуть из ОЗУ, то там вообще печалька. И сколько сотен 16/32 битных команд процессор способен за одну выборку загрузить через 32- или хотя-бы 128(кэш)-битную шину? По моему ты путаешь загрузку и заполнение конвейера, такт и цикл... Выполняются - не факт, а вот загружаются(начинают обрабатываться) как и ранее последовательно слово за словом. Суперскаляр отличается лишь тем, что для загрузки следующего не ждет завершения обработки предыдущего.

Нужна среда разработки визуализирующая текущий контекст поиска(с разбивкой по словарям) с возможностью использования из него слов указание мышки, визуализация текущего словаря компиляции, необходимо расширить содержимое словарей добавив туда быстрый help по каждому слову, желательно иметь возможность там-же просмотра куска памяти и дизассемблирования, необходимо логирование действий.... Это больше должно быть похоже на отладчик современного IDE чем на его основное окно редактирования. И чего точно не надо, так это очередного редактора который по сути пытается впихнуть Форт в классическую схему где он однозначно проигрывает.

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

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

... (и как удалить?)

Тут кто-то говорит об идеальной стековой архитектуре? Где такая есть? Само собой после компиляции на регистровую архитектуру реального процессора ни о какой идеальной стековой речи не идет и несколько элементов стека будут в регистрах с соответствующей с ними работой. Собственно, после компиляции код работы с данными, для Форта компилирующего в нативный код, будет на малых кусках не сильно отличаться от кода создаваемого тем же Си, потому как он так-же использует двухстековую архитектуру с размещением на стеке данных всех локальных переменных.

Название хотя-бы парочки микросхем которые учитывают энергию, а не тупо работают по напряжению, можно?

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

Я не говорю о преимуществах или недостатках - я говорю о том откуда это пошло и исходя из этого почему оно так странно выглядит. Сейчас на него смотрят как на язык программирования, но исторически Форт был по сути системой управления сложным оборудованием. Зачем помнить - команда попадает в словарь и все доступные команды доступны для поиска и просмотра. Какое отношение декодирование и конвейерная обработка процессором имеет к написанию алгоритма работы с данными? Вам не кажется что это "слегка" разные уровни? А что мешает? В программе точка1 точка2 нарисовать_линию нет указаний через какой стек передаются координаты. Это может быть как стек данных, так и широкий стек координат.

Да ладно - вполне простые и понятные инструкции почти на уровне "Hello, world!". Вот если бы были конструкции типа 4\421341 , это да, без 100 грамм никак. Не совсем так. Суть Форта состоит в разрыве цикла компиляции. Т.е. изначально предполагался интерактивный режим работы с ПК(компиляция - как бонус позволяющий создавать новые инструкции). Т.е. если в классическом языке программирования человек пишет некий текст программы целиком, потом этот текст скармливает компилятору который делает из него исполняемый код, который затем запускается и наблюдается его работа, то в Форте изначально человек непосредственно запускает инструкции, результатом которых, в частности, могут быть скомпилированы новые инструкции каждую из которых можно исполнить. Результатом работы был не текст программы, а исполнимый кусок кода исполняющий требуемую задачу. Потому иногда и говорят, что на Форте не столько пишется программа, сколько выращивается Форт-система до уровня требуемой задачи. А стековая машина это всего лишь следствие передачи параметров между исполняемыми инструкциями без посредников в виде переменных. Т.е. подразумевается, что результат исполнения предыдущей инструкции принимает следующая. Крайне спорно. Ели конечно пытаться все прогнать через стек данных размером с ячейку, то да, но никто так не заставляет писать. К примеру, еще с 90-х для целочисленной арифметики использовали отдельный стек(по-факту стек сопроцессора), так почему не сделать еще стек для "широких данных"?