Ок, пусть и не самым удобным образом запястье выворачивать, но ради избавления от этого иногда возникающего «неудобства» постоянно носить на ремешке какую-то дополнительную приблуду, которую ещё и заряжать отдельно надо??
Справедливости ради, 115200 - как раз таки очень распространённая скорость, а вот какие-нибудь 1.5-2мбод (CH340 такое поддерживает) были бы действительно нетипичны (как и противоположная крайность - 50бод).
Ретаймеры - плюс к цене, а при длинах до 0.8м они не нужны. Соответственно, те, кому хватает дистанций до 0.8м, не платит за них ни в кабеле, ни в устройстве, кому не хватает - платит за них в цене более длинного кабеля. В устройстве же за них платили бы и те и те.
Вспомнилось: есть ещё младшее семейство, FX3, на базе уязвимых STM32, их китайцы вовсю копируют и на Али продают. У них, случайно, кодовая база с FX5 не общая? Возможно, удалось бы сдампить прошивку FX3 и почерпнуть из неё что-то применимое на FX5, чем чёрт не шутит?
Трэвис в своём посте без экивоков вроде «сходства в прошивках» прямо говорит «это украденный NEC, только silicon art разработчика удалили», и если смотреть то на одно, то на другое фото кристалла, огромное сходство в топологиях очевидно, и в схемах таких масштабов такое не получается «просто потому, что у микросхемы те же функции», это именно копирование топологии. В качестве контрпримера копирования только функционала, но в своей разработке, можно здесь посмотреть фото различных китайских клонов STM32F103, топологии у них довольно разные, это больше «AMD K5 вместо Intel Pentium».
Через «запредельные» DevOff к самой прошивке не подобраться? Или к какой-нибудь области RAM, где мелькает ключ обновления в процессе установки? Наверняка же попробовали :)
Да, это самодеятельность NAND-контроллера. К примеру, из него наружу хотят классическими секторами по 0x200, сам NAND имеет страницы по 16К, контроллер использует схему ECC по 11 байт на сектор - ну и чхать ему на некрасивые смещения, забивает физические 16K кусками данные+ECC по 0x20B байт подряд без стыков, не разбираясь, где там по задумке производителя NAND данные, где spare, у него в сторону NAND потоковый интерфейс со счётчиками байтов, разделяющий данные/ЕСС на лету, достаточно только задать ему размеры того и другого. Плюс, внимание, где-то не в начале и не в конце физ. страницы может находиться bad block marker (!=FF - блок дефектный, смещение определяет производитель, он сразу на фабрике помечает дефектные блоки. Смещения встречались ну очень некруглые), приличный NAND-контроллер и его на лету отделяет, как ни в чём ни бывало. В итоге на самом нижнем уровне формат может быть ну очень причудливым.
И вишенкой на торте: в NAND, с которого какой-нибудь SoC напрямую грузится в embedded Linux, запросто может быть несколько зон с разными форматами страниц: BootROM понимает какой-нибудь свой причудливый формат, первичный загрузчик записан в нём, вторичным взяли какой-нибудь готовый U-Boot, организующий софтово свой формат, ядро Linux лежит в нём, а в самом ядре в драйвере ФС ещё какой-нибудь третий, и ФС - в нём :)
Красота! Трюк с исправлением битов, ориентируясь на CRC, отдельно порадовал. Жду продолжения!
"Шифрование" NAND - не ради сокрытия, а просто чтобы устранить длинные последовательности одинаковых битов (в NAND высокой плотности такие сгустки зарядов могут портить соседние биты), стандартная функция многих NAND-контроллеров. И та странность с другими сидами в каждом n-ном блоке, возможно, учитывает физическую организацию некой конкретной модели NAND. Алгоритмы эти, бывает, всплывают на форумах Acelab и подобных софтов по восстановлению данных.
Попробуйте найти «старое» колесо от G30 (просите продавца показать серийный номер - должен на 6 начинаться), у них намотка «тяговая». У более новых (номера на 9) уже «скоростная» намотка. В профильных ТГ-группах время от времени появляются желающие избавиться от «шестого» колеса (т.к. большинство гонится за скоростью). Они действительно очень хорошо тянут (всё субъективно конечно, сравнивал крутизну наших склонов с вашим по фото).
По поводу сгорания транзисторов при торможении - а дело, часом, не в BMS? Многие BMS с самокатов попроще выполнены по однопортовой схеме (зарядный и разрядный ключи стоят последовательно между ячейками и общим зарядно/разрядным портом), при особо интенсивном рекуперативном торможении такие BMS видят превышение напряжения на ячейках, закрывают зарядный ФЕТ, отсекая рекуперацию, у инвертора резко пропадает нагрузка и напряжение взлетает до небес. Для сравнения, как всё реализовано в более приличных Ninebot/Xiaomi: зарядный и разрядный порты разделены, разрядный отделён от ячеек только разрядным ключом, отсечь заряд (т.е. рекуперацию) через него BMS вообще не способна, при превышении напряжения она просто сообщает об этом контроллеру и тот уже программно снижает ток торможения до тех пор, пока BMS не перестанет «жаловаться».
В простейшем случае программа просто писалась с расчётом на 32-битность и плоскую модель, собиралась Watcom C(++), компоновщик которого сам ваш код компоновал в формат LE (OS/2 Linear Executable), затем добавлял к нему DOS MZ заголовок и сам DOS/4GW как DOS stub. При запуске получившегося ехе первым получал управление DOS/4GW (т.к. DOS не понимал формат LE и видел только MZ часть), который, как и описано в статье, искал уже работающий DPMI-сервер (через прерывание INT 2F, закреплённое за DPMI), при отсутствии оного сам «вешался» на это прерывание, а дальше через функцию того же INT 2F (обрабатываемую либо самим DOS/4GW, либо «чужим» DPMI-сервером) переходил в защищённый режим, через функции INT 31 (DPMI API уже в 32-битном режиме, DPMI-сервер и его должен обрабатывать) выделял память под пользовательскую программу, загружал её туда (разбирая уже LE-часть) и в конце концов «прыгал» на пользовательскую точку входа, указанную в LE-заголовке.
Другая часть «магии» Watcom находилась в его стандартной библиотеке, которая «заворачивала» работу с файлами/консолью в вызовы DOS через функции всё того же INT 31, выделяла/освобождала память опять же через INT 31 итд.
Если программе не требовалось что-нибудь низкоуровневое вроде установки обработчика прерывания, прямого доступа к видеобуферу и подобного, она выглядела как самый обычный С/С++. Для низкоуровневых же вещей требовалось уже вручную вызывать всё тот же INT 31.
Ок, пусть и не самым удобным образом запястье выворачивать, но ради избавления от этого иногда возникающего «неудобства» постоянно носить на ремешке какую-то дополнительную приблуду, которую ещё и заряжать отдельно надо??
Справедливости ради, 115200 - как раз таки очень распространённая скорость, а вот какие-нибудь 1.5-2мбод (CH340 такое поддерживает) были бы действительно нетипичны (как и противоположная крайность - 50бод).
А ещё с «недоливом» на «мутных» заправках забавно будет - машина то теперь в состоянии со своей стороны не менее точно считать «залитое»
Avioneta - однозначно испанский
А вдруг MiFare Classic дырявую поставили? Flipperом бы каким-нибудь прощупать их.
Пальцем в небо: а гравитация не почувствуется? С одной стороны, тонна - ерунда, с другой - пролетая прямо сквозь тело, она будет ну очень близко.
Интересно, во времена луддитов кто-то тоже разрабатывал какие-нибудь «кувалды для более эффективного разрушения станков»? </sarcasm>
Ретаймеры - плюс к цене, а при длинах до 0.8м они не нужны. Соответственно, те, кому хватает дистанций до 0.8м, не платит за них ни в кабеле, ни в устройстве, кому не хватает - платит за них в цене более длинного кабеля. В устройстве же за них платили бы и те и те.
В комментариях к оригинальной статье пишут, что это - ретаймеры для высокоскоростных линий, т.е. полезное.
В догонку ремастер Hexen
В ГУ Zeekr творятся сущие чудеса гибридизации: Android работает в… паравиртуализованном контейнере внутри QNX!
Вспомнилось: есть ещё младшее семейство, FX3, на базе уязвимых STM32, их китайцы вовсю копируют и на Али продают. У них, случайно, кодовая база с FX5 не общая? Возможно, удалось бы сдампить прошивку FX3 и почерпнуть из неё что-то применимое на FX5, чем чёрт не шутит?
Трэвис в своём посте без экивоков вроде «сходства в прошивках» прямо говорит «это украденный NEC, только silicon art разработчика удалили», и если смотреть то на одно, то на другое фото кристалла, огромное сходство в топологиях очевидно, и в схемах таких масштабов такое не получается «просто потому, что у микросхемы те же функции», это именно копирование топологии. В качестве контрпримера копирования только функционала, но в своей разработке, можно здесь посмотреть фото различных китайских клонов STM32F103, топологии у них довольно разные, это больше «AMD K5 вместо Intel Pentium».
Очень увлекательно, спасибо, что делитесь!
Через «запредельные» DevOff к самой прошивке не подобраться? Или к какой-нибудь области RAM, где мелькает ключ обновления в процессе установки? Наверняка же попробовали :)
Да, это самодеятельность NAND-контроллера. К примеру, из него наружу хотят классическими секторами по 0x200, сам NAND имеет страницы по 16К, контроллер использует схему ECC по 11 байт на сектор - ну и чхать ему на некрасивые смещения, забивает физические 16K кусками данные+ECC по 0x20B байт подряд без стыков, не разбираясь, где там по задумке производителя NAND данные, где spare, у него в сторону NAND потоковый интерфейс со счётчиками байтов, разделяющий данные/ЕСС на лету, достаточно только задать ему размеры того и другого. Плюс, внимание, где-то не в начале и не в конце физ. страницы может находиться bad block marker (!=FF - блок дефектный, смещение определяет производитель, он сразу на фабрике помечает дефектные блоки. Смещения встречались ну очень некруглые), приличный NAND-контроллер и его на лету отделяет, как ни в чём ни бывало. В итоге на самом нижнем уровне формат может быть ну очень причудливым.
И вишенкой на торте: в NAND, с которого какой-нибудь SoC напрямую грузится в embedded Linux, запросто может быть несколько зон с разными форматами страниц: BootROM понимает какой-нибудь свой причудливый формат, первичный загрузчик записан в нём, вторичным взяли какой-нибудь готовый U-Boot, организующий софтово свой формат, ядро Linux лежит в нём, а в самом ядре в драйвере ФС ещё какой-нибудь третий, и ФС - в нём :)
Красота! Трюк с исправлением битов, ориентируясь на CRC, отдельно порадовал. Жду продолжения!
"Шифрование" NAND - не ради сокрытия, а просто чтобы устранить длинные последовательности одинаковых битов (в NAND высокой плотности такие сгустки зарядов могут портить соседние биты), стандартная функция многих NAND-контроллеров. И та странность с другими сидами в каждом n-ном блоке, возможно, учитывает физическую организацию некой конкретной модели NAND. Алгоритмы эти, бывает, всплывают на форумах Acelab и подобных софтов по восстановлению данных.
Ну не "упрощать" же "непростое время" в конце то концов.
Наконец то! Неофициальные сервисы аж целые лазерные гравёры покупали ради удаления этих несчастных стёкол.
Попробуйте найти «старое» колесо от G30 (просите продавца показать серийный номер - должен на 6 начинаться), у них намотка «тяговая». У более новых (номера на 9) уже «скоростная» намотка. В профильных ТГ-группах время от времени появляются желающие избавиться от «шестого» колеса (т.к. большинство гонится за скоростью). Они действительно очень хорошо тянут (всё субъективно конечно, сравнивал крутизну наших склонов с вашим по фото).
По поводу сгорания транзисторов при торможении - а дело, часом, не в BMS? Многие BMS с самокатов попроще выполнены по однопортовой схеме (зарядный и разрядный ключи стоят последовательно между ячейками и общим зарядно/разрядным портом), при особо интенсивном рекуперативном торможении такие BMS видят превышение напряжения на ячейках, закрывают зарядный ФЕТ, отсекая рекуперацию, у инвертора резко пропадает нагрузка и напряжение взлетает до небес. Для сравнения, как всё реализовано в более приличных Ninebot/Xiaomi: зарядный и разрядный порты разделены, разрядный отделён от ячеек только разрядным ключом, отсечь заряд (т.е. рекуперацию) через него BMS вообще не способна, при превышении напряжения она просто сообщает об этом контроллеру и тот уже программно снижает ток торможения до тех пор, пока BMS не перестанет «жаловаться».
В простейшем случае программа просто писалась с расчётом на 32-битность и плоскую модель, собиралась Watcom C(++), компоновщик которого сам ваш код компоновал в формат LE (OS/2 Linear Executable), затем добавлял к нему DOS MZ заголовок и сам DOS/4GW как DOS stub. При запуске получившегося ехе первым получал управление DOS/4GW (т.к. DOS не понимал формат LE и видел только MZ часть), который, как и описано в статье, искал уже работающий DPMI-сервер (через прерывание INT 2F, закреплённое за DPMI), при отсутствии оного сам «вешался» на это прерывание, а дальше через функцию того же INT 2F (обрабатываемую либо самим DOS/4GW, либо «чужим» DPMI-сервером) переходил в защищённый режим, через функции INT 31 (DPMI API уже в 32-битном режиме, DPMI-сервер и его должен обрабатывать) выделял память под пользовательскую программу, загружал её туда (разбирая уже LE-часть) и в конце концов «прыгал» на пользовательскую точку входа, указанную в LE-заголовке.
Другая часть «магии» Watcom находилась в его стандартной библиотеке, которая «заворачивала» работу с файлами/консолью в вызовы DOS через функции всё того же INT 31, выделяла/освобождала память опять же через INT 31 итд.
Если программе не требовалось что-нибудь низкоуровневое вроде установки обработчика прерывания, прямого доступа к видеобуферу и подобного, она выглядела как самый обычный С/С++. Для низкоуровневых же вещей требовалось уже вручную вызывать всё тот же INT 31.
Как-то так.