Mastering_Embedded_Linux_Programming_Create_fast_and_Frank_Vasquez.pdf
17.8 MB
این هم کتاب کامل و رایگان برای علاقه مندان
Forwarded from Sisoog مرجع متن باز الکترونیک-سیسوگ
📌امبدد لینوکس با ArmSom
👈#سیسوگ
🖋 نویسنده: #smem
📍این مقاله درباره لینوکس نهفته (Embedded Linux) است و توضیح می‌دهد چطور از دل سیستم‌های ساده‌ی مبتنی بر میکروکنترلر، نیاز به سیستم‌عامل‌های قوی‌تر برای دستگاه‌های هوشمند شکل گرفت. مزایای اصلی آن مانند متن‌باز بودن، انعطاف‌پذیری، پشتیبانی گسترده سخت‌افزاری و پایداری بالا شرح داده شده و سپس کاربردهایش در صنایع مختلف مثل خودرو، الکترونیک، IoT، شبکه و هوش مصنوعی بررسی می‌شود.
✅ در ادامه، مقاله به نقش بردهای آماده توسعه و سیستم روی ماژول (SOM) در ساده‌سازی فرایند طراحی می‌پردازد و شرکت ARMSOM را با برد CM1 به عنوان نمونه معرفی می‌کند. همچنین مراحل ساخت و راه‌اندازی گام‌به‌گام لینوکس نهفته روی این برد توضیح داده شده است.
متن کامل را می توانید در وبسایت سیسوگ مطالعه فرمایید.💯
🌐 لینک مطلب در سیسوگ
📣 عضویت در کانال تلگرام سیسوگ
👈#سیسوگ
🖋 نویسنده: #smem
📍این مقاله درباره لینوکس نهفته (Embedded Linux) است و توضیح می‌دهد چطور از دل سیستم‌های ساده‌ی مبتنی بر میکروکنترلر، نیاز به سیستم‌عامل‌های قوی‌تر برای دستگاه‌های هوشمند شکل گرفت. مزایای اصلی آن مانند متن‌باز بودن، انعطاف‌پذیری، پشتیبانی گسترده سخت‌افزاری و پایداری بالا شرح داده شده و سپس کاربردهایش در صنایع مختلف مثل خودرو، الکترونیک، IoT، شبکه و هوش مصنوعی بررسی می‌شود.
✅ در ادامه، مقاله به نقش بردهای آماده توسعه و سیستم روی ماژول (SOM) در ساده‌سازی فرایند طراحی می‌پردازد و شرکت ARMSOM را با برد CM1 به عنوان نمونه معرفی می‌کند. همچنین مراحل ساخت و راه‌اندازی گام‌به‌گام لینوکس نهفته روی این برد توضیح داده شده است.
متن کامل را می توانید در وبسایت سیسوگ مطالعه فرمایید.💯
🌐 لینک مطلب در سیسوگ
📣 عضویت در کانال تلگرام سیسوگ
سیسوگ
بردهای ARMSOM و Embedded Linux | بررسی کامل ARMSOM CM1 و راه‌اندازی با Buildroot
آموزش نحوه اجرای Embedded Linux بر روی بردهای ARMSOM آشنا می‌شوید. از معماری و ابزارهای Buildroot و Yocto گرفته تا بوت، کرنل و تست عملی توضیح داده شده است.
Sisoog مرجع متن باز الکترونیک-سیسوگ
📌امبدد لینوکس با ArmSom 👈#سیسوگ 🖋 نویسنده: #smem 📍این مقاله درباره لینوکس نهفته (Embedded Linux) است و توضیح می‌دهد چطور از دل سیستم‌های ساده‌ی مبتنی بر میکروکنترلر، نیاز به سیستم‌عامل‌های قوی‌تر برای دستگاه‌های هوشمند شکل گرفت. مزایای اصلی آن مانند متن‌باز…
من یه نکته جالب توی این مقاله دیدم که گفتم شاید برای شما هم سؤال‌برانگیز یا جذاب باشه.
موضوعش Super Loop در میکروکنترلرهای Bare Metal مثل STM32 هست.
این نوع میکروکنترلرها معمولاً خیلی کم‌مصرف، با حافظه و توان سخت‌افزاری محدود و در عوض ارزان و ساده طراحی میشن. و اغلب با زبان سی هم نوشته میشن . هدفشون اجرای چند تسک مشخص و تکراریه، مثل اینکه اگه دما از یه حدی بالاتر رفت، یه عمل خاص انجام بشه.
در برنامه‌نویسی Bare Metal، خبری از سیستم‌عامل یا Scheduler نیست. همه‌چیز مستقیم روی سخت‌افزار اجرا میشه.
به همین خاطر، معمولاً یه ساختار تکرارشونده‌ی مرکزی داریم به اسم Super Loop. این حلقه وظیفه‌ی اجرای مداوم کد اصلی رو بر عهده داره.
به‌صورت کلی ساختارش این شکلیه:
while (1) {
// Your main code here
}
تمام کارهایی که می‌خوایم به شکل پیوسته انجام بشن، داخل این حلقه نوشته میشن.
مثلاً خوندن داده از سنسور، بررسی شرط‌ها یا کنترل خروجی‌ها.
در واقع Super Loop مثل قلب برنامه‌ی Bare Metal عمل میکنه؛ همیشه در حال تپیدنه و هرگز متوقف نمیشه، مگر اینکه سیستم خاموش بشه یا وارد حالت Sleep یا Low Power بشه.
@AlgooForge
موضوعش Super Loop در میکروکنترلرهای Bare Metal مثل STM32 هست.
این نوع میکروکنترلرها معمولاً خیلی کم‌مصرف، با حافظه و توان سخت‌افزاری محدود و در عوض ارزان و ساده طراحی میشن. و اغلب با زبان سی هم نوشته میشن . هدفشون اجرای چند تسک مشخص و تکراریه، مثل اینکه اگه دما از یه حدی بالاتر رفت، یه عمل خاص انجام بشه.
در برنامه‌نویسی Bare Metal، خبری از سیستم‌عامل یا Scheduler نیست. همه‌چیز مستقیم روی سخت‌افزار اجرا میشه.
به همین خاطر، معمولاً یه ساختار تکرارشونده‌ی مرکزی داریم به اسم Super Loop. این حلقه وظیفه‌ی اجرای مداوم کد اصلی رو بر عهده داره.
به‌صورت کلی ساختارش این شکلیه:
while (1) {
// Your main code here
}
تمام کارهایی که می‌خوایم به شکل پیوسته انجام بشن، داخل این حلقه نوشته میشن.
مثلاً خوندن داده از سنسور، بررسی شرط‌ها یا کنترل خروجی‌ها.
در واقع Super Loop مثل قلب برنامه‌ی Bare Metal عمل میکنه؛ همیشه در حال تپیدنه و هرگز متوقف نمیشه، مگر اینکه سیستم خاموش بشه یا وارد حالت Sleep یا Low Power بشه.
@AlgooForge
👍2
Kernel Space
به نظرتون
باورم نمیشه که ۵ تا گربه توی گروه داریم و تا اینجای کار اکثریت رای دهنده ما گربه هستن 😂😂😂😂😂😂😂😂
❤1🔥1
Forwarded from OpenPCB
شاید براتون جالب باشه بدونید اولین میکروپروسسور دنیا یعنی Intel 4004 کاملا با دست طراحی و ساخته شد.
اون موقع هنوز خبری از CAD و نرم‌افزارهای مدرن امروزی نبود. Bob Noyce و تیمش از روشی به اسم Rubylith استفاده می‌کردن! یه ورق قرمز که ماسک لیتوگرافی رو روی اون به صورت دستی می‌بریدن.
یعنی مسیر ترانزیستورها، گیت‌ها، لایه‌ها… همش واقعاً با کاتر و خط‌کش. فکر کنید مدار چند هزار ترانزیستوری رو مثل معرق‌کاری تیکه‌تیکه کنار هم بذاری. نه Undo، نه Grid، نه DRC/ ERC… فقط چشم، دست، دقت و صبر.
همین که اینا تونستن در اون شرایط اولین میکروپروسسور تاریخ رو بسازن و جواب بده، خودش یه شاهکار واقعیه. گاهی تکنولوژی امروز رو می‌بینیم و فراموش می‌کنیم که ریشه‌اش رو یه مشت آدم با دست خالی شروع کردن. این به‌نظرم واقعاً خفنه.
📡openpcb
اون موقع هنوز خبری از CAD و نرم‌افزارهای مدرن امروزی نبود. Bob Noyce و تیمش از روشی به اسم Rubylith استفاده می‌کردن! یه ورق قرمز که ماسک لیتوگرافی رو روی اون به صورت دستی می‌بریدن.
یعنی مسیر ترانزیستورها، گیت‌ها، لایه‌ها… همش واقعاً با کاتر و خط‌کش. فکر کنید مدار چند هزار ترانزیستوری رو مثل معرق‌کاری تیکه‌تیکه کنار هم بذاری. نه Undo، نه Grid، نه DRC/ ERC… فقط چشم، دست، دقت و صبر.
همین که اینا تونستن در اون شرایط اولین میکروپروسسور تاریخ رو بسازن و جواب بده، خودش یه شاهکار واقعیه. گاهی تکنولوژی امروز رو می‌بینیم و فراموش می‌کنیم که ریشه‌اش رو یه مشت آدم با دست خالی شروع کردن. این به‌نظرم واقعاً خفنه.
📡openpcb
❤3
Forwarded from Linuxor ?
یه برد جدید اومده به اسم Arduino Uno Q که یه برد عجیب و جالبیه، این برد هيبرید و ترکیبی از معماری سیستم‑روی‌یک‌چیپ (MPU) با سیستم‌عامل لینوکس و یه میکروکنترلر (MCU) توی یه برد هستش، هم میکروکنترلر داره برای کنترل حسگرها و موتور‌ها، هم یه بخش لینوکسی مثل Raspberry Pi که می‌تونه برنامه‌های سنگین‌تر یا مدل‌های هوش مصنوعی رو اجرا کنه. یعنی هم می‌تونی پروژه‌های سخت‌افزاری رو با C++ کنترل کنی، هم با Python توی لینوکس چیزای باحال بسازی.
با این برد می‌تونید پروژه های پردازش تصویر و هوش مصنوعی انجام بدید! قیمت حدودی توی بازار 12 تومن.
@Linuxor
با این برد می‌تونید پروژه های پردازش تصویر و هوش مصنوعی انجام بدید! قیمت حدودی توی بازار 12 تومن.
@Linuxor
گوگل اخیراً در اقدامی قابل توجه، اسناد و ابزارهای مربوط به لیتوگرافی را برای گره‌های قدیمی‌ترِ تولید تراشه به‌صورت اوپن‌سورس منتشر کرد. قبلاً گوگل با SkyWater همکاری کرد و پکیج PDK برای گرهٔ ۱۳۰ نانومتر (SKY130) را باز گذاشت، و بعدتر پکیج PDK برای گرهٔ ۱۸۰ نانومترِ GlobalFoundries (GF180MCU) را هم در گیت‌هاب منتشر کرد. هدف این کار این است که اطلاعات و ابزارهای تکنیکیِ گره‌های بالغ—که دیگر محرمانه و حساس نیستند اما هنوز کاربرد دارند—را در اختیار جامعهٔ طراحی تراشه قرار دهد تا طراحی و تولید آزمایشی و آموزش و نوآوری ارزان‌تر و دم‌دست‌تر شود.
این انتشار شامل مستندات فنی، کتابخانه‌های استاندارد (standard cells)، ماکروهای SRAM، و ابزارهای مرتبط با طراحی است و تحت مجوز Apache-2.0 منتشر شده که استفاده و اشتراک‌گذاری را ممکن می‌سازد. گوگل همچنین با شرکایی مثل Efabless همکاری می‌کند تا طرح‌های اوپن‌سورس بتوانند در قالب «MPW shuttle» (چندطراحه) هزینهٔ ساخت اولیهٔ چیپ‌ها را کاهش دهند؛ به‌طور خلاصه هدف، دموکراتیزه‌کردن دسترسی به فرآیند تولید و تقویت اکوسیستم اوپن‌سیلیکون است.
این انتشار شامل مستندات فنی، کتابخانه‌های استاندارد (standard cells)، ماکروهای SRAM، و ابزارهای مرتبط با طراحی است و تحت مجوز Apache-2.0 منتشر شده که استفاده و اشتراک‌گذاری را ممکن می‌سازد. گوگل همچنین با شرکایی مثل Efabless همکاری می‌کند تا طرح‌های اوپن‌سورس بتوانند در قالب «MPW shuttle» (چندطراحه) هزینهٔ ساخت اولیهٔ چیپ‌ها را کاهش دهند؛ به‌طور خلاصه هدف، دموکراتیزه‌کردن دسترسی به فرآیند تولید و تقویت اکوسیستم اوپن‌سیلیکون است.
❤2
من براتون لینک های گیت هابش رو می‌زارم تا خواستید نگاه کنید و چک کنید
https://github.com/google/skywater-pdk
گیت هاب پروژه
https://github.com/google/gf180mcu-pdk
گیت هاب 180nm
گیت هاب 130nm
https://github.com/google/skywater-pdk
و 90nm
https://github.com/google/sky90fd-pdk
https://github.com/google/skywater-pdk
گیت هاب پروژه
https://github.com/google/gf180mcu-pdk
گیت هاب 180nm
گیت هاب 130nm
https://github.com/google/skywater-pdk
و 90nm
https://github.com/google/sky90fd-pdk
GitHub
GitHub - google/skywater-pdk: Open source process design kit for usage with SkyWater Technology Foundry's 130nm node.
Open source process design kit for usage with SkyWater Technology Foundry's 130nm node. - google/skywater-pdk
❤3
Forwarded from TechTube 𝕏 تک توب
⚡️ یکی از دغدغه های کاربران موبایل تاثیر شارژ سریع روی عمر باتری هست که کانال یوتوب HTX Studio با تستهای عملی به این سوال جواب داده.
این کانال 10 ایفون 12 و 10 گوشی iQOO 7 رو به 4 گروه تقسیم کرد:
1. 3 گوشی اندرویدی و 3 ایفون با شارژ سریع شارژ میشدن که معادل 120 وات برای اندروید و 20 وات برای ایفون بود.
2. 3 گوشی اندرویدی و 3 ایفون با سرعت پایین شارژ میشدن که معادل 20 وات برای اندروید و 5 وات برای ایفون بود.
3. 3 گوشی اندرویدی و 3 ایفون در گروهی قرار داشتن که فقط بین 30 تا 80 درصد شارژ میشدن.
4. و در نهایت یک گوشی اندرویدی و یک ایفون هم در طول این ازمایش شارژ نشدن.
بعد این کانال ظرفیت واقعی باتری اونهارو ثبت کرد و اونهارو برای 6 ماه شارژ و دشارژ میکرد.
نتیجه این بود که بعد از 500 بار شارژ کردن کامل (یعنی 500 بار 0 تا 100 و بالعکس سیکل کامل شارژ دشارژ)، ایفون 12 هایی که با فست شارژ، شارژ شده بودن فقط 0.5 درصد ظرفیت کمتری نسبت به ایفونهایی که شارژ اهسته شارژ شده بودن، داشتن. این رقم برای گوشی اندرویدی حتی کمتر و حدود 0.3 درصد بود عملا قابل چشم پوشی هست.
بنابراین فست شارژ روی عمر و دوام باتری تاثیر قابل توجهی نداره.
تاثیر شارژ کردن گوشی بین 30 تا 80 درصد هم که در جاهای مختلف برای افزایش دوام باتری پیشنهاد میشه، بعد از 500 بار شارژ کامل، برای ایفون باعث داشتن 4 درصد ظرفیت باتری میشه و برای اندروید حدود 2.5 درصد ظرفیت باتری بیشتر نسبت به حالت عادی به ارمغان میشه.
یعنی شارژ کردن گوشی فقط در این بازه، دوام باتری رو کمی بیشتر میکنه که برای بعضی افراد ممکنه به زحمتش و داشتن شارژ کمتر بیارزه، برای برخی دیگه خیر.
علاوه بر این، این کانال به سوال دیگه ای هم پاسخ داده و اونم اینه که ایا نگه داشتن گوشی تو شارژ برای مدت طولانی، مثلا شب تا صبح، تاثیر بدی روی عمر باتری هم داره؟ که حداقل برای یک هفته نگه داشتن گوشی در شارژ، هیچ تاثیری رو عمر و دوام باتری نداشته.
پیشنهاد میشه ویدیوی کامل رو در یوتوب مشاهده کنید.
🔎 notebookcheck
📍 @TechTube
این کانال 10 ایفون 12 و 10 گوشی iQOO 7 رو به 4 گروه تقسیم کرد:
1. 3 گوشی اندرویدی و 3 ایفون با شارژ سریع شارژ میشدن که معادل 120 وات برای اندروید و 20 وات برای ایفون بود.
2. 3 گوشی اندرویدی و 3 ایفون با سرعت پایین شارژ میشدن که معادل 20 وات برای اندروید و 5 وات برای ایفون بود.
3. 3 گوشی اندرویدی و 3 ایفون در گروهی قرار داشتن که فقط بین 30 تا 80 درصد شارژ میشدن.
4. و در نهایت یک گوشی اندرویدی و یک ایفون هم در طول این ازمایش شارژ نشدن.
بعد این کانال ظرفیت واقعی باتری اونهارو ثبت کرد و اونهارو برای 6 ماه شارژ و دشارژ میکرد.
نتیجه این بود که بعد از 500 بار شارژ کردن کامل (یعنی 500 بار 0 تا 100 و بالعکس سیکل کامل شارژ دشارژ)، ایفون 12 هایی که با فست شارژ، شارژ شده بودن فقط 0.5 درصد ظرفیت کمتری نسبت به ایفونهایی که شارژ اهسته شارژ شده بودن، داشتن. این رقم برای گوشی اندرویدی حتی کمتر و حدود 0.3 درصد بود عملا قابل چشم پوشی هست.
بنابراین فست شارژ روی عمر و دوام باتری تاثیر قابل توجهی نداره.
تاثیر شارژ کردن گوشی بین 30 تا 80 درصد هم که در جاهای مختلف برای افزایش دوام باتری پیشنهاد میشه، بعد از 500 بار شارژ کامل، برای ایفون باعث داشتن 4 درصد ظرفیت باتری میشه و برای اندروید حدود 2.5 درصد ظرفیت باتری بیشتر نسبت به حالت عادی به ارمغان میشه.
یعنی شارژ کردن گوشی فقط در این بازه، دوام باتری رو کمی بیشتر میکنه که برای بعضی افراد ممکنه به زحمتش و داشتن شارژ کمتر بیارزه، برای برخی دیگه خیر.
علاوه بر این، این کانال به سوال دیگه ای هم پاسخ داده و اونم اینه که ایا نگه داشتن گوشی تو شارژ برای مدت طولانی، مثلا شب تا صبح، تاثیر بدی روی عمر باتری هم داره؟ که حداقل برای یک هفته نگه داشتن گوشی در شارژ، هیچ تاثیری رو عمر و دوام باتری نداشته.
پیشنهاد میشه ویدیوی کامل رو در یوتوب مشاهده کنید.
🔎 notebookcheck
📍 @TechTube
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳1
Forwarded from OpenPCB
طبق گفته FFmpeg پچ جدید باعث شده یه تابع مهم تو پردازش ویدیو ۳.۴۶ برابر سریع‌تر بشه. ماجرا اینه که یکی از کانتریبیوترها به اسم mkver اومده تابع add_8x8basis_sse3 رو که قبلاً با C نوشته شده بود رو کاملا با اسمبلی x86 بازنویسی کرده و خروجی هم شده همین جهش سرعت جدی.
دلیلش اینه که کامپایلرهای GCC و Clang وقتی با فلگ O3 کد رو کامپایل می‌کنند، معمولاً یه سری حلقه هایی که اصلاً قرار نیست زیاد اجرا بشن رو باز می‌کنن و کد رو حجیم‌تر می‌کنن. اینجا هم اون فانکشن رو از ۱۷۶ بایت رسونده به ۱۴۰۶ بایت! تو این مدل پردازش‌ها، چون دستورهای خاص و عجیب‌غریبی مثل pmulhrsw وجود داره، کامپایلر همیشه انتخاب‌های درستی نمی‌کنه. دولوپرهای FFmpeg هم میگن: «باشه، خودمون درستش می‌کنیم.» نکته مهم اینه که لزوماً کد C مشکل نداره! این رفتار کامپایلر تو مرحله بهینه‌سازیه که گاهی خودش دردسر درست میکنه.
این اولین‌بار نیست FFmpeg از اسمبلی برای گرفتن نهایت قدرت سخت‌افزار استفاده میکنه واین همون بحث معروف چند وقت پیشه که چرا پلیر dav1d که چندتا آدم معمولی ساختنش، بعضی جاها از libgav1 گوگل بهتره. جواب همون همیشگیه: وقتی دقیق می‌دونی چی می‌خوای و خودت دستی کد اسمبلی رو می‌نویسی، خروجی معمولاً از نسخه‌ی تولیدشده توسط کامپایلر بهتره.
یه سوال هم که همیشه مطرح میشه اینه که «چرا این مشکلات رو به سازنده‌های کامپایلر گزارش نمی‌کنن؟» گزارش می‌دن، ولی تا نسخه جدید کامپایلر بیاد مدت‌ها طول می‌کشه. یعنی عملاً بهترین کار اینه که خودشون همزمان دست به آچار باشن و مشکل رو دور بزنن.
برای همین پروژه‌هایی مثل FFmpeg اینقدر ارزشمندن. از یه طرف همیشه تو بهینه‌ترین حالت ممکنه، از یه طرف دیگه همین مواردی که پیدا می‌کنن عملاً به کل کامیونیتی C و کامپایلرها سود می‌رسونه و باعث میشه ابزارهایی که همه استفاده می‌کنن، کم‌کم بهتر بشن.
📺Source
📡openpcb
دلیلش اینه که کامپایلرهای GCC و Clang وقتی با فلگ O3 کد رو کامپایل می‌کنند، معمولاً یه سری حلقه هایی که اصلاً قرار نیست زیاد اجرا بشن رو باز می‌کنن و کد رو حجیم‌تر می‌کنن. اینجا هم اون فانکشن رو از ۱۷۶ بایت رسونده به ۱۴۰۶ بایت! تو این مدل پردازش‌ها، چون دستورهای خاص و عجیب‌غریبی مثل pmulhrsw وجود داره، کامپایلر همیشه انتخاب‌های درستی نمی‌کنه. دولوپرهای FFmpeg هم میگن: «باشه، خودمون درستش می‌کنیم.» نکته مهم اینه که لزوماً کد C مشکل نداره! این رفتار کامپایلر تو مرحله بهینه‌سازیه که گاهی خودش دردسر درست میکنه.
این اولین‌بار نیست FFmpeg از اسمبلی برای گرفتن نهایت قدرت سخت‌افزار استفاده میکنه واین همون بحث معروف چند وقت پیشه که چرا پلیر dav1d که چندتا آدم معمولی ساختنش، بعضی جاها از libgav1 گوگل بهتره. جواب همون همیشگیه: وقتی دقیق می‌دونی چی می‌خوای و خودت دستی کد اسمبلی رو می‌نویسی، خروجی معمولاً از نسخه‌ی تولیدشده توسط کامپایلر بهتره.
یه سوال هم که همیشه مطرح میشه اینه که «چرا این مشکلات رو به سازنده‌های کامپایلر گزارش نمی‌کنن؟» گزارش می‌دن، ولی تا نسخه جدید کامپایلر بیاد مدت‌ها طول می‌کشه. یعنی عملاً بهترین کار اینه که خودشون همزمان دست به آچار باشن و مشکل رو دور بزنن.
برای همین پروژه‌هایی مثل FFmpeg اینقدر ارزشمندن. از یه طرف همیشه تو بهینه‌ترین حالت ممکنه، از یه طرف دیگه همین مواردی که پیدا می‌کنن عملاً به کل کامیونیتی C و کامپایلرها سود می‌رسونه و باعث میشه ابزارهایی که همه استفاده می‌کنن، کم‌کم بهتر بشن.
📺Source
📡openpcb
👍2
Forwarded from Blue Moon
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Blue Moon
Please open Telegram to view this post
VIEW IN TELEGRAM