فریمور آپدیت از نوع OTA وجود داشت، وقتی هنوز کسی نمی‌دونست OTA یعنی چی!

با اینکه در دهه ۸۰ میلادی خبری از وای‌فای، اینترنت یا سرور نبود، ولی رادیوهای FM تو هلند داشتن برای کامپیوترهای خونگی برنامه پخش کامپیوتری پخش می‌کردن، اونم فقط با صدای بوقی که تشکیل می‌شد از دو فرکانس ۱۲۰۰ و ۲۴۰۰ و مدولاسیونFSK روی رادیو FM که خودش هم یه بار مدوله شده بود!
اسم این ماجرا BASICODE بود! یه استاندارد عجیب و درخشان از اوایل دهه‌ی ۸۰ که می‌خواست همه‌ی کامپیوترهای خُرد اون دوران رو با یه زبان واحد به هم برسونه.

ماجرا از یه مهندس رادیویی به اسم Hessel de Vries شروع شد، کسی که برای شبکه‌ی ملی هلند (NOS) کار می‌کرد. اون فهمید که کامپیوترهای اون دوران از کومودور گرفته تا ZX Spectrum، BBC Micro و MSX هر کدوم زبان BASIC مختص به خودشون رو دارن و عملاً نمی‌تونن با هم حرف بزنن. نتیجه؟ BASICODE رو اختراع کرد، یا به قول خودشون «اسپرانتوی کامپیوترها». یه نسخه‌ی حداقلی و استاندارد از BASIC که روی هر دستگاهی اجرا می‌شد، فقط کافی بود یه «بیسکودر» مخصوص اون دستگاه رو لود می‌کردی.

بیسکودر یه جور محیط اجرایی بود، یه بوت‌لودر دست‌ساز که توش تابع‌های مشترک برای ورودی/خروجی، نمایش متن، ذخیره‌سازی روی کاست و بعدتر صدا و گرافیک ساده تعریف شده بود! برنامه‌ها از خط ۱۰۰۰ به بعد شروع می‌شدن و بقیه‌ی خطوط پایین‌تر مخصوص خود بیسکودر بودن. برای فراخوانی توابعش هم فقط یه GOSUB می‌زدی، درست مثل یه API ابتدایی برای ۸ بیتی‌ها.

حالا تصور کنید رادیو برنامه رو به صورت صدا پخش می‌کرد، تو ضبط می‌کردی روی نوار کاست، بعد اون رو به کامپیوترت می‌دادی تا کدها رو از توی صدا بخونه و اجرا کنه. به معنای واقعی کلمه «OTA»! فقط نه با پکت و فرکانس ۲.۴ گیگاهرتز، بلکه با بوق ۱۲۰۰ و ۲۴۰۰ هرتز! سرعت انتقالش؟ حدود ۶ کیلوبایت در دقیقه. بله، دقیقه. ولی برای اون دوران، همین هم مثل جادو بود.

در نسخه‌ی BASICODE 2 سال ۱۹۸۳، کارکردها گسترده‌تر شد مدیریت داده، ورودی از نوار، و یه کتابخونه‌ی کامل از حدود ۵۰ تابع مشترک. نسخه‌ی سوم (BASICODE 3) در ۱۹۸۶ حتی گرافیک تک‌رنگ و صدا هم اضافه کرد، و نسخه‌ی 3C در ۱۹۹۱ رنگی هم شد. برنامه‌ها از رادیو در سراسر آلمان شرقی و هلند پخش می‌شدن، حتی روی صفحه‌گِرامافون هم منتشر می‌کردن تا مردم بتونن کد رو از صدا بخونن!

اما مثل همه‌ی پروژه‌های قهرمانانه‌ی دهه‌ی ۸۰، پایانش با ظهور ۱۶ و ۳۲ بیتی‌ها رقم خورد. وقتی آمیگا، آتاری ST و PCها با سیستم‌عامل‌های گرافیکی اومدن، BASICODE دیگه زیادی ساده به نظر می‌رسید. نسخه‌ی چهارمی هم برنامه‌ریزی شده بود، ولی هیچ‌وقت ساخته نشد.

با این حال، BASICODE هنوز یه میراث زنده‌ست. خیلی از مفاهیمی که امروز تو جاوا، PDF یا حتی پلتفرم‌های کراس‌پلتفرم مدرن می‌بینیم، ریشه در همون ایده داره: یه استاندارد زبانی مشترک + یه مفسر مخصوص هر سیستم. همون کاری که JVM برای جاوا می‌کنه، بیسکودر برای کامپیوترهای ۸ بیتی می‌کرد.

و شاید قشنگ‌ترین بخش ماجرا این بود که کل سیستم، فقط با یه رادیو، یه نوار کاست، و چند خط BASIC کار می‌کرد.
جالب اینه که هنوزم هستن کسایی که به عنوان سرگرمی از این شیوه و زبان و ... استفاده می‌کنند.

تو این لینک می‌تونید در موردش بخونید.

📡openpcb

اگه یادتون باشه قبلاً تو این پست در مورد یکی از پروژه‌های خاص استیو نوشته بودم! که با ترکیب یه برد رزبری‌پیکو و یه دانگل hdmi یک ابزار DAQ با نرخ انتقال داده 75 مگابایت بر ثانیه ساخته بود!

استیو یبار دیگه با پروژه جذاب Pico-100BASE-TX برگشته! یه فرستنده‌ی اترنت سریع ۱۰۰ مگابیتی که کامل تو نرم‌افزار روی میکروکنترلر یک دلاری 2040 یا RP2350 بدون هیچ سخت‌افزار اضافه دیگه‌ای اجرا می‌شه.

مارکگراف با ترکیب PIO و DMA تونسته کدینگ‌های MLT-3، 4B5B و scrambling رو با نرخ ۱۲۵ MHz پیاده کنه. نتیجه‌اش یه لینک واقعی ۱۰۰ مگابیتی شده که حدود ۱۱ مگابایت بر ثانیه می‌تونه از طریق UDP داده بفرسته — مثلاً استریم زنده‌ی صدا یا داده‌ی ADC.
جزییات کامل این پروژه رو اینجا می‌تونید بررسی کنید.


📡openpcb

