Runtime: Arm6 Raspberry PI Zero - PI 1

لا ، لا يوجد مثل هذا الجهد. ربما تكون المشكلة الأكبر التي يجب حلها هي أن JIT لا يدعم ترميز تعليمات إبهام ARM6.

إذن ماذا علي أن أتوقع؟ هل هناك أي فرصة لوجود التزام من المجتمع أو MS لتقديم دعم Arm6 أم أن الطريقة الوحيدة هي Mono؟

سأكون رائعًا إذا كان هناك دعم لوحدة المعالجة المركزية ARMv6 مثل Pi Zero و Pi Zero W. بالنسبة لبعض حالات الاستخدام ، ليست هناك حاجة لاستخدام ARMv7 أكثر قوة مثل Pi 3.

أرغب في رؤية ARMv6 مدعومًا :)

أوافق على أنه يجب عليك تضمين دعم ARMV6. أريد تشغيل dotnet core في Pi Zero الآن أنا عالق مع mono.

أي كلمة عن دعم armv6؟ لدي اثنين من أصفار pi في انتظار غرض ما ..

janvorli إذا كانت JIT هي المشكلة ، هل يمكن أن نتوقع .Net Core على CoreRT لتمكين هذا؟

dcuccia CoreRT يستخدم نفس مترجم JIT مثل CoreCLR لذلك تبقى المشكلة.

dcuccia ، mikedn ، يحتوي corert على وضع يتم فيه التحويل البرمجي إلى C ++ ، بحيث يمكن أن يحل المشكلة. ومع ذلك ، فقد فقدت المسار حول مقدار الأشياء التي تعمل بالفعل في هذا الوضع. jkotas هل يمكنك تقديم بعض التفاصيل حول ذلك؟

يقوم CppCodeGen بتشغيل برامج بسيطة (مرحبًا بالعالم ، وما إلى ذلك). من https://github.com/dotnet/corert#platform -support: الميزات الكبيرة المفقودة هي الانعكاس وجمع القمامة ومعالجة الاستثناءات.

أوافق على أن CoreRT + CppCodeGen سيكون خيارًا جيدًا للوصول إلى النظام الأساسي.

jkotas هل قرأت هذا بشكل صحيح - باتباع المثال من corert -> https://github.com/dotnet/corert/tree/master/samples/WebApi يمكنني تجميع ذلك باستخدام cppCodeGen ويمكن تشغيله على rasp pi صفر؟

أم أنها ستظل تفشل بسبب وجود ARMv6 فقط؟

CppCodeGen غير كامل جدًا لعينة WebApi. يجب أن يعمل التفكير وجمع القمامة أولاً.

شكرًا jkotas - ولكن بعد ذلك سيعمل عالم مرحبًا وبعض عناصر عملاء IO / http الأساسية؟

httpclient هو جزء معقد جدًا من التعليمات البرمجية. يمكنك تجربتها ، لكنني أشك في أنها ستعمل مع CppCodeGen اليوم.

هل هناك نية لتقديم الدعم لـ ARMv6؟

أنا أيضًا مهتم جدًا برؤية دعم ARMv6. يبدو أن النواة تقترب ، لكنني لست مؤهلاً للحكم جيدًا.

إضافة +1 لدعم ARMv6. تبلغ فجوة السعر بين rPi0w و rPi3 25 دولارًا ، مما يجعل Pi Zero W أكثر فائدة لمشاريع إنترنت الأشياء حيث يتم استخدام الكثير من الأجهزة. هل من الممكن أن نعيد استخدام بعض الأكواد من Mono لهذا الغرض؟

وأنا أيضا أميل إلى الموافقة. هناك مجتمع أكبر يريد تشغيل Linux أفضل بكثير على Pi ، بما في ذلك Pi Zero ثم فقط الإصدارات التي يدعمها مجتمعهم.

هذا يتجاوز Pi / Zero ، لما يستحق. يفتح دعم ARMv6 الأبواب أمام مجموعة واسعة من وحدات التحكم الدقيقة. إن توفر .NET كخيار في هذا النظام البيئي سيكون ذا أهمية كبيرة ، وسيوفر مزيدًا من الاهتمام / التغطية لجوانب إنترنت الأشياء لـ CoreRT.

سأفكر في هذه الخطوة 1 في تسلسل يرى في النهاية .NET كخيار للبرمجة في أنظمة التشغيل في الوقت الفعلي. بعبارة أخرى ، من فضلك لا تساوي ببساطة دعم ARMv6 مع دعم Raspberry Pi Zero ، حيث إنه يذهب إلى أبعد من ذلك بالمعنى الفوري (العديد من MCUs الأخرى التي تستخدم مجموعة التعليمات هذه ، ولن يتم الانتقال إلى أي مكان قريبًا للحصول على طاقة منخفضة / cost MCUs) ، وعوالم أخرى بالمعنى التجريدي (مثل رؤية هدف CoreRT PAL لـ FreeRTOS أو ما شابه).

