1984 CASIO watch that has a touch screen with gesture control calculator!


📌 ماشین حساب لمسی در «کاسیو ۱۹۸۴»

البته بیش از آنکه تکنولوژی به کار رفته برای تشخیص لمس و حرکات دست شگفت‌انگیز باشد، آن‌هم با تکنولوژی‌های موجود آن زمان (۱۹۸۴)، جسارت تغییر و نوآوری و تعهد به کیفیت بوده است. چیزی که برای پیشرفت صنعت بومی یک کشور نیاز است.

هشتگ #نوستالژی را دنبال کنید.

@embedded

Classification of AI technology and its allied functions showing applications in manufacturing sector

#AI
@embedded

✅ GNSS vs GPS

📌 جایگزینی سیستم‌های مبتنی بر GPS با GNSS توسط کمپانی‌های بزرگ در حال انجام است. شرکت Nikon تولید کننده مطرح دوربین‌های عکاسی هم در مدل‌های جدید خود از GNSS بجای GPS استفاده کرده است.

👈 اما GNSS چیست؟
🛰️ سامانه ماهواره‌ای ناوبری جهانی (Global Navigation Satellite System)، امواجی که طرف ماهواره های موجود در مدار دریافت می کند و با کمکی که از گیرنده های زمینی می گیرد می تواند محل دقیق یک نقطه را در فضای سه بعدی مشخص کند. این سیستم از سیستم‌های زیر تشکیل شده است:

GPS که متعلق به ایالت متحده آمریکا است.
GALILEO مربوط به اتحادیه اروپا
Compass متعلق به کشور چین
Beidou مربوط به کشور چین
GLONASS برای کشور روسیه می باشد.

🔺در کنار دقت در موقعیت‌یابی، استقلال طلبی فناوری و دلایل سیاسی و امنیتی، باعث اقبال شرکتهای بزرگ از این سامانه و جایگزینی آن شده است.
#GNSS
#GPS

@embedded

🔺Comparision of C++ and Posix Threads

✍️ B4b4k

What is the difference between using the C++ std threads and POSIX threads?

API: The API for C++ std threads and POSIX threads are different, with different function names and parameters. The C++ std thread library is part of the C++ standard library and provides a C++ interface, while the POSIX threads library is a separate library that provides a C interface.

Implementation: The implementation of C++ std threads and POSIX threads may differ depending on the specific platform and implementation details. C++ std threads are typically implemented using a combination of user-level and kernel-level threads, while POSIX threads are typically implemented using kernel-level threads.

Portability: C++ std threads are part of the C++ standard library, which makes them more portable than POSIX threads, which are a separate library and may not be available on all platforms.

Exception handling: C++ std threads support exception handling, while POSIX threads do not. This means that in C++ std threads, exceptions can be propagated across thread boundaries, while in POSIX threads, exceptions must be caught and handled within the same thread.

Synchronization primitives: C++ std threads provide a set of synchronization primitives, such as mutexes, condition variables, and atomic operations, that are designed to work with the C++ language and its memory model. POSIX threads provide similar synchronization primitives, but they are designed to work with the C language and may require more low-level manipulation of shared memory.


#Cpp
#Multithreading
#POSIX

@embedded

برای استفاده از یادگیری عمیق برای پردازش صوت و گفتار یکی از تکنیک‌های مورد کاربرد تبدیل داده تک بعدی صوتی به داده‌های دوبعدی است. این عملیات اصطلاحا بصری‌سازی (Visualization) نام دارد. [این کار با تبدیل‌های فرکانسی صورت می‌پذیرد.]

این مقاله کوتاه، برخی از مهم‌ترین تکنیک‌های مرتبط را توضیح می‌دهد.


#CNN
#Speech_Processing
#Librosa
@embedded

📰 #آگهی_استخدام/امریه
📍 #تهران
#تمام_وقت

یک شرکت دانش بنیان جهت تکمیل تیم توسعه سیستم نهفته خود، به یک توسعه دهنده حرفه ای با شرایط زیر نیازمند است:

🔸فارغ التحصیل رشته الکترونیک
🔸تجربه کد نویسی با STM32 و ESP32
🔸آشنا با کدنویس cpp
🔸توانایی کدنویسی ماژولار
🔸تسلط و درک از معماری پردازنده های STM32
🔸تجربه کدنویسی برای ماژول های مختلف میکروکنترلرهاEthernet port , USB port ,SPI,UART, CAN, ...
🔸مسلط به کامپایلر Keil
🔸مسلط به Free RTOS
🔸مسلط به محیط STM32CubeMX
🔸توانایی دیباگ سخت افزار
🔸توانایی مستندسازی و گزارش نویسی

معرفی شرکت:
شرکت دانش بنیان مستقر در دانشگاه شريف.

امكان جذب به صورت امریه سربازی برای آقایان وجود دارد.

ارسال رزومه به:
[email protected]