به نظرتون کسی که اسم این چیپ رو انتخاب کرده رگ ایرانی داشته؟😂

به نظر تو ژاپن برای «ساخت قطعات الکترونیکی دقیق و فوق‌کم‌مصرف» جایزه دارن😬

چیپ NC4650 از Nisshinbo که یه رگولاتور بوست فوق کم‌مصرفه، تو جایزه‌ی «سوپر قطعه‌سازی ۲۰۲۵» (جایزه‌ی قطعات برتر مونوزوکوری ژاپن🤷🏻‍♂️) تو بخش «قطعات الکتریکی-الکترونیکی» برنده شده.
جریان حالت استندبای این رگولاتور ۷۰ نانوآمپره.

مراسم اهدای جایزه هم دسامبر برگزار می‌شه انگار!

منبع:
https://x.com/NisshinboMicro/status/1986249092587266106


📡openpcb

اگه چند سال پیش می‌گفتن یه روزی می‌شه با زیر ۲۰۰ دلار چیپ اختصاصی ASIC خودت رو تولید کنی! جدی نمی‌گرفتم. ولی خب الان به لطف اکوسیستم TinyTapeout و سرویس‌های شاتل ارزون که فب‌ها باز کردن، دیگه واقعاً ممکنه.

الان با حدود ۱۸۵ یورو می‌تونی یه طرح ساده دیجیتال بسازی، Tapeout بدی، و نسخه واقعی چیپ رو دستت بگیری. نه شبیه‌سازی، نه FPGA، خود چیپ سیلیکونی رو!

این یعنی دروازه طراحی چیپ از دست «شرکت‌های میلیارد دلاری» دراومده و رسیده به دست میکرو تیم‌ها، دانشجوها، DIYها و دیوونه‌های کنجکاو!

کم‌کم دنیای الکترونیک هم مثل نرم‌افزار داره دموکراتیک می‌شه و از این به بعد «من خودم چیپش رو ساختم» دیگه ادعای عجیب‌غریبی نیست، روزمره‌ست!


لیست پروژه‌هایی که تا الان ثبت شدن هم اینجاست، کارای عجیب‌غریب قشنگ زیاد هست:
https://app.tinytapeout.com/shuttles/ttsky25b


📡openpcb

با توجه به پست قبلی بد نیست یه مروری کنیم ببینیم چی شد که ساخت یه چیپ اختصاصی حتی برای یک نوجوون ۱۶ساله با هزینه ۱۸۰ دلار ممکن شد!

ماجرا برمی‌گرده به چند سال پیش، وقتی ایده‌ی «ارزون‌کردن Tapeout» تازه جدی شد. ریشه‌ی کار از همکاری Google و فب SkyWater شروع شد. گوگل اومد با اسکای‌واتر روی یه ایده تاریخی دست گذاشت: فرآیند ساخت تراشه‌ی ۱۳۰ نانومتری رو از حالت محرمانه درآورد و به‌شکل یک Open PDK عمومی منتشر کرد. یعنی دیتایی که قبلاً فقط شرکت‌های میلیارددلاری بهش دسترسی داشتن، یک‌باره شد عمومی. این لحظه واقعاً نقطه‌ی عطف بود.

اینطوری راه برای ابزارهای طراحی متن‌باز باز شد. ابزارهایی مثل OpenLane و Yosys و Magic که قبلاً فقط تو حاشیه بودن، یه‌دفعه تبدیل شدن به گزینه‌های واقعی برای طراحی ASIC بدون لایسنس‌های چندمیلیون‌دلاری! یعنی از این لحظه طراحی چیپ از «باشگاه اختصاصی چند شرکت غول» تبدیل شد به چیزی که عملاً روی لپ‌تاپ خونه هم می‌شد انجامش داد.

منفعتش برای اسکای‌واتر چی بود؟ خب اسکای‌واتر یه فب ۱۳۰نانومتری داشت که دیگه برای صنعت موبایل و CPUهای جدید جذاب نبود، اما برای چیپ‌های دیجیتالی ساده، IoT، مدارهای ترکیبی و هزار مدل کاربرد ساده، هنوز کاملاً به‌دردبخور بود. اونها به جای خاک خوردن خط تولید، گفتن: «خب چرا تبدیلش نکنیم به یه پلتفرم Tapeout ارزون؟» اینجاست که ایده‌ی Multi Project Wafer جرقه خورد: چند نفر طراحی‌هاشون رو با هم می‌فرستن و هزینه‌ی یه ویفر بین همه تقسیم می‌شه. خط قدیمی دوباره فعال شد، ولی این‌بار نه برای تولید انبوه، بلکه به‌عنوان ماشین Tapeout کم‌هزینه. و در کنارش، مشتری‌های آینده هم تربیت شدن!

همین‌جا بود که یه سری آدم خوره و خوش‌فکر دور هم جمع شدن که بگن طراحی ASIC باید «برای همه» قابل انجام باشه. از دل همین فضا پروژه‌ی TinyTapeout بیرون اومد. Matt Venn شد چهره‌ی جلوی صحنه! آدمی که از روز اول دنبال این بود که ساخت چیپ مثل پروژه‌های نرم‌افزاری بشه: متن‌باز، قابل تجربه، و بدون مانع‌های سنگین مالی. گوگل هم ظرفیت شاتل و حمایت مالی گذاشت که دانشگاهی‌ها، هکرها و آدم‌های کنجکاو واقعاً بتونن Tapeout کنن، نه فقط حرفش رو بزنن.

این حمایت گوگل هم اصلاً از روی خیرخواهی نبود! بلکه دقیق و بلندمدت بود. گوگل دنبال آینده‌ایه که سخت‌افزار هم مثل نرم‌افزار «قابل اتوماسیون و تولید به‌وسیله ابزارها» باشه. برای رسیدن به «AI-Silicon Design» باید جامعه‌ی طراح وجود داشته باشه. این پروژه عملاً داشت نسل بعدی مهندس‌های سیلیکون رو می‌ساخت.