metanoic أتفق معك تمامًا. وهذا من شأنه أن يساعد في نقل IoT Edge أيضًا (https://github.com/Azure/iotedge/issues/12)

يجب أن يكون لدينا منصة إنترنت الأشياء في أيدينا بأقل من 10 دولارات!

+1

يوافق. في الواقع أنا عالق مع Mono :)

بناء بعض عناصر إنترنت الأشياء على armv6. جئت هنا حزينة. تريد إضافة +1 الخاص بي إلى هذه المشكلة.

هل لدى أي شخص أي تحديث بشأن ما إذا كان هناك تقدم يتم إحرازه في هذا الشأن؟ لقد حاولت للتو التفكير في أنه سيعمل كما هو الحال في pi3b +. لقد نسيت أنهما معالجان مختلفان :(

لديّ نموذج Raspberry Pi قديم B (وحدة المعالجة المركزية armv6l) وأرغب في تشغيل بعض مشاريع dotnet الأساسية عليه

لدي العديد من الخوادم المصغرة القائمة على وحدة المعالجة المركزية ARMv6 مع Linux & Mono. هل ترغب في تحويلها إلى .NET core.

سوف يصوت أيضا لدعم armv6! +1

+1 لدعم armv6!

+1 سيكون من الرائع الحصول عليه

نعم!

لو سمحت!

سيكون رائعا حقا!

مجرد فضول ، هل هناك سبب تقني يجعل على سبيل المثال وقت تشغيل Go يمكن أن يجمع إلى العديد من البنى باستخدام نفس المترجم ، ولكن بالنسبة لـ CoreCLR يبدو أنه عملية أطول لإضافة دعم القوس؟ https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63

@ mms- نعم ، هناك سبب تقني. تم تجميع Go مسبقًا. يحتوي على مترجمين - gc يدعم فقط x86 (32 و 64 بت) و arm و gccgo في دول مجلس التعاون الخليجي كخلفية لها. لذا مهما كانت البنى التي يدعمها مجلس التعاون الخليجي ، فإنهم يحصلون عليها مجانًا.
يستخدم CoreCLR JIT ، لذلك نحن وحدنا لإضافة دعم للهياكل الجديدة.

يجعل الشعور بالكمال. سيكون من المثير للاهتمام إذا تم توسيع .Net Native لتمكين هذا المسار نفسه لـ .Net Core على هذه البنى الأخرى حيث لا يوجد JIT بعد.

إضافة تصويتي ل ARMv6

نحن بحاجة إلى هذا!

ARMv6 لديه الكثير من الجاذبية وراء Raspberry Pi Zero. على سبيل المثال ، تقوم وحدة Raspberry Pi Compute 1 بتشغيل ARMv6 وتجعل الاعتماد على dotnet أكثر أمانًا. حاليًا ، يجب استخدام وقت تشغيل Mono وهو أمر جيد ، لكن دعم dotnet المناسب هو شيء أرغب فيه حقًا.

تضمين التغريدة

سيكون دعم ARMv6 رائعًا.

هل يمكن لأي شخص أن يشرح لماذا تحتاج Core إلى JIT وبالتالي لا يمكنها العمل على Armv6 ، لكن Mono يمكنها ذلك؟ من المؤكد أن Mono لديها JIT لأنها تحتاج فقط إلى رمز IL للتشغيل - يجب أن يتم الانتقال إلى وحدة المعالجة المركزية المحلية؟

هل يمكن لأي شخص أن يشرح لماذا تحتاج Core إلى JIT وبالتالي لا يمكنها العمل على Armv6 ، لكن Mono يمكنها ذلك؟

يحتوي Mono على JIT مختلف يدعم Armv6. لا يدعمها CoreCLR JIT. يحتوي ARM على مجموعتين من التعليمات - ARM و THUMB. يحتوي ARM v6 على THUMB ، بينما يحتوي ARM v7 على THUMB2.
يقوم Mono JIT بتجميع كل شيء في مجموعة تعليمات ARM ، لذلك فهو يعمل على كل من Armv6 و v7 ، لكن هذا ينتج عنه مساحة ذاكرة أكبر بنسبة 30 ٪ تقريبًا من الكود.
الاختلافات بين Armv7 THUMB2 و Armv6 THUMB كبيرة جدًا وإضافة دعم لـ Armv6 سيتطلب الكثير من التغييرات على CoreCLR JIT.

NET Core 3.0 في الخارج ، 3.1 على الأبواب ، 5.0 مخطط له ويتم الإعلان عنه كمنصة موحدة .
يستخدم Blazor Mono ، ولا يمكن اختيار JIT عند إنشاء مشروع جديد (تحديد الهدف) ، إذا تم تحديد ARMv7 ، فيجب استخدام CoreCLR إذا كان ARMv6 ثم Mono-like JIT.

سعر Raspberry Pi 4 هو 35 دولارًا على الأقل ، و Pi Zero هو 5 دولارات ، و Pi Zero W هو 10 دولارات. لذا مقابل سعر Pi 4 واحد تحصل على 7 أصفار Pi!

وكما كتب آخرون من قبل ، فإن هذا لا يتعلق فقط بـ Raspberry Pi Zero ، حيث يمكن لجميع أجهزة ARMv6 تشغيل تطبيقات .NET Core.

بعد 2.5 سنة ما زلنا ننتظر 🙂

+1

هناك علاقات عامة تسمى دعم armv6 في مشروع وقت التشغيل: https://github.com/dotnet/runtime/pull/657

الرجاء إضافة هذا الدعم

أنا في انتظار هذا الدعم أيضًا ...

سيكون دعم Armv6 لـ net core رائعًا ...

أي كلمة عن دعم armv6؟ لدي اثنين من أصفار pi في انتظار غرض ما ..

شكر

الرجاء إضافة دعم لـ armv6

https://blogs.windows.com/windowsdeveloper/2020/05/26/build-your-iot-devices-with-windows-for-iot-a-compuate-platform-for-every-device-developer/

نحن متحمسون لمشاركة ذلك من الآن فصاعدًا ، هناك إصدار واحد لنظام تشغيل Windows لـ IoT و Windows 10 IoT Enterprise يمكنه تلبية هذه الاحتياجات.

قد أكون تفسيرًا خاطئًا لهذا الأمر ، لكنه يجعلني أشعر بالقلق من أنه لن يكون هناك المزيد من IoT Core لـ RPi ما لم يكن ARM64.

miloush لا أعتقد أن هذه المشكلة لها أي شيء مع Windows IoT. الموضوع هنا هو إضافة دعم dotnet إلى معالج armv6 حتى نتمكن من تشغيل dotnet على Raspberry Pi Zero.

تضمين التغريدة

من القراءة أعلاه ، يبدو أن دعم ARM6 غير مرجح بسبب العمل المطلوب لمجموعة تعليمات الإبهام. هل لدى أي شخص آخر خبرة في تشغيل dotnet core على أجهزة أخرى منخفضة التكلفة مثل Orange Pi Zero؟

تم إغلاق PR # 657 لإضافة ARMv6 ...

جئت إلى هنا بسبب مشروع NET Core. نحتاج إلى تشغيل RPi Zeros في المدرسة حيث لدينا حوالي 25 ضعفًا من RPi Zeros تم شراؤها لهذا المشروع. ليس لدينا ، ولن نشتري 25 RPi 3s جديدة لأن .NET Core لا يدعم ARMv6.

أعتقد أنني سأعيد كتابة المشروع في Golang ...

@ eduncan911 جرب السير في الطريق الأحادي. إليك بعض التفاصيل.

يجب أن يدعم Net6 بنى وحدة المعالجة المركزية المتعددة عبر وقت التشغيل الأحادي. يمكن.

أنا أقوم بتشغيل أكثر من ألف من أجهزة وحدة المعالجة المركزية ARMv6 عبر أحادية. منذ 3 سنوات ، قدمنا ​​أجهزة ARMv7 ، التي لا تزال أحادية اللون ، ولكننا الآن نقوم بإعادة البناء والترحيل إلى Net core / net standard ، لذلك سيكون الملف القابل للتنفيذ الصغير فقط مختلفًا ويتم إعادة استخدام المكتبات بين mono و net core.

كذلك هنا. أركض لوحات النتائج في ملعب لورد للكريكيت من بي 1
و Pi B + باستخدام Mono. تعمل المجموعة الأحدث على تشغيل Pi 3 باستخدام Net Core. نفس
ملفات المصدر ، مع كائن أساسي يقوم بالعمل. في مجال العمل
والتطبيقات الأساسية ، يقوم فقط بإنشاء كائن الخدمة وتحميل التطبيق
التكوين فيه.

بريان كروتاز
منحني فضي

للأسف أحادية مليئة بالأخطاء. البق لن يصلحها أحد على الإطلاق. معظمهم مرتبطة بالشبكة. على سبيل المثال ، في بعض الشبكات عندما يكون نظام أسماء النطاقات متاحًا ولكن هناك مشكلة في حركة المرور العادية - تتسبب تدفقات https / ssl في حدوث تسرب في الذاكرة مما قد يؤدي إلى تآكل الذاكرة بأكملها. أو لم يتمكن mono من الاتصال على بعض الشبكات دون اللعب بحجم MTU. لكن لا يواجه Python أو NET Core مشاكل في الاتصال.

من المثير للدهشة أن أحادية اللون تكون أحيانًا أسرع من الشبكة الأساسية ، على الأقل في ARMv7. ليس دائمًا ، لكنني توقعت أن يفوز net core بسباق الأداء بهامش ضخم.

أجد صعوبة في تصديق أن Mono مليئة بالأخطاء ، لكنها قد تعتمد على التطبيق. يتم تنفيذ Blazor WASM في Mono وإذا كانت هناك مشكلات متعلقة بالشبكة فستكون مشكلة كبيرة.

أحادية: من Xamarin إلى WebAssembly و Blazor و .NET 5

سي سي @ ماريك سفار

أقوم بتشغيل أحادي على عدة آلاف من الأجهزة والعديد من تكوينات الشبكة. لا تحدث هذه الأخطاء في كل تكوين الجهاز والشبكة. لديهم نفس صورة لينكس.

مشكلة حجم MTU - 0.3٪ من التثبيتات - على هذه الشبكة قابلة للتكرار بنسبة 100٪. ليس لدي فكرة تماما لماذا. لكن ssh يعمل على هذه الشبكات وحقيقة أنني مضطر لتغيير حجم mtu تم اكتشافها عن طريق الصدفة فقط.

تسرب ذاكرة SSL Stream - 2٪ من عمليات التثبيت. كان من الصعب جدًا إعادة إنتاجه ، وفي النهاية نجحنا في إعادة إنتاجه باستخدام جهاز توجيه 4G مع البيانات المستهلكة ، لذلك يعمل نظام أسماء النطاقات فقط ، والطلب الآخر لا يعمل. لكن لم نتمكن من محاكاته باستخدام محاكي خطأ tcp على شبكة LAN العادية. نستخدم موجه 4G وبطاقة SIM محددة لمحاكاة هذا التسرب. يحدث عادةً عند التثبيت مع 4G أو شبكات لاسلكية أخرى. يبدو أنه في حالة عدم اكتمال مصافحة TCP لاتصال TCP & HTTPS ، يؤدي ذلك إلى حدوث تسرب.

من وقت لآخر ، نواجه خطأً ، وأحيانًا يتم إصلاحه في وقت قصير ، وأحيانًا نجربه وبمجرد أن أصلحه في أحادي وتم قبول طلب السحب (مرتبط أيضًا بالشبكة) :) ولكن لكي نكون منصفين ، هذا الأسبوع وجدت (وأبلغت) عن خطأ في NET5 RC1. بالنسبة لي ، تعد mono قطعة ممتازة من البرامج (أعمل معها لمدة 9 سنوات) ولكن بها بعض الثغرات في كود الشبكة.