📌 فرصت‌های شغلی مرتبط با مهندسی نهفته 👇
@embedded

«Minimum Viable Architecture»

A presentation by Randy Soup, Chief Architect at Ebay, introducing this idea based on his experiences and evolutions of famous technology giants such as Amazon, Google and so on.

Watch This Presentation at YouTube

#SoftwareArchitect
#Microservices
#AgileDevelopment
@embedded

Gall's Law

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
قانون گال:
یک سیستم پیچیده که کار می‌کند، تکامل یافته سیستم ساده است که کار می‌کرده. سیستم پیچیده‌ای که از ابتدا طراحی شود، هیچگاه کار نمی‌کند و نمی‌توان عیب‌یابی کرد. شما مجبورید با سیستم ساده کارا شروع کنید.

from Gall's book Systemantics: How Systems Really Work and How They Fail

#SystemDesign
@embedded

🤔 خیلیا میپرسن بهترین آموزشگاه که تضمینی آموزش میده کجاس ؟

🔘ما نیرا سیستم رو به شما معرفی می کنیم :
@nirasystem

‼️ بهترین دوره ها و کارگاه های آموزشی برق الکترونیک

🔸 آموزش مهارت های مورد نیاز بازارکار
🔹 آموزش کاملا عملی و پروژه محور
🔸کارآموزی در واحدهای فنی نیرا
🔹معرفی به واحدهای صنعتی برای استخدام



🎯 آینده را اکنون بساز|نیراسیستم

عضویت 👇👇👇

@nirasystem

مشاهده دوره های آموزشی:
www.nirasystem.com

✅ Where Complexity Fails Us

✍ Jack Ganssle

Engineering is about numbers. Do you specify a ±5% resistor or ±1%? Do the math! Will all of the signals arrive at the latch at the proper time? A proper analysis will reveal the truth. How hot will that part get? Crunch the numbers and pick the proper heat sink.

Alas, software engineering has been somewhat resistant to such analysis. Software development fads seem more prominent than any sort of careful analysis. Certainly, in the popular press "coding"1 is depicted as an arcane art practiced by gurus using ideas unfathomable to "normal" people. Measure stuff? Do engineering analysis? No, that will crowd our style, eliminate creativity, and demystify our work.

I do think, though, that in too many cases we've abdicated our responsibility as engineers to use numbers where we can. There are things we can and must measure.

One example is complexity, most commonly expressed via the McCabe Cyclomatic Complexity metric. A fancy term, it merely means the number of paths through a function. One that consists of nothing more than 20 assignment statements can be traversed exactly one way, so has a complexity of one. Add a simple if and there are now two directions the code can flow, so the complexity is two.

There are many reasons to measure complexity, not the least is to get a numerical view of the function's risk (spoiler: under 10 is considered low risk. Over 50: untestable.)

To me, a more important fallout is that complexity tells us, in a provably-correct manner, the minimum number of tests we must perform on a function to guarantee that it works. Run five tests against a function with a complexity of ten, and, for sure, the code is not completely tested. You haven't done your job.

What a stunning result! Instead of testing to exhaustion or boredom we can quantify our tests.

Alas, though, it only gives us the minimum number of required tests. The max could be a much bigger number.

Consider:

if ((a && b) (c && d) (e && f))...
Given that there's only two paths (the if is taken or not taken) this statement has a complexity of 2. But it is composed of a lot of elements, each of which will affect the outcome. A proper test suite needs a lot more than two tests. Here, complexity has let us down; the metric tells us nothing about how many tests to run.

Thus, we need additional strategies. One of the most effective is modified condition/decision coverage (MC/DC). Another fancy term, it means making sure every possible element in a statement is tested to ensure it has an affect on the outcome.

Today some tools offer code coverage: they monitor the execution of your program and tag every statement that has been executed, so you can evaluate your testing. The best offer MC/DC coverage testing. It's required by the most stringent of the avionics standards (DO-178C Level A), which is partly why airplanes, which are basically flying computers, aren't raining out of the sky.

Use complexity metrics to quantify your code's quality and testing, but recognize its limitations. Augment it with coverage tools.


Footnotes:

1 I despise the word "coding." Historically coding was the most dreary of all activities: the replacement of plain text by encrypted cipher. Low-level functionaries, or even machines, did the work. Maybe "coding" is an appropriate term for script kiddies or HTML taggers. If we are coders you can be certain that in very short order some AI will replace us. No, we in the firmware world practice2 software engineering: implementing complex ideas in software using the precepts of careful engineering. These include analysis, design, negotiating with customers, implementation and measurements of our implementations.

2 Bob Dylan got it right: "he not busy being born is busy dying". We should be forever practicing software engineering. Practice: "perform (an activity) or exercise (a skill) repeatedly or regularly in order to improve or maintain one's proficiency." Unless we're constantly striving to improve we'll be dinosaurs awaiting the comet of our destruction.

@embedded