در نهایت هم هیچ آسیبی به «رازهای بزرگ» وارد نشد. نه فرایند ۵ نانومتر باز شد، نه ۷ نانومتر. چیزی که باز شد، فرآیندی بود که از نظر اقتصادی از اوجش گذشته بود و حالا ارزش جدید پیدا کرد. در عوض چی به‌دست اومد؟ نیروی انسانی بیشتر، اکوسیستم متن‌باز قوی‌تر، بازگشت جریان درآمد به فبی که عملاً از چرخه خارج شده بود، و نفوذ استراتژیک در آینده‌ی طراحی تراشه.

در اصل جایی که بقیه فقط «یه چیپ ۱۳۰ نانومتری» می‌دیدن، گوگل و اسکای‌واتر داشتن نسل طراح‌های فردا رو می‌ساختن و راه رو برای «سخت‌افزار مثل نرم‌افزار» هموار می‌کردن.


📡openpcb

در ادامه دو پست قبلی می‌خوام توضیح بدم کل روند Tapeout کردن چطور کار می‌کنه و چطور می‌تونید چیپ ASIC خودتون رو با زیر ۲۰۰ دلار بسازید.

از اونجایی که TinyTapeout کل زنجیره‌ی «طراحی > سنتز > P&R > تولید» رو تبدیل کرده به یک خط اتوماتیک و دم‌دستی. اول شما مدار دیجیتال‌تون رو طراحی و تست می‌کنید. این مرحله کاملاً رایگانه. می‌تونید از Wokwi استفاده کنید که به‌شکل شماتیک و منطقی مدار رو می‌سازید و شبیه سازی می‌کنید!

اگر هم از اونایی هستید که با HDL راحتید، مستقیم Verilog می‌نویسید و تست‌بنچ می‌زنید. نکته‌ی کلیدی اینه که TinyTapeout یک Interface ثابت بین طراحی شما و پدهای چیپ داره, یعنی شما فقط «منطق داخلی» رو می‌سازید، بخش «پدها، باندینگ، IO آپشن‌ها, کلاک و ریست» استاندارد شده و همین باعث می‌شه طراحی خیلی قابل اعتماد و قابل Tapeout باشه.

وقتی از صحت مدار مطمئن شدید، پروژه‌تون رو روی GitHub می‌ذارید و فقط یک فایل info.yaml رو پر می‌کنید. از اینجا به بعد، GitHub Actions وارد بازی می‌شه و پروسه سنتز منطق با Yosys، Place & Route با OpenLane، و در نهایت تولید فایل GDSII. GDS همون نقشه‌ی واقعی سیم‌کشی لایه‌های فلز و ترانزیستورهای پلی/دیفیوژن هست اتفاق می‌افته و مستقیم می‌ره فب. این مرحله اتوماتیکه یعنی شما دقیقاً دارید از همون پایپ‌لاین ابزارهای اپن‌سورس صنعتی استفاده می‌کنید! بدون لایسنس‌های میلیون دلاری Cadence و Synopsys.

هزینه فقط وقتی پرداخت می‌شه که تصمیم می‌گیرید طرحتون رو روی شاتل Tapeout واقعی بفرستید. همونطور که قبلا گفتم TinyTapeout از Multi-Project Wafer استفاده می‌کنه یعنی چند ده طرح با هم روی یک ویفر ساخته می‌شن و هزینه بین همه تقسیم می‌شه. همین باعث می‌شه قیمت Tapeout بیاد روی حدود ۱۸۵ یورو.

وقتی چیپ تولید شد، براتون روی یک هدر برد دمو مونتاژ شده ارسال می‌شه. این برد شامل IOهای استاندارد، 7-Segment، هدرهای توسعه، و یک Raspberry Pi Pico به‌عنوان «درایور + محیط تست» هست. با MicroPython یا حتی UART ساده می‌تونید ورودی بدید، خروجی بخونید، و رفتار چیپ‌تون رو ببینید و وریفای کنید. این همون لحظه‌ایه که پروژه از یک شبیه‌سازی دیجیتال تبدیل می‌شه به یک چیپ واقعی روی میز! اون لحظه‌، لحظه‌ی «این دیگه شوخی نیست، این دیگه واقعاً چیپه» هستش.

اگر کسی بخواد عمیق‌تر بره سمت طراحی جدی‌تر، منابع درجه‌یک و کاملاً رایگانی در دسترس هست که تا همین چند سال پیش عملاً غیرممکن بود بهشون دسترسی داشته باشید. مثلاً کورس طراحی مدار آنالوگ مبتنی بر جریان باز و معماری آزاد از Prof. Pretl در JKU که طراحی آنالوگ رو از سطح Device تا Tapeout آموزش می‌ده، یا برنامه‌ی SSCS-Chipathon تحت هدایت Prof. Mourmann که عملاً یک بوت‌کمپ Tapeout محور برای عمومه!

از اون طرف، گروه Prof. Frank Gürkaynak در ETH که یکی از فعال‌ترین تیم‌ها در RISC-V و طراحی بازه، پلتفرم‌ها و هسته‌هایی مثل croc رو منتشر کرده که بسیار جذابه. در نهایت اگر دنبال جامعهای هستید که بیشتر با این مبحث آشنا بشید، جامعه‌ی طراحان مدار باز در اینجا رو دنبال کنید.

و نکته‌ی آخر و البته مهم:
به لطف یکی از خواننده‌های کانال، پنج کوپن TinyTapeout برای شاتل‌های بعدی موجوده. یعنی اگر طرح‌تون به مرحله‌ای رسیده که تست سیمولیشن و تست منطقی پشت‌سر گذاشته و واقعاً قصد Tapeout دارید، پیغام بدید تا یکی از کوپن‌ها در اختیارتون قرار بگیره.


📡openpcb

شاید براتون جالب باشه بدونید اولین میکروپروسسور دنیا یعنی Intel 4004 کاملا با دست طراحی و ساخته شد.

اون موقع هنوز خبری از CAD و نرم‌افزارهای مدرن امروزی نبود. Bob Noyce و تیمش از روشی به اسم Rubylith استفاده می‌کردن! یه ورق قرمز که ماسک لیتوگرافی رو روی اون به صورت دستی می‌بریدن.
یعنی مسیر ترانزیستورها، گیت‌ها، لایه‌ها… همش واقعاً با کاتر و خط‌کش. فکر کنید مدار چند هزار ترانزیستوری رو مثل معرق‌کاری تیکه‌تیکه کنار هم بذاری. نه Undo، نه Grid، نه DRC/ ERC… فقط چشم، دست، دقت و صبر.