عادل بما فيه الكفاية ، لكن وصف Mono بأنه مليء بالأخطاء هو أمر غير عادل بعض الشيء. من المؤكد أن مجموعة أجهزة التوجيه / بطاقة SIM من الجيل الرابع تبدو وكأنها حالة متطورة ، وأنا أشجعك على إنشاء مشكلة في Mono repo وتقديم أكبر قدر ممكن من المعلومات. حتى إذا لم يتم حلها ، يمكن للآخرين على الأقل الذين يعانون من نفس المشكلة اكتشاف الخطأ. شكرًا لمساهماتك السابقة في مستودعات Mono / NET5.

حسنًا ، آسف ، هذا غير عادل.

لكننا فقدنا عدة مئات من ساعات العمل في العثور على سبب وجود هذه المشاكل في بعض المنشآت. يمكن استخدام Mono بشكل خاص للتطبيقات قصيرة العمر - مثل الهاتف المحمول. لدينا بعض التركيبات التي لدينا فيها وقت تشغيل يزيد عن عام ، ولكن في بعض الأحيان يكون ذلك مشكلة.

michaldobrodenka راجع للشهادة الخاصة بك مثيرة جدا للاهتمام!

هل سيتم تضمين دعم ARMv6 في .NET 6.0؟

ذكر ريتشارد لاندر شيئًا حول هذا الموضوع في تعليقات إعلان .NET 5 Preview 4
https://devblogs.microsoft.com/dotnet/announcing-net-5-preview-4-and-our-journey-to-one-net/#comment -5958

تفكيري في ذلك هو أننا سنستخدم Mono لـ Armv6 كجزء من .NET 5.0. نحن في الغالب جميع المشاريع ذات الصلة Mono / Xamarin 6.0. آمل أن نتمكن من تمويل بناء Mono Armv6 في 6.0.