Runtime: Arm6 Framboesa PI Zero - PI 1

Não, não existe esse esforço. Provavelmente, o maior problema que precisaria ser resolvido é que o JIT não suporta a codificação de instruções ARM6 Thumb.

Então o que devo esperar? Existe alguma chance de haver compromisso da comunidade ou MS para trazer suporte ao Arm6 ou a única maneira é Mono?

Eu seria fantástico se houvesse suporte para cpu ARMv6 como Pi Zero e Pi Zero W. Para alguns casos de uso, não há necessidade de usar um ARMv7 mais poderoso como Pi 3.

Adoraria ver o ARMv6 suportado :)

Concordo que você deve incluir suporte para ARMV6. Eu quero executar o dotnet core no Pi Zero agora estou preso ao mono.

Alguma palavra sobre o suporte armv6? Eu tenho dois pi zeros apenas esperando por um propósito ..

@janvorli Se o JIT for o problema, podemos esperar que o .Net Core no CoreRT habilite isso?

@dcuccia CoreRT usa o mesmo compilador JIT que CoreCLR, então o problema permanece.

@dcuccia , @mikedn o corret tem um modo no qual compila em C++, para que possa resolver o problema. No entanto, perdi a noção de quanta coisa realmente funciona nesse modo. @jkotas você pode fornecer alguns detalhes sobre isso?

O CppCodeGen executa programas simples (hello world, etc.). De https://github.com/dotnet/coret#platform -support : Os grandes recursos ausentes são reflexão, coleta de lixo e tratamento de exceção.

Concordo que CoreRT + CppCodeGen seria uma boa opção para o alcance da plataforma.

@jkotas Eu li isso correto - seguindo o exemplo de corert -> https://github.com/dotnet/coret/tree/master/samples/WebApi eu posso compilar isso com cppCodeGen e ele pode ser executado no meu rasp pi zero?

Ou ainda falhará devido a apenas ter ARMv6?

CppCodeGen está muito incompleto para a amostra WebApi. A reflexão e a coleta de lixo teriam que funcionar primeiro.

obrigado @jkotas - mas então um olá mundo e algumas coisas básicas de IO/httpclient funcionarão?

httpclient é um pedaço de código bastante complexo. Você pode tentar, mas duvido que funcione com o CppCodeGen hoje.

Existe alguma intenção de fornecer suporte para ARMv6?

Também estou muito interessado em ver o suporte ARMv6. Parece que o core está se aproximando, porém não estou qualificado para julgar bem.

Adicionando meu +1 para suporte ARMv6. A diferença de preço entre rPi0w e rPi3 é de US$ 25, tornando o Pi Zero W muito mais útil para projetos de IoT onde muitos dispositivos são usados. É possível reutilizarmos algum código do Mono para isso?

E também estou inclinado a concordar. Há uma comunidade ainda maior que deseja executar um Linux muito melhor no Pi, incluindo o Pi Zero, do que apenas os lançamentos suportados pela comunidade.

Isso vai muito além do Pi/Zero, vale o que vale. O suporte ao ARMv6 abre as portas para uma vasta gama de microcontroladores. Ter o .NET disponível como opção nesse ecossistema seria de grande importância e forneceria substancialmente mais interesse/cobertura sobre os aspectos de IoT do CoreRT.

Eu consideraria esta etapa 1 em uma sequência que eventualmente veria o .NET como uma opção para programação em sistemas operacionais de tempo real. Em outras palavras, por favor, não equacione simplesmente o suporte ARMv6 com o suporte Raspberry Pi Zero , pois vai muito mais longe do que isso no sentido imediato (muitos outros MCUs que usam esse conjunto de instruções, e não vai a lugar nenhum tão cedo para baixo consumo de energia /cost MCUs) e mundos além no sentido mais abstrato (por exemplo, vendo um destino CoreRT PAL para FreeRTOS ou similar).

@metanoic concordo plenamente com você. E isso também ajudaria na portabilidade do IoT Edge (https://github.com/Azure/iotedge/issues/12)

Devemos ter uma plataforma IoT em nossas mãos por menos de 10$!

+1

Aceita. Na verdade eu estou preso com Mono :)

Construindo algumas coisas de IoT no armv6. Veio aqui triste. Quero adicionar meu +1 a este problema.