همین که اینا تونستن در اون شرایط اولین میکروپروسسور تاریخ رو بسازن و جواب بده، خودش یه شاهکار واقعیه. گاهی تکنولوژی امروز رو می‌بینیم و فراموش می‌کنیم که ریشه‌اش رو یه مشت آدم با دست خالی شروع کردن. این به‌نظرم واقعاً خفنه.


📡openpcb

طبق گفته FFmpeg پچ جدید باعث شده یه تابع مهم تو پردازش ویدیو ۳.۴۶ برابر سریع‌تر بشه. ماجرا اینه که یکی از کانتریبیوترها به اسم mkver اومده تابع add_8x8basis_sse3 رو که قبلاً با C نوشته شده بود رو کاملا با اسمبلی x86 بازنویسی کرده و خروجی هم شده همین جهش سرعت جدی.

دلیلش اینه که کامپایلرهای GCC و Clang وقتی با فلگ O3 کد رو کامپایل می‌کنند، معمولاً یه سری حلقه هایی که اصلاً قرار نیست زیاد اجرا بشن رو باز می‌کنن و کد رو حجیم‌تر می‌کنن. اینجا هم اون فانکشن رو از ۱۷۶ بایت رسونده به ۱۴۰۶ بایت! تو این مدل پردازش‌ها، چون دستورهای خاص و عجیب‌غریبی مثل pmulhrsw وجود داره، کامپایلر همیشه انتخاب‌های درستی نمی‌کنه. دولوپرهای FFmpeg هم میگن: «باشه، خودمون درستش می‌کنیم.» نکته مهم اینه که لزوماً کد C مشکل نداره! این رفتار کامپایلر تو مرحله بهینه‌سازیه که گاهی خودش دردسر درست می‌کنه.

این اولین‌بار نیست FFmpeg از اسمبلی برای گرفتن نهایت قدرت سخت‌افزار استفاده می‌کنه واین همون بحث معروف چند وقت پیشه که چرا پلیر dav1d که چندتا آدم معمولی ساختنش، بعضی جاها از libgav1 گوگل بهتره. جواب همون همیشگیه: وقتی دقیق می‌دونی چی می‌خوای و خودت دستی کد اسمبلی رو می‌نویسی، خروجی معمولاً از نسخه‌ی تولیدشده توسط کامپایلر بهتره.

یه سوال هم که همیشه مطرح می‌شه اینه که «چرا این مشکلات رو به سازنده‌های کامپایلر گزارش نمی‌کنن؟» گزارش می‌دن، ولی تا نسخه جدید کامپایلر بیاد مدت‌ها طول می‌کشه. یعنی عملاً بهترین کار اینه که خودشون همزمان دست به آچار باشن و مشکل رو دور بزنن.

برای همین پروژه‌هایی مثل FFmpeg اینقدر ارزشمندن. از یه طرف همیشه تو بهینه‌ترین حالت ممکنه، از یه طرف دیگه همین مواردی که پیدا می‌کنن عملاً به کل کامیونیتی C و کامپایلرها سود می‌رسونه و باعث می‌شه ابزارهایی که همه استفاده می‌کنن، کم‌کم بهتر بشن.


📺Source
📡openpcb

بعد از ادعای بزرگ بنیاد رزبری در مورد غیر قابل هک بودن میکروکنترلر RP2350 و فراخوان به هک و تعیین کردن جایزه برای کسی که بتونه code امضا نشده رو روی میکرو اجرا کنه، چند تیم مستقل امنیتی موفق شدن حداقل پنج روش اجرایی رو پیدا کنن که عملاً تمام لایه‌های دفاعی سخت‌افزاری و نرم‌افزاری این چیپ رو دور می‌زنه، این حملات نشون دهنده شکست کامل مکانیزم‌های Secure Boot و حتی استخراج فیزیکی کلیدها از سیلیکون بود.

اولین حفره‌ای امنیتی که پیدا شد مربوط به (State Machine)سخت‌افزاری بود که مسئول خوندن اطلاعات حیاتی از حافظه OTP موقع بوت شدنه! محققان متوجه شدن که با یه گلیچ ولتاژ دقیق روی پین تغذیه USB_OTP_VDD در بازه زمانی ۲۴۵ تا ۲۷۵ میکروثانیه بعد از استارت، می‌شه کاری کرد که سیستم به جای داده‌های واقعی، مقادیر "Guard Read" (که اتفاقاً 0x333333 هستن) رو بخونه و این باعث می‌شه چیپ اشتباهاً دیباگ رو باز کنه و با معماری RISC-V بالا بیاد که هیچ‌کدوم از تنظیمات امنیتی روش اعمال نشده.

روش دوم حمله به بوت‌لودر USB بود که توی فضای Non-Secure اجرا می‌شه! اونجا یه تابع reboot هست که با دو تا دستور اسمبلی چک می‌کنه کسی درخواست (Vector Boot) نکرده باشه، ولی با (Crowbar Glitching) و اسکیپ کردن یکی از این دستورات، تونستن سیستم رو گول بزنن تا کد امضا نشده رو اجرا کنه و جالب اینجاست که حتی آشکارسازهای گلیچ و (Random Delays) هم نتونستن جلوی این حمله رو بگیرن.

قشنگترین حمله وقتی بود که پای لیزر وسط اومد و با یه ستاپ لیزری خونگی زیر ۸۰۰ دلار، پروسه تایید امضا رو هدف گرفتن! تکنیک اینجا یه جور TOCTOU بود که فرم‌ور سالم رو برای تایید امضا می‌فرستادن اما با استفاده از لیزر پوینتر حافظه رو تغییر می‌دادن تا موقع اجرا، کد مخرب از یه آدرس دیگه لود بشه.

حمله چهارم هم روی مکانیزم قفل نرم‌افزاری OTP سوار شد، جایی که بوت‌لودر سعی می‌کنه دسترسی‌ها رو ببنده و این کار رو دو بار چک می‌کنه، ولی با ایجاد "دو تا گلیچ" الکترومغناطیسی (EMFI) پشت سر هم روی دستورات شیفت بیت، تونستن کاری کنن که قفل اعمال نشه و کلیدها از طریق USB قابل خوندن بشن.

