пакеты в эфире другие, но та же модуляция и если сильно хочется- 24-ым можно нафонить бле-пакетов. на которые хватит максимальной длины (у 24 немножко маленькая, хватит только, чтоб другой девайс увидел нас). у вайфая все же qam сейчас, насколько помню.
читать всю спеку бле мне немножко лениво, сорян. не приходилось еще пилить девайсов с ним. про ifs знаю.
после передачи пакета ble выключает pll и передатчик. и чтоб раскочегарить его обратно- нужно время. по итогу имеем чтот около 50 кбит/с. а вот при приеме пакетов никто ничего не выключает... правда там опять же спека что-то где-то запрещала и сильно много напринимать не получится.
у nrf24l01+ и аналогов все точно так же. *потому что в 24l01 радио от ble*. только уже там можно принимать на один приемник побольше пакетов, потому что никакая спека ble ничего не запрещает.
а потом в сети появляется стремная железка со стремным ethernet-контроллером от не менее стремной конторы synopsys. их gmac где только не встречается...
и вот иногда он может быть не то криво сконфигурирован при синтезе, или еще что-нибудь случиться, но как только закончится dhcp lease (и ос сходит на dhcp-сервер за новым)- железка с этим контроллером просто перестанет отвечать даже на пинги. при этом с самой железки tcp-коннекты поднимаются и работают.
а потом захочется воткнуть в usb ему другую сетевуху- а usb-то тоже от synopsys. dwc_usb. те, кто пробовал его попрогать на расте в микроконтроллерах- поймут xD
(он проваливается в stall, если процессор слишком медленно работает. или сборка дебажная (и поэтому достаточно медленная))
извините, я опять трогала стремные платы. а вон та проблема с гмаком лечится установкой этой железке статического адреса и ни в коем случае не использования конкретно на ней dhcp.
p5we0/аналоги? там просто нет полноценного управления кулером со стороны основного процессора. можно только или включить его на 100%, или оставить автоматическое управление. можно загрузить там пару раз свежую 10/11, она обновит ему ME, кулер хотя бы начнет работать автоматически.
если влом- на старом в линуксе можно сходить в suspend2ram и выйти из него. кулер тоже заработает. до выключения питания.
если совсем-совсем-совсем не влом- можно попатчить прошивку EC, управление кулером там. свежий ME тоже нужен, без него все еще будет все разломано. (при этом я вообще не помню, зачем оно там надо было, по идее все должно работать и так. основной регион биоса винда точно не трогает.)
H5, гигабайт оперативки, отсутствие eMMC, аллвиннеровская же вайфайка... по итогу получается клон orange pi на h5 с другим питальником втридорога.
минусы навскидку:
мали450- это как ati rage сейчас. малиновая гпу получше будет.
всего два лейна CSI. мало ли захочется туда воткнуть что-нибудь побыстрее, чем 1080p30
нет DSI
скорее всего придется немножко повоевать с питальником, чтоб плата жрала поменьше
зато (в отличие от старых малин) четыре usb-хоста и сеть не на usb. жаль, гигабитный phy не воткнули. а еще встроенный кодек умеет vaapi. и гребенка чуть полезнее малиновой должна быть. и есть специальное отдельное ядрышко для высовывания туда realtime-штук (авторы репки же не заюзали его под управление питанием? правда?)
926ej-s... 208 мгц... не думала, что опять увижу это в 2022.
*косится на siemens s75 с таким же 926ej-s на 208 мгц в стоке. вроде там в думе было побольше 19-ти фпс.*
на snes и прочие сеги этого проца хватит. даже немножечко должно хватить на первую кваку, если памяти добавить. по крайней мере эта самая квака относительно неплохо бегала на нокии 3230, в которой 926 на 124 мгц.
к слову говоря, на 5000 линейке радеонов был наглухо сломан opencl, видеокарта просто неправильно считала и/или крашилась, если ее нагрузить выше ~80% (по потреблению). говорят, на свежих дровах пофикшено.
скорее всего это защита от контрафактных чипов, FTDI этим страдали. будет работать только со старыми драйверами (2.8.14 кажется), если прописать vid/pid в него обратно (гуглится по ftdi mprog). но проще взять любой другой usb-uart конвертер, лучше всего на ch340 - они точно могут в два мегабода и их дрова не страдают защитой от подделок.
nucleus запускается, совсем лоулевел "драйвера" запускаются, шедулер работает. до старта "основной ос" не доходит (да, там "ос поверх ос"). за что-то надо дернуть, еще не нашла, за что xD
или возможно просто что-то прошивке не нравится и она втихую перестает дальше запускаться (но не выключается и не перестает перезапускать watchdog)
тот лог с фуллфлеша s65, если что.
Так он вроде работал? В соседнем комменте про это писали.
в соседнем комменте про видео, а не про 3d. ЕМНИП там стоял ati imageon из первых, у которых был opengles 1.1. и вот оно работало настолько плохо... что я не уверена, что он вообще использовался. xD
какую-то таблицу с указателями
посмотри на сеть. где-то там был пятерной указатель. xD
я просто лениво-лениво пишу эмулятор pmb8875/6, насмотрелась на оные. ну, а на dead926e еще тогда, чуть меньше 15 лет назад.
0xface926e лежит по адресу 0x14. но не уверена, что его можно прочитать просто так- туда подмаплена TCM.
Я реально столкнулся с тем, что при чтении страницы (40 кб) из файла наивно в GUI_OnRedraw() всё ощутимо пролагивает на полсекунды.
там просто фс тоже в отдельном процессе и общение с ним mailbox'ами и очередями. с очевидными тормозами на каждом шагу.
А зачем они ставили 16, чтобы не использовать половину? Это ж дорого?
кто же их знает, это же siemens xD
возможно, хотели что-то еще добавить, но не успели. там очень-очень много недопиленных вещей. *показывает на 3d-ускоритель в s75*
даже с современными инструментами вроде ghidra.
гидрой, да 32-меговый бинарь... она ж подавится xD
вроде бы запускает переданную функцию как отдельный поток
чисто технически все эльфы работают в одном потоке. cepid 0x4209, насколько помню. а subproc запускает функцию в контексте другого (но тоже одного и фиксированного) потока с другим приоритетом (pid == приоритет). вот его уже не помню, слишком давно было.
тщмта, железа этих телефонов вполне хватало на xvid 132*176 в 15 fps. больше смысла не имело, ибо дефолтный "драйвер" дисплея (который на самом деле не драйвер, а просто процесс nucleus'а, а драйвера siemens не использовали вообще) просто не умел рефрешить чаще.
упор там был даже не в производительность проца, которой вполне хватало (но дико нехватало наличия хоть какого-нибудь FPU и бесило то, что проц даже банально делить не умеет), а в скорость доступа до флешки. той, которая (RS-)MMC. наивный fopen/fread выдавал единицы килобайт в секунду. ровно по той причине, что siemens не использовали драйвера.
при этом чисто технически sdio-контроллер там мог читать флешки быстро и делал это- но только в родном плеере. спокойно выдавал все 1411 кбит/с.
крч, не просто так в этих телефонах в векторах прерываний есть замечательная константа 0xFACE926E, а память при старте ос они проверяют не менее замечательной константой 0xDEAD926E.
2 Мб оперативки
а на cx75 (и возможно m75)- 16, верхние 8 из которых не использовались. но можно включить обратно.
пакеты в эфире другие, но та же модуляция и если сильно хочется- 24-ым можно нафонить бле-пакетов. на которые хватит максимальной длины (у 24 немножко маленькая, хватит только, чтоб другой девайс увидел нас).
у вайфая все же qam сейчас, насколько помню.
читать всю спеку бле мне немножко лениво, сорян. не приходилось еще пилить девайсов с ним. про ifs знаю.
оно там будет, но звездочкамелкийшрифт
после передачи пакета ble выключает pll и передатчик. и чтоб раскочегарить его обратно- нужно время. по итогу имеем чтот около 50 кбит/с. а вот при приеме пакетов никто ничего не выключает... правда там опять же спека что-то где-то запрещала и сильно много напринимать не получится.
у nrf24l01+ и аналогов все точно так же. *потому что в 24l01 радио от ble*. только уже там можно принимать на один приемник побольше пакетов, потому что никакая спека ble ничего не запрещает.
а потом в сети появляется стремная железка со стремным ethernet-контроллером от не менее стремной конторы synopsys. их gmac где только не встречается...
и вот иногда он может быть не то криво сконфигурирован при синтезе, или еще что-нибудь случиться, но как только закончится dhcp lease (и ос сходит на dhcp-сервер за новым)- железка с этим контроллером просто перестанет отвечать даже на пинги. при этом с самой железки tcp-коннекты поднимаются и работают.
а потом захочется воткнуть в usb ему другую сетевуху- а usb-то тоже от synopsys. dwc_usb. те, кто пробовал его попрогать на расте в микроконтроллерах- поймут xD
(он проваливается в stall, если процессор слишком медленно работает. или сборка дебажная (и поэтому достаточно медленная))
извините, я опять трогала стремные платы. а вон та проблема с гмаком лечится установкой этой железке статического адреса и ни в коем случае не использования конкретно на ней dhcp.
p5we0/аналоги? там просто нет полноценного управления кулером со стороны основного процессора. можно только или включить его на 100%, или оставить автоматическое управление. можно загрузить там пару раз свежую 10/11, она обновит ему ME, кулер хотя бы начнет работать автоматически.
если влом- на старом в линуксе можно сходить в suspend2ram и выйти из него. кулер тоже заработает. до выключения питания.
если совсем-совсем-совсем не влом- можно попатчить прошивку EC, управление кулером там. свежий ME тоже нужен, без него все еще будет все разломано. (при этом я вообще не помню, зачем оно там надо было, по идее все должно работать и так. основной регион биоса винда точно не трогает.)
H5, гигабайт оперативки, отсутствие eMMC, аллвиннеровская же вайфайка... по итогу получается клон orange pi на h5 с другим питальником втридорога.
минусы навскидку:
мали450- это как ati rage сейчас. малиновая гпу получше будет.
всего два лейна CSI. мало ли захочется туда воткнуть что-нибудь побыстрее, чем 1080p30
нет DSI
скорее всего придется немножко повоевать с питальником, чтоб плата жрала поменьше
зато (в отличие от старых малин) четыре usb-хоста и сеть не на usb. жаль, гигабитный phy не воткнули. а еще встроенный кодек умеет vaapi. и гребенка чуть полезнее малиновой должна быть. и есть специальное отдельное ядрышко для высовывания туда realtime-штук (авторы репки же не заюзали его под управление питанием? правда?)
очень сильно не уверена, что хотя бы одна инструкция жабьего байткода в железе реализована. скорее всего там заглушка.
*и кстати, на симанцах эту java-машину каждый второй отключал. ибо лишний мегабайт оперативки, да.*
вот не помню, как на s75 было, вот тайминги с s65 (926e на 104 мгц, память sdram)
надо бы уже собраться и дописать эмулятор...
и да, на старых телефонах тоже экономили на всем, что только можно было.
926ej-s... 208 мгц... не думала, что опять увижу это в 2022.
*косится на siemens s75 с таким же 926ej-s на 208 мгц в стоке. вроде там в думе было побольше 19-ти фпс.*
на snes и прочие сеги этого проца хватит. даже немножечко должно хватить на первую кваку, если памяти добавить. по крайней мере эта самая квака относительно неплохо бегала на нокии 3230, в которой 926 на 124 мгц.
к слову говоря, на 5000 линейке радеонов был наглухо сломан opencl, видеокарта просто неправильно считала и/или крашилась, если ее нагрузить выше ~80% (по потреблению). говорят, на свежих дровах пофикшено.
ага, они хотели сначала ноутбук, потом почти получился кпк.. а хвосты ноутбука остались. xD
там вон в прошивке поддержка модемов даже есть. и невидимая область экрана используется. xD
существовал (почти) и еще более полноценный компьютер в той серии.
http://www.leningrad.su/museum/show_calc.php?n=178
8086, 128 килобайт оперативки, 128 килобайт биоса, почти-cga-like дисплей. почти xt'шка. добавь ей флоповод- небось и дос бы запустился.
https://www.phantom.sannata.org/viewtopic.php?f=27&t=39037&p=592596#p592596 вот тут даже есть (недописанный) эмулятор этой штуки. все жду, пока мне считают дамп с реальной смпшки...
да зачем что-то ломать, если там механический замок для оверрайда настолько плох, что негоден даже для почтовых ящиков?
ЕМНИП вместо эльфов там были .bin (и веселье с релоками).
а вон то скорее всего на acevideo сделано, на j2me. оно там неплохо бегало.
скорее всего это защита от контрафактных чипов, FTDI этим страдали. будет работать только со старыми драйверами (2.8.14 кажется), если прописать vid/pid в него обратно (гуглится по ftdi mprog). но проще взять любой другой usb-uart конвертер, лучше всего на ch340 - они точно могут в два мегабода и их дрова не страдают защитой от подделок.
https://pastebin.com/YBYspJBe
nucleus запускается, совсем лоулевел "драйвера" запускаются, шедулер работает. до старта "основной ос" не доходит (да, там "ос поверх ос"). за что-то надо дернуть, еще не нашла, за что xD
или возможно просто что-то прошивке не нравится и она втихую перестает дальше запускаться (но не выключается и не перестает перезапускать watchdog)
тот лог с фуллфлеша s65, если что.
в соседнем комменте про видео, а не про 3d. ЕМНИП там стоял ati imageon из первых, у которых был opengles 1.1. и вот оно работало настолько плохо... что я не уверена, что он вообще использовался. xD
посмотри на сеть. где-то там был пятерной указатель. xD
кажется, около dns.
я просто лениво-лениво пишу эмулятор pmb8875/6, насмотрелась на оные. ну, а на dead926e еще тогда, чуть меньше 15 лет назад.
0xface926e лежит по адресу 0x14. но не уверена, что его можно прочитать просто так- туда подмаплена TCM.
там просто фс тоже в отдельном процессе и общение с ним mailbox'ами и очередями. с очевидными тормозами на каждом шагу.
кто же их знает, это же siemens xD
возможно, хотели что-то еще добавить, но не успели. там очень-очень много недопиленных вещей. *показывает на 3d-ускоритель в s75*
гидрой, да 32-меговый бинарь... она ж подавится xD
чисто технически все эльфы работают в одном потоке. cepid 0x4209, насколько помню. а subproc запускает функцию в контексте другого (но тоже одного и фиксированного) потока с другим приоритетом (pid == приоритет). вот его уже не помню, слишком давно было.
тщмта, железа этих телефонов вполне хватало на xvid 132*176 в 15 fps. больше смысла не имело, ибо дефолтный "драйвер" дисплея (который на самом деле не драйвер, а просто процесс nucleus'а, а драйвера siemens не использовали вообще) просто не умел рефрешить чаще.
упор там был даже не в производительность проца, которой вполне хватало (но дико нехватало наличия хоть какого-нибудь FPU и бесило то, что проц даже банально делить не умеет), а в скорость доступа до флешки. той, которая (RS-)MMC. наивный fopen/fread выдавал единицы килобайт в секунду. ровно по той причине, что siemens не использовали драйвера.
при этом чисто технически sdio-контроллер там мог читать флешки быстро и делал это- но только в родном плеере. спокойно выдавал все 1411 кбит/с.
крч, не просто так в этих телефонах в векторах прерываний есть замечательная константа 0xFACE926E, а память при старте ос они проверяют не менее замечательной константой 0xDEAD926E.
2 Мб оперативки
а на cx75 (и возможно m75)- 16, верхние 8 из которых не использовались. но можно включить обратно.