Alguém tem alguma atualização sobre se há progresso sendo feito sobre isso? Eu apenas tentei pensar que funcionaria como no pi3b +. Esqueci que são dois processadores diferentes :(

Eu tenho um antigo Raspberry Pi modelo B (CPU armv6l) e adoraria executar alguns projetos dotnet core nele

Eu tenho muitos mini servidores baseados em CPU ARMv6 com Linux e Mono. Gostaria de trocá-los para .NET Core.

Também votaria no suporte ao armv6! +1

+1 para suporte armv6!

+1 seria bom ter

SIM!

Por favor!

Seria realmente ótimo!

Apenas curioso, existe uma razão técnica pela qual, por exemplo, o tempo de execução Go pode compilar para muitas arquiteturas usando o mesmo compilador, mas para o CoreCLR parece um processo muito mais longo adicionar suporte ao arco? https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63

@mms- sim, há uma razão técnica. Go é pré-compilado. Ele tem dois compiladores - gc que suporta apenas x86 (32 e 64 bits) e arm e gccgo que GCC como seu backend. Portanto, quaisquer que sejam as arquiteturas suportadas pelo GCC, elas as obtêm gratuitamente.
CoreCLR usa JIT, então estamos por conta própria para adicionar suporte para novas arquiteturas.

Faz todo o sentido. Seria interessante se o .Net Native pudesse ser expandido para permitir esse mesmo caminho para o .Net Core nessas outras arquiteturas onde o JIT ainda não existe.

Adicionando meu voto para ARMv6

Nós precisamos disso!

O ARMv6 tem muito apelo além do Raspberry Pi Zero. O Raspberry Pi Compute Module 1, por exemplo, executa o ARMv6 e torna muito mais seguro confiar no dotnet. Atualmente, o tempo de execução Mono deve ser usado, o que é bom, mas o suporte adequado a dotnet é algo que eu realmente gostaria.

@richlander

O suporte ARMv6 seria incrível.

Alguém pode explicar por que o Core precisa do JIT e, portanto, não pode ser executado no Armv6, mas o Mono pode? Certamente o Mono tem JIT, pois só precisa de código IL para ser executado - isso precisa ser JIT para a CPU local?

Alguém pode explicar por que o Core precisa do JIT e, portanto, não pode ser executado no Armv6, mas o Mono pode?

Mono tem um JIT diferente que suporta Armv6. O CoreCLR JIT não o suporta. ARM tem dois conjuntos de instruções - ARM e THUMB. ARM v6 tem THUMB, ARM v7 tem THUMB2.
O Mono JIT compila tudo em um conjunto de instruções ARM, portanto, funciona tanto no Armv6 quanto no v7, mas isso resulta em um espaço de memória aproximadamente 30% maior do código.
As diferenças entre Armv7 THUMB2 e Armv6 THUMB são bastante grandes e adicionar suporte para Armv6 exigirá muitas mudanças no CoreCLR JIT.

O .NET Core 3.0 foi lançado, o 3.1 está chegando, o 5.0 está planejado e é anunciado como uma plataforma unificada .
Blazor está usando Mono, o JIT não pode ser escolhido ao criar um novo projeto (selecionando o destino), se ARMv7 for selecionado, então CoreCLR deve ser usado se ARMv6, então JIT semelhante a Mono.

O Raspberry Pi 4 custa pelo menos US$ 35, o Pi Zero custa US$ 5, o Pi Zero W custa US$ 10. Então, pelo preço de um único Pi 4, você recebe 7 Pi Zeros!

E como muitos outros escreveram antes, não se trata apenas do Raspberry Pi Zero, todos os dispositivos ARMv6 podem executar aplicativos .NET Core.

2,5 anos depois ainda estamos esperando 🙂

+1

Existe um PR chamado suporte armv6 no projeto de tempo de execução: https://github.com/dotnet/runtime/pull/657

Por favor, adicione este suporte

Aguardo esse suporte também...

O suporte Armv6 para net core seria incrível...

Alguma palavra sobre o suporte armv6? Eu tenho dois pi zeros apenas esperando por um propósito ..

Obrigado

Por favor, adicione suporte para armv6

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

Temos o prazer de compartilhar que, daqui para frente, há uma versão do sistema operacional para Windows para IoT, Windows 10 IoT Enterprise, que pode atender a essas necessidades.

Posso estar interpretando isso errado, mas me preocupa que não haverá mais IoT Core para RPi, a menos que seja ARM64.

@miloush Eu não acho que esse problema tenha algo com o Windows IoT. O tópico aqui é adicionar suporte dotnet ao processador armv6 para que possamos executar o dotnet no Raspberry Pi Zero.

@realivanjx realmente meu mal

Da leitura acima, parece que o suporte ARM6 é improvável devido ao trabalho necessário para o conjunto de instruções do polegar. Alguém mais tem experiência executando dotnet core em outro hardware de baixo custo como Orange Pi Zero?

O PR #657 para adicionar ARMv6 foi fechado...

Viemos aqui por causa de um projeto .NET Core que precisamos rodar em um RPi Zeros na escola, pois temos cerca de 25x RPi Zeros comprados para este projeto. Não temos nem vamos comprar 25 novos RPi 3s porque o .NET Core não suporta ARMv6.

Acho que vou reescrever o projeto em Golang...

@ eduncan911 Tente seguir a rota mono. Aqui estão alguns detalhes.

O Net6 deve suportar várias arquiteturas de CPU via tempo de execução mono. pode ser.

Estou executando mais de mil dispositivos cpu ARMv6 via mono. 3 anos atrás nós introduzimos o hardware ARMv7, ainda em mono, mas agora estamos refatorando e migrando para Net core/net padrão, então apenas pequenos executáveis ​​serão diferentes e as bibliotecas são reutilizadas entre mono e net core.

Mesmo aqui. Eu corro os placares no campo de críquete do Senhor do pi 1
e Pi B+ usando Mono. O kit mais recente é executado no Pi 3 usando o Net Core. Mesmo
arquivos de origem, com um objeto principal que faz o trabalho. No quadro
e aplicativos principais, ele apenas cria o objeto de serviço e carrega o aplicativo
config nele.

Bryan Crotaz
Curva Prata E

Infelizmente o mono está cheio de bugs. Bugs que ninguém provavelmente vai consertar. A maioria deles relacionados à rede. Por exemplo, em algumas redes, quando o dns está disponível, mas o tráfego normal tem um problema - os fluxos https/ssl têm um vazamento de memória que pode consumir toda a memória. Ou o mono não conseguiu se comunicar em alguma rede sem jogar com o tamanho da MTU. Mas python ou NET Core não tem problemas de comunicação.

Surpreendentemente, o mono às vezes é mais rápido que o net core, pelo menos no ARMv7. Nem sempre, mas eu esperava que o net core vencesse a corrida de desempenho por uma margem enorme.

Acho difícil acreditar que o Mono esteja cheio de bugs, mas pode depender da aplicação. O Blazor WASM é implementado no Mono e se houvesse problemas relacionados à rede, isso seria um grande problema.

Mono: de Xamarin para WebAssembly, Blazor e .NET 5

cc @ marek-safar

Eu corro mono em vários milhares de máquinas e muitas configurações de rede. Esses bugs não ocorrem em todas as configurações de máquina e rede. Eles têm a mesma imagem linux.

O problema do tamanho da MTU - 0,3% das instalações - nestas redes é 100% reprodutível. Eu não tenho nenhuma idéia do porquê. Mas o ssh funciona nessas redes e o fato de eu ter que alterar o tamanho do mtu foi descoberto apenas por acidente.

Vazamento de memória SSL Stream - 2% das instalações. Foi muito difícil de reproduzir, no final conseguimos reproduzi-lo com roteador 4G com dados consumidos, então apenas o dns está funcionando, outro pedido não funciona. Mas não conseguimos simulá-lo com o simulador de erro tcp na rede lan normal. Usamos roteador 4G e cartão SIM específico para simular esse vazamento. Geralmente acontece na instalação com 4G ou outras redes sem fio. Parece que, se no caso de estabelecer uma conexão TCP e HTTPS, o handshake TCP não for concluído, isso cria um vazamento.

De vez em quando encontramos um bug, às vezes é corrigido em pouco tempo, às vezes nós os contornamos e uma vez que consertei em mono e o pull request foi aceito (também relacionado à rede) :) Mas para ser justo, esta semana eu encontrou (e relatou) um bug no NET5 RC1. Para mim, o mono é um excelente software (trabalho com ele há 9 anos), mas apresenta algumas falhas no código de rede.