نهایتاً تیر خلاص استخراج فیزیکی بود! با اینکه سلول‌های آنتی‌فیوز ۴۰ نانومتری خیلی کوچیکن، با استفاده از تکنیک کنتراست ولتاژ غیرفعال (PVC) زیر میکروسکوپ FIB، تونستن مستقیماً وضعیت ۰ یا ۱ بودن بیت‌ها رو از روی سیلیکون ببینن چون فیوزهای سوخته بار الکتریکی رو تخلیه می‌کردن و روشن‌تر دیده می‌شدن.

رزبری‌پای همه این موارد رو تایید کرد و برای بعضی‌هاش Errata داد، ولی نکته ترسناک اینه که حملاتی مثل OTP PSM یا لیزر نیاز به تغییر سیلیکون دارن و با آپدیت نرم‌افزاری درست نمی‌شن، که نشون می‌ده پیچیدگی زیاد بوت‌لودر و اتکا به سخت‌افزاری که قبل از اجرای کد امنیتی گلیچ می‌خوره (Pre-boot attacks)، می‌تونه کل معماری امنیتی رو به باد بده.

نکته قابل توجه ماجرا اینه که حتی شرکت‌هایی مثل رزبری‌ که اسمشون با «مهندسی تمیز» و «قابل اعتماد بودن» گره خورده و ادعاهای بزرگی در مورد امن بودن دارن، ممکنه همینقدر قاطع تو پیاده سازی ساز و کارهای امنیتی شکست بخورن.

اگه به جزییات این ماجرا علاقه داشتید می‌تونید تو این مقاله در موردش بخونید.



📡openpcb

اگه یه نگاهی به ارزش کل صنعت بازار نیمه‌هادی بندازیم, نکته عجیب این دیتا تمرکز وحشتناک ۳۷ درصدی این صنعت ۱۲ تریلیون دلاریه که دست انویدیاست این نشون می‌ده بازار الان عملاً فقط داره روی "هوش مصنوعی" قیمت‌گذاری می‌کنه و نه خودِ سیلیکون به معنای سنتی.

یه پارادوکس جالب مهندسی هم اینجاست که آمریکا با ۷ تریلیون دلار سهم بازار، قدرت بلامنازع به نظر میاد، اما اکثر این غول‌ها (انویدیا، برادکام، AMD) مدل Fabless دارن، یعنی عملاً هیچ چیپی نمی‌سازن و برای فیزیکِ کار کاملاً وابسته به TSMC تایوان هستن که این یعنی گلوگاه واقعی سخت‌افزار دنیا هنوز توی آسیای شرقیه.

اروپا هم عملاً تبدیل شده به یه "تک‌خال" به اسم ASML! یعنی اگه لیتوگرافی EUV هلند رو از معادله حذف کنی، اروپا با شرکت‌هایی مثل ST و Infineon و NXP که بیشتر توی حوزه امبدد، خودرو و پاور کار می‌کنن.

نکته عجیب بعدی، غیبت شرکت‌های مهمی مثل Nordic Semiconductor و Silicon Labs تو این دیتاست! اونم در حالی که چندتا شرکت نسبتا گمنام اسرائیلی تو لیست دیده می‌شن.


📡openpcb

شما هم ممکنه مثل پیتر کاولی (@corsix) کد ساده‌ی C خودتون را با GCC کامپایل کنید و خروجی اسمبلی ARM64 را باز کنید و همینطور که دارید کد اسمبلی تولید شده رو میبینید از خودتون بپرسید:
«این دیگه چیه؟ چرا کامپایلر دو بار w4 & w1 رو حساب کرده، بعد هم دو بار w0 & w4 رو تکرار کرده! مگه نمی‌شد یک mov بزنه و خلاص؟»
چیزی که در نگاه اول مثل یک باگ یا تنبلی کامپایلر به نظر می‌رسه، در واقع یکی از بهترین درس‌های بهینه‌سازی CPUهای مدرنه!

قبلش باید ببینیم چرا GCC (و گاهی Clang) همچین کار «عجیبی» می‌کنن و چرا تقریباً همیشه تو این موارد حق با کامپایلره.

کد سی احتمالاً همچین چیزی بوده:

uint32_t lookup(uint32_t index, uint32_t mask, const uint32_t* table) {
    uint32_t idx = index & mask;
    return table[idx];
}

و در نتیجه کد اسمبلی تولید شده توسط GCC همچین چیزیه!

and   w0, w4, w1        // w0 = w4 & w1
and   w2, w4, w1        //! w2 = w4 & w1
and   w0, w0, w4        // w0 = w0 & w4
and   w0, w0, w4        // !
ldr   w0, [x2, w0, uxtw #2]

کدهای تکراری! ولی چرا؟ تو CPUهای مدرن ARM64 (Apple M1/M2/M3/M4، Snapdragon X Elite، Graviton و …) اجرای دوباره‌ی یک دستور ساده‌ی AND تقریباً همیشه از mov سریعتره چون mov وابستگی داده (data dependency) ایجاد می‌کنه و pipeline را متوقف می‌کنه. یعنی وقتی می‌نویسی mov w2, w0،اتفاقی که میفته اینه که CPU باید صبر کنه تا w0 کاملاً آماده بشه، بعد w2 رو پر کنه. اما وقتی دو بار and w2, w4, w1 می‌نویسی، هر دو دستور ورودی یکسان (w4 و w1) داره و هیچ وابستگی‌ای بین‌شون نیست. نکته بعدی اینکه CPUهای out-of-order می‌تونند این دو دستور AND رو همزمان در دو واحد ALU مختلف اجرا کنند و از طرفی مکانیزم Register Renaming باعث می‌شه CPU این دو نتیجه را به‌عنوان دو رجیستر فیزیکی کاملاً جدا ببینه و هزینه‌ی واقعی خیلی خیلی کمه!

جالب اینه که clang خروجی متفاوتی داره و کمی تمیزتره!

and   w0, w1, w2      
and   w0, w0, w1    
ldr   w0, [x3, w0, uxtw #2]

دلیلش اینه که Clang کمی محافظه‌کارتره و بیشتر به «کد تمیز» اهمیت می‌ده، تو بنچمارک‌های واقعی روی M2/M3/M4 معمولاً تفاوت سرعت از ۱٪ کمتره. یعنی GCC با کد «زشت‌تر» گاهی حتی چند صدم درصد سریع‌تره!

پس یادتون نره در بیشتر مواقع «کامپایلر بیشتر از من می‌فهمه»، کد اسمبلی کوتاه‌تر هم نشونه سریعتر بودنش نیست. دفعه‌ی بعدی هم که GCC یا Clang چیزی تولید کرد که در نگاه اول «احمقانه» به نظر رسید، قبل از آه‌کشیدن یه بنچمارک کوچیک بزنین و یه نگاهی به معماری همون CPU بندازید. تو ۹۹٪ مواقع می‌بینین کامپایلر حق داشته. البته چیزهایی که هکرهای ffmpeg دستی بهینه می‌کنن رو هم نمی‌شه نادیده گرفت، ولی اونها قرار نیست به ما ثابت کنن که کامپایلر خنگه و ما ازش باهوش‌تریم. و در نهایت هم یادمون نره که روی آرم، GCC معمولاً یه ذره، خیلی کم اسمبلی بهینه‌تری تولید می‌کنه.


📡openpcb

جف گیرلینگ (معروف به GeerlingGuy) توییت جالبی منتشر کرده و برای اولین بار عکسی از Raspberry Pi Compute Module 0 (CM0) رو نشون داده! ماژولی که در واقع همون Raspberry Pi Zero 2 Wـه، ولی به شکل SoM (System on Module) البته با لبه‌های castellated برای لحیم مستقیم روی PCB.

روی این برد پردازنده RP3A0 به همراه حافظه ۱۶ گیگابایت eMMC دیده می‌شه، و فقط برای بازار چین عرضه شده (به‌خاطر کمبود جهانی حافظه LPDDR2)! این برد برای پروژه‌های صنعتی و embedded که نیاز به حجم تولید بالا و رزیری‌پای دارن و تولیدشون چین‌محوره مناسبه.

خبر خوب اینه که شرکت EDATEC تأیید کرده CM0 رسماً توی سایت Raspberry Pi لیست شده و از ژانویه ۲۰۲۶ محصولات صنعتی مبتنی بر اون در سطح جهانی عرضه می‌شه.



با اینکه محصول جذابی به نظر می‌رسه، ولی اگه دنبال یه راه‌حل کم‌مصرف، ارزان و قابل تولید انبوه برای پروژه‌های IoT یا صنعتی هستین، همین الان هم گزینه‌های جذاب‌تری توی بازار وجود داره.



📡openpcb

چند وقتیه تو شبکه های اجتماعی مثل x حرف و حدیث‌هایی درباره گجت NanoKVM پخش شده که می‌گن این گجت یه میکروفون مخفی داره و بدون اینکه کاربر بدونه، می‌تونه حریم خصوصی رو تهدید کنه. ولی وقتی می‌ری سراغ مستندات، تاریخچه‌ی ماژول و روند توسعه‌ی خود محصول، داستان یه چیز دیگه‌ست.

گجت NanoKVM یه IP-KVM متن‌بازه که روی ماژول LicheeRV Nano ساخته شده. خود LicheeRV Nano یه ماژول استاندارد RISC-Vـه و از همون اول مثل اکثر بردهای توسعه امکانات پایه مثل MIPI LCD، تاچ، اسپیکر و میکروفون داشته. یعنی این قابلیت بخشی از برد اصلی بوده، نه اینکه NanoKVM بیاد یواشکی چیزی اضافه کنه.

اولین کاربران NanoKVM معمولاً کسایی بودن که قبلاً با LicheeRV Nano به عنوان یه برد لینوکسی کوچیک کار کرده بودن! پس براشون وجود میکروفون چیز جدیدی نبود. اما وقتی محصول بیشتر سر زبون‌ها افتاد و کاربرای جدید اومدن، تازه چشمشون به میکروفون افتاد و از همین‌جا قصه‌ی «میکروفون مخفی» ساخته شد.
ولی آیا اصلا این میکروفون مشکل امنیتی ایجاد می‌کنه؟ خیر! چند دلیل ساده داره: IP-KVM ذاتاً قابلیت صوت دوطرفه داره. حتی اگه روی بورد میکروفون نباشه، اگر KVM توسط یه نفر دیگه کنترل بشه، می‌تونه از میکروفون سیستم مقصد استفاده کنه. پس خود سخت‌افزار NanoKVM موضوع جدیدی ایجاد نمی‌کنه. از طرفی درایور میکروفون ۹ ماهه حذف شده و عملاً غیر فعاله. یعنی حتی اگه میکروفون فیزیکی باشه، صدایی نمی‌تونه بگیره.

ولی چرا میکروفون همچنان تو مدل‌های Cube و Lite باقی موند؟ مدل‌های NanoKVM-Cube و NanoKVM-Lite مستقیم روی LicheeRV-Nano ساخته می‌شن. حذف میکروفون یعنی تغییر BOM، تغییر تولید، تغییر QC، و هزینه‌ی اضافه. تیم توسعه ترجیح داده همون برد رو نگه داره تا قیمت و مدیریت موجودی پیچیده نشه. از نظر تجاری و تولید کاملاً منطقیه.

واقعیت اینه که خیلی از مقاله‌ها و پست‌هایی که پخش شدن، مشکل رو بزرگ‌نمایی کردن. NanoKVM ضعف‌هایی داره، ولی ضعف‌هاش به نت‌ورک و کانفیگ اشتباه کاربرا مربوطه. نه به وجود یه میکروفون خاموش که اساساً درایور هم نداره. مزیت مهم NanoKVM اینه که متن‌بازه! یعنی جامعه‌ی توسعه می‌تونه white-box و black-box تست انجام بده و امنیت رو واقعی بهتر کنه، نه با ترس رسانه‌ای. این داستان «میکروفون مخفی» هم بیشتر نتیجه‌ی سوءتفاهم کاربرای جدید با دانش کم سخت افزاری و هیجان رسانه‌هاست.

📡openpcb

محققای دانشگاه استنفورد با همکاری کارخونه SkyWater Technology و دانشگاه‌های MIT، Penn و CMU موفق شدن اولین چیپ سه‌بعدی یکپارچه (Monolithic 3D) رو توی یه خط تولید تجاری بسازن تا قبل از این همیشه تو آزمایشگاه بوده ولی اینبار تو به صورت تجاری و تولید انبوه بوده.

این تکنولوژی برای حل مشکل گلوگاه معماری von Neumann تو چیپ‌های دوبعدی طراحی شده که توش جابجایی دیتا بین پردازنده و حافظه باعث تاخیر و مصرف انرژی زیاد میشه. راهکار این تیم استفاده از ترانزیستورهای نانولوله‌کربنی (CNFET) روی حافظه‌های RRAM بوده! چون CNFETها رو میشه توی دمای پایین ساخت، امکان لایه‌گذاری مدارات منطقی مستقیماً روی حافظه بدون آسیب زدن به لایه‌های زیرین فراهم شده.

این معماری اجازه میده اتصالات عمودی بین لایه‌ها به شدت متراکم باشن که خروجیش افزایش سرعت پردازش و بهره‌وری انرژی خیلی بالاتر برای بارهای کاری هوش مصنوعیه. نکته کلیدی این دستاورد، اثبات قابلیت تولید این چیپ‌ها با ابزارهای استاندارد صنعتیه که مسیر رو برای تولید انبوه سخت‌افزارهای نسل بعدی AI باز می‌کنه.

خبری اصلی رو می‌تونید اینجا بخونید.

📡openpcb

یه مهندس خوش ذوق به اسم Kevin Yang با پروژه‌ی Commi Board، ادعا می‌کنه که می‌تونه دنیای پروتوتایپینگ تو حوزه امبدد رو تغییر بده, ایده ایشون ساده اما رادیکاله! در نگاه اول، Commi Board شبیه یه اکسسوری MagSafe معمولیه که پشت آیفون می‌چسبه که یه برد‌بورد کوچیک بهت میده. اما نکته اصلی در نحوه ارتباطش با گوشیه.

این برد از USB-C 3.2 استفاده می‌کنه و مستقیم به پردازنده آیفون متصل می‌شه بدون هیچ میکروکنترلر واسطی. این یعنی ما یه اتصال دیتا با سرعت بالا و Latency پایین داریم که اجازه میده اپلیکیشن موبایل، پین‌های فیزیکی روی برد رو تقریباً به صورت Real-time کنترل کنه. عملاً گوشی شما تبدیل میشه به یه پردازنده چند گیگاهرتزی که پایه‌های I/O رو درایو می‌کنه.

این گجت قراره از USB-C 3.2 برای کارهای Critical و BLE برای تسک‌های سبک‌تر استفاده کنه، تغذیه رو مستقیم از باتری گوشی (بدون نیاز به Li-Po جداگانه) تامین کنه و نرم‌افزار کنترلی هم داخل گوشی نصب میشه.

قدرت اصلی Commi Board توی اپلیکیشنشه که نقش IDE، کامپایلر و دیباگر رو بازی می‌کنه. چون پردازش روی CPU موبایل انجام میشه، فیچرهایی داره که روی میکروکنترلرهای معمولی (مثل سری AVR یا حتی STM32های سبک) به این راحتی در دسترس نیست:
مثلاً Real-time Circuit Validation داره که قبل از اینکه مدار رو بسوزونید، اپلیکیشن مسیرهای احتمالی جریان و لاجیک رو چک می‌کنه.
از پرامپت‌های AI برای تست‌های سریع گرفته تا محیط بلوکی و نهایتاً یه محیط کدنویسی کامل برای پیاده‌سازی لاجیک‌های پیچید استفاده می‌کنه و شبیه‌سازی رفتار مدار قبل از اجرای فیزیکی هم داره.

طرفداراش می‌گن برای Rapid Prototyping فوق‌العاده‌ست. تصور کنید می‌خواید رفتار یه سنسور جدید I2C رو چک کنید یا یه لاجیک ساده کنترلی رو تست کنید. به جای باز کردن لپ‌تاپ و ستاپ کردن محیط VS Code و PlatformIO، گوشی رو برمی‌گردونید، سنسور رو روی برد‌بورد می‌زنید و کد رو ران می‌کنید.

به نظر من گجت بامزه‌ایه ولی تو کار حرفه‌ای بعید می‌دونم جایگاهی پیدا کنه. ریسک وصل کردن مستقیم I/O به گوشی ۱۰۰۰ دلاری (بدون ایزولاسیون مطمئن) و محدودیت‌های OS Jitter توی iOS، باعث میشه برای کارهای جدی صنعتی قابل اعتماد نباشه.


اینجا می‌تونید بیشتر در موردش بخونید.

📡openpcb

دولت هنداعلام کرده که بالاخره تونسته اولین ریزپردازنده‌ی ۶۴ بیتی دو هسته‌ای با فرکانس ۱ گیگاهرتز رو که کاملاً داخل خود کشور طراحی شده، رو بسازه. اسم این پردازنده DHRUV64 هستش و از نظر دولت هند یه نقطه‌ی عطف حساب می‌شه، چون برای اولین بار دارن از فاز «ما می‌تونیم» وارد فاز «ما تونستیم» می‌شن.

این پردازنده بخشی از برنامه‌ی Digital India RISC-Vـه! یعنی دقیقاً رفتن سراغ معماری متن‌باز RISC-V تا هم درگیر لایسنس‌های گرون و دست‌وپاگیر ARM نشن هم بتونن زنجیره‌ی طراحی تا تولید رو خودشون کنترل کنن. DHRUV64 یه پردازنده دو هسته‌ایه، ۶۴ بیتی، و برای کاربردهای نسبتاً جدی مثل زیرساخت‌های مخابراتی، 5G، سیستم‌های صنعتی، خودرو و حتی IoT در مقیاس بزرگ طراحی شده.

نکته‌ی مهم‌تر اینه که این چیپ قرار نیست اولین و آخرین نوع خودش باشه. بعد از این، نسل‌های بعدی به اسم Dhanush و Dhanush+ هم در راهن، یعنی عملاً دارن یه خانواده‌ی پردازنده درست می‌کنن، نه یه دمو یا پروژه‌ی دانشگاهی. این حرکت ادامه‌ی همون مسیر پروژه‌های قبلی هند مثل SHAKTI، AJIT، VIKRAM و THEJAS ـه که هر کدوم یه تیکه از پازل استقلال سخت‌افزاری‌شون بوده.

مشخصه هند نمی‌خواد فقط مصرف‌کننده‌ی چیپ باشه. می‌خواد طراحی، مالکیت فکری و اکوسیستم اطرافش رو خودش داشته باشه، مخصوصاً برای جاهایی که امنیت، پایداری و تحریم‌ناپذیری مهمه. برای همین هم دولت با برنامه‌هایی مثل India Semiconductor Mission و Chips to Startup داره مستقیم پول و زیرساخت می‌ریزه توی این فضا.

در مجموع، DHRUV64 شاید از نظر عدد و رقم با پردازنده‌های تجاری روز دنیا قابل مقایسه نباشه، ولی از نظر سیاسی، صنعتی و راهبردی، یه قدم بزرگ حساب می‌شه. دقیقاً همون نقطه‌ای که خیلی از کشورها دوست دارن بهش برسن.


خبر اصلی رو اینجا بخونید.

📡openpcb

بریم برای کالبدشکافی CVE-2025-68260. ماجرا از این قراره که یه فایل مشخص تو Binder کرنل لینوکس سال‌ها با C وجود داشته. یه کد C قدیمی، حوصله‌سربر، محافظه‌کارانه، ولی درست! لاک‌ها شاید کمی طولانی‌تر بودن، ولی قانونش خیلی ساده و سفت و سخت بوده: death_list همیشه زیر یه لاک واحد دستکاری می‌شد، مالکیتش هیچ‌وقت مبهم نمی‌شد، و لیست از کنترل صاحبش خارج نمی‌شد. همین.

تا اینکه یه روز تصمیم گرفته می‌شه همین تیکه کد رو با فلسفه‌ی «Rewrite it in Rust» بازنویسی کنن. نیت روی کاغذ خوبه: لاک کوتاه‌تر، کد تمیزتر، استفاده از Rust تو سطح کرنل، و طبیعتاً یه دور افتخار و کلی بوق.

تو پیاده‌سازی Rust، برای این‌که Borrow Checker راضی بشه و کد «Rusty» به نظر بیاد، تصمیم گرفته می‌شه که محتویات death_list رو موقتاً بکشن بیرون و بریزن تو یه لیست محلی، لاک رو رها کنن، بعد بیرون از لاک روش Iterate کنن.

روی کاغذ؟ عالی. لاک کوتاه‌تر شده.در عمل؟ یه قاعده‌ی همیشگی (Invariant) تاریخی Binder نابود شده.چیزی که تو نسخه‌ی C اصلاً قابل تصور نبوده، نه به‌خاطر امنیت C، بلکه به‌خاطر «ذهنیت کرنلی» که می‌گفت لیست درون‌ساختاری (Intrusive List) یا کاملاً مال لاکه، یا اصلاً وجود نداره. حد وسطی وجود نداشت. ولی تو نسخه‌ی Rust، این Invariant تبدیل می‌شه به یه کامنت قشنگ بالای یه unsafe: «این نود یا تو همین لیسته یا هیچ‌جا نیست.»
در حالی که دیگه درست نیست! نتیجه کاملاً قابل پیش‌بینیه: ایجاد Race Condition واقعی، دستکاری هم‌زمان پوینترهای prev/next، فساد حافظه، کرش کرنل، و در نهایت یه CVE رسمی.

طنز تلخ ماجرا؟ همون فایل تو نسخه‌ی C سال‌ها بدون این داستان‌ها کار کرده بوده. از نظر Performance هم داستان قشنگ نیست. نسخه‌ی Rust اینجا نه‌تنها unsafe داره، بلکه Abstraction ،Indirection ،Refcounting و پیچیدگی هم اضافه کرده. یعنی هم سربار بیشتر، هم Reasoning سخت‌تر. لاک کوتاه‌تر شده، ولی فهم کد سخت‌تر شده! و تو کرنل این دقیقاً خلاف جهته.

مسئله اینه که Rust ابزار خوبیه، ولی وقتی یه کد کرنلی بالغ و Battle-tested رو بدون نیاز واقعی و بدون بازطراحی عمیق مدل هم‌زمانی، صرفاً بازنویسی می‌کنی، احتمال این‌که بدترش کنی خیلی بالاست. مخصوصاً وقتی با Data Structureهای Intrusive و Invariantهای نانوشته سروکار داری.

از طرفی تو کرنل، کد Boring که سال‌ها درست کار کرده، یه داراییه. بازنویسی فقط به این دلیل که «می‌شه با Rust نوشت»، فضیلت نیست! می‌تونه منبع Regression، پیچیدگی و باگ جدید باشه.

این قضیه برای ما تو دنیای امبدد یه زنگ خطر جدی‌تری هم داره. وقتی منابع محدودن و دیوایس قراره سال‌ها تو فیلد بدون دسترسی فیزیکی کار کنه، «پیچیدگی» بزرگ‌ترین دشمنه. تو این سیستم‌ها ما دنبال قطعیت (Determinism) و پیش‌بینی‌پذیری (Predictability) هستیم، نه Abstractionهایی که معلوم نیست اون‌زیر چه سرباری (Overhead) دارن.

اگه قراره Rust جایگزین C بشه، باید بتونه همون سادگی و کارایی Bare-metal رو بده، نه اینکه برای حل مشکل مموری که خودش هم میتونه به بار بیاره، مشکل معماری درست کنه. تو امبدد، کدی که «شاید» Race داشته باشه ولی ۱۰ لایه رپ (Wrap) شده، خیلی ترسناک‌تر از کد C لُختیه که دقیق می‌دونی بیت‌به‌بیتش داره چیکار می‌کنه.

برای جزییات بیشتر اینجا رو بخونید.

📡openpcb