É justo, mas caracterizar o Mono como cheio de bugs é um pouco injusto. A combinação de roteador 4G/cartão SIM certamente parece um caso de ponta, eu encorajo você a criar um problema no repositório Mono e fornecer o máximo de informações possível. Mesmo que não seja resolvido, pelo menos outros com o mesmo problema podem descobrir o bug. Obrigado por suas contribuições anteriores aos repositórios Mono/NET5.

Ok, desculpe, é injusto.

Mas acabamos de perder várias centenas de horas-homem descobrindo por que algumas instalações apresentam esses problemas. Mono é especialmente útil para aplicativos de curta duração - como dispositivos móveis. Temos algumas instalações onde temos mais de um ano de atividade, mas às vezes é problemático.

@michaldobrodenka aliás seu depoimento é muito interessante!

O suporte ARMv6 será incluído no .NET 6.0?

Richard Lander mencionou algo sobre isso nos comentários do anúncio do .NET 5 Preview 4
https://devblogs.microsoft.com/dotnet/announcing-net-5-preview-4-and-our-journey-to-one-net/#comment -5958

Meu pensamento com isso é que usaríamos Mono para Armv6 como parte do .NET 5.0. Nós quase todos os projetos relacionados ao Mono/Xamarin para 6.0. Espero que possamos financiar uma construção Mono Armv6 em 6.0.