zConf — Zephyr MCC-like 0.10.3

Compatibilidade com a mensagem de inicialização do pyOCD (0.10.3)

Corrige o falso timeout do Cortex-Debug 1.12.1 com versões recentes do pyOCD. O pyOCD 0.46.1 anuncia GDB server listening on port, enquanto o adaptador esperava GDB server started at/on port. O zConf agora grava overrideGDBServerStartedRegex nas configurações pyOCD para reconhecer os formatos novo e antigo. Mensagens de descoberta e do servidor STDIO não são tratadas como prontidão do GDB. Configurações J-Link não recebem a regra.

Instale zconf-0.10.3.vsix, recarregue a janela e selecione a configuração zConf — nome_do_projeto em Executar e Depurar. O padrão é aplicado tanto ao F5 quanto ao botão Depurar. O teste de regressão usa a linha de log do PL10 e foi conferido com os fontes locais dos dois componentes instalados.

Configuração do Cortex-Debug e F5 (0.10.2)

A extensão grava uma configuração zConf — nome_do_projeto em .vscode/launch.json da pasta aberta no VS Code. O botão Depurar inicia essa mesma configuração pelo nome, com servertype validado (pyocd ou jlink), MCU, ELF e ferramentas do ambiente selecionado. As demais configurações de debug são preservadas. O registro é atualizado ao abrir um projeto preparado e quando zconf.json ou os ajustes do zConf mudam.

Instale zconf-0.10.3.vsix, recarregue a janela e selecione zConf — teste_PL10_zephyr em Executar e Depurar. Use F5 para iniciar/continuar, F10/F11 para passos e F9 para breakpoints. O botão Depurar do zConf gera e compila antes de iniciar; F5 usa o último ELF compilado.

A saída zConf Debug registra o servidor, dispositivo e ELF usados. A mensagem “Invalid servertype parameters” ocorre quando o Cortex-Debug recebe esse campo ausente ou fora da lista aceita. O projeto PL10 observado não tinha launch.json; o gerador anterior já produzia pyocd corretamente. O validador real do Cortex-Debug 1.12.1 aceitou a configuração completa. A origem exata da mensagem pelo botão anterior não foi reproduzida em uma sessão real; o novo caminho salvo e o log permitem conferir o que é iniciado.

Visibilidade dos periféricos (0.10.1)

A aba Periféricos, o botão Todos os periféricos do MCU e a lista Available Components agora consultam o inventário do dispositivo. Antes, o inventário completo estava em uma tela antiga que a navegação não abria. Os blocos físicos aparecem mesmo quando não possuem um nó no SDK instalado. Selecione um item para consultar seus detalhes ou configurar o nó disponível. A busca aceita nome do bloco, função, rótulo do SDK e pino.

No PIC32CM6408PL10048, o inventário ATDF contém 33 blocos, incluindo ADC0, AC, CCL e EVSYS. Sem nó no SDK indica que o bloco existe no chip mas precisa de integração de driver/devicetree para ser configurado no Zephyr. A extensão não cria suporte de driver apenas por exibir o bloco. Em dispositivos sem ATDF, a cobertura continua limitada às fontes disponíveis e os avisos de inventário parcial são preservados.

Instale zconf-0.10.3.vsix no perfil do VS Code usado para o projeto e execute Developer: Reload Window. O cabeçalho do configurador deve mostrar 0.10.1. A árvore lateral do zConf também possui Todos os periféricos do MCU; Project peripherals reúne apenas os recursos configurados no projeto.

Debug pelos controles do VS Code (0.10.0)

Instale zconf-0.10.3.vsix e recarregue a janela do VS Code. Cortex-Debug (marus25.cortex-debug) agora é uma dependência declarada do zConf e é instalado pelo VS Code junto com a extensão, com acesso ao Marketplace. Se estiver offline, instale/habilite Cortex-Debug no mesmo perfil antes de usar o novo debug.

O botão Depurar e o comando zConf: Depurar projeto continuam preparando o dispositivo, gerando e compilando a aplicação. Agora iniciam uma sessão cortex-debug pela API do VS Code e abrem Executar e Depurar. A execução para em main; o usuário pode colocar breakpoints no editor e usar a barra de debug:

• F9: alternar breakpoint na linha selecionada.
• F5: continuar a sessão em andamento.
• F10: executar a próxima linha sem entrar na função.
• F11: entrar na função.
• Shift+F11: sair da função.
• Shift+F5: encerrar a sessão.

Variáveis, inspeções (Watch), pilha de chamadas e o console de debug passam a ser os recursos normais do VS Code/Cortex-Debug. Para iniciar e recompilar, use o botão Depurar do zConf. Não é necessário editar launch.json.

A integração gráfica aceita pyOCD e J-Link, usando MCU, interface, frequência, número de série de debug e caminho opcional do J-Link salvos no projeto. O ELF e as ferramentas GDB/objdump/nm são obtidos do SDK do projeto. O pyOCD vem do mesmo ambiente Python usado para preparar os packs. MPLAB IPE continua sendo somente uma opção de gravação. Outros runners de terminal não são convertidos automaticamente para Cortex-Debug.

Cortex-Debug gerencia os servidores e escolhe portas livres para a sessão; o campo de porta GDB existente permanece destinado a West/terminal. O ambiente fica bloqueado contra atualização enquanto a sessão gráfica estiver ativa. O botão Parar encerra a sessão e libera o ambiente. Para facilitar passos por linha e inspeção de variáveis, selecione -Og em Otimização do compilador.

Os testes cobrem configuração e ciclo de vida da sessão. O GDB do SDK reconheceu as linhas de main no ELF PL10 existente; não foi executada sessão em placa durante esta entrega. Referências: Cortex-Debug e API de depuração do VS Code.

Inventário de periféricos e otimização (0.9.0)

Instale zconf-0.9.0.vsix e recarregue a janela do VS Code. O cache de modelos antigos é invalidado automaticamente. O publisher continua RodrigoBritto.

Todos os periféricos do MCU, na lista de componentes e na aba Periféricos, abre um inventário pesquisável. Ele reúne todas as instâncias descritas no ATDF ou SVD exato do dispositivo, ou as declarações do header específico quando não há esses arquivos. Também apresenta todos os recursos descritos no devicetree do SDK, incluindo nós sem rótulo que antes não apareciam na lista.

Cada recurso mostra nome, função, origem, endereço e, quando descritos no pacote, sinais/pinos e quantidade de registradores. Configurar abre o editor existente para os nós configuráveis do SDK. Recursos de sistema e recursos inexistentes no die selecionado não recebem um controle de ativação indevido.

Isso torna visíveis, por exemplo, ADC, AC, CCL e EVSYS do PL10, mesmo quando o SDK instalado ainda não descreve seus nós. Sem nó no SDK significa que o bloco existe no chip, mas precisa de integração de devicetree/driver para ser usado pelo Zephyr. Esta versão não cria drivers de hardware ausentes no SDK. Quando não há metadados completos do chip, a interface informa a cobertura parcial em vez de usar os periféricos de outro modelo. Use Recarregar inventário após alterar o SDK, ou Verificar atualização do SDK para consultar novas revisões.

O índice de capacidades passa a examinar todas as pastas de drivers do Zephyr e dos módulos instalados, em vez de somente algumas classes. A classificação inclui eventos, lógica configurável, touch/PTC, CRC, I3C, PECI, PS/2, backup, reset e controle de alimentação, além das categorias anteriores.

Em Software ou Compilar / Depurar, a seção Otimização do compilador oferece padrão do SDK, -O0, -Og, -O1, -O2, -O3, -Os e -Oz, conforme o SDK. A escolha fica em zconf.json e é aplicada ao gerar/compilar. As opções nativas usam a escolha Kconfig do Zephyr. -O1 e -O3 usam a base de velocidade do Zephyr e um override C/C++ no alvo de interface, abrangendo aplicação, kernel e módulos; exigem GCC ou Clang. Trocar para uma opção nativa remove o override. O modo padrão preserva a configuração existente. Uma seleção manual conflitante fora do bloco gerado de prj.conf é apontada para revisão, sem apagar texto do usuário.

Referências: opções oficiais do compilador Zephyr e os arquivos ATDF/headers locais mostrados nos detalhes de cada recurso. Consulte VALIDACAO-0.9.0.txt para cobertura e limites de validação.

Gravação, debug e atualização do SDK (0.8.0)

Instale zconf-0.8.0.vsix e recarregue a janela do VS Code. O publisher é RodrigoBritto. Use zConf: Configurar gravação e debug para abrir os controles.

• Escolha separadamente a ferramenta de gravação e a de debug: padrão da placa, pyOCD/CMSIS-DAP, SEGGER J-Link ou MPLAB IPE (somente gravação).
• Configure SWD/JTAG, frequência em Hz, número de série do gravador, número de série do depurador, porta GDB e dispositivo. Para pyOCD, escolha também o modo de conexão/reset. MPLAB IPE seleciona o protocolo pelo dispositivo.
• A criação e a geração do projeto leem as opções da placa e o MCU do catálogo do SDK. As escolhas ficam em zconf.json; o módulo zconf_programmer registra as opções no CMake sem editar os arquivos das placas fornecidos pelo SDK.
• O suporte não fica limitado ao PL10: a mesma preparação verifica o alvo exato para cada MCU selecionado. Quando pyOCD precisa de um Device Family Pack, o zConf atualiza o índice, instala o pacote e confirma novamente o alvo. Se o gerenciador terminar sem disponibilizá-lo, tenta o pacote oficial Microchip/Atmel via HTTPS. O download pode demorar. Se o alvo continuar indisponível, a operação é interrompida com orientação para escolher uma ferramenta compatível; não se usa outro MCU.
• Preparar suporte do dispositivo permite repetir a preparação. Gravar firmware e Depurar geram e compilam antes de iniciar a ferramenta. O botão Depurar abre uma tarefa com GDB interativo no terminal do VS Code, usando o servidor pyOCD/J-Link configurado ou o runner padrão da placa. Não é uma sessão de breakpoints gráficos da extensão Cortex-Debug. Encerre a tarefa ao terminar.
• Os programas SEGGER J-Link e MPLAB IPE devem estar instalados e compatíveis com o dispositivo e o hardware conectado. Há campos para seus executáveis. PICkit, ICD, ICE e gravadores integrados dependem do suporte da ferramenta escolhida; não se presume que todos os gravadores atendam a todos os MCUs.

Para o projeto PL10 existente, selecione pic32cm_pl10_cnano, abra Configurar gravação e debug e use pyOCD, alvo pic32cm6408pl10048, SWD e 100000 Hz. Clique em Preparar suporte do dispositivo e depois em Gravar firmware ou Depurar. A preparação usa o mesmo Python do ambiente usado pelo West.

zConf: Verificar atualizações do Zephyr4Microchip consulta a branch do manifesto do ambiente gerenciado. A verificação automática ocorre na ativação, no máximo uma vez a cada 24 horas, e pode ser desativada em zconf.checkSdkUpdates. Nada é atualizado sem clicar em Atualizar agora. A atualização sincroniza o manifesto, módulos, dependências e compiladores, com progresso e cancelamento; pode baixar vários GB e demorar. Alterações locais ou commits próprios dos módulos bloqueiam a operação. Tags/commits fixados não são trocados automaticamente. Uma falha deixa registro para retomada pelo mesmo comando, com nova confirmação. Aplicações do usuário são preservadas. Recarregue o modelo após atualizar.

Validação desta versão: testes de configuração, geração, controles e confirmação de atualização; configuração CMake real do PL10; download oficial e reconhecimento do alvo pelo pyOCD. Não foi feita gravação física nem validada uma sessão em placa. Consulte o relatório VALIDACAO-0.8.0.txt entregue com o VSIX para os limites dos testes.

Referências: suporte de alvos pyOCD, gravação/debug do PL10 no Zephyr e manifesto Zephyr4Microchip.

Correção 0.7.1 — download do Wget no Windows

O Wget passa a ser baixado do ZIP oficial 1.25.0, com SHA-256 fixado e validado antes da extração e execução. O pacote WinGet 1.21.4 usado anteriormente retornou erro de hash no ambiente do usuário. A validação de integridade continua obrigatória. O ZIP verificado é guardado em .zconf-tools dentro do ambiente Zephyr e reutilizado nas tentativas seguintes. O PATH global do computador não é alterado. As outras ferramentas continuam sendo obtidas pelo WinGet.

Instale zconf-0.7.1.vsix, recarregue o VS Code e execute zConf: Instalar / retomar Zephyr4Microchip. O ambiente parcial da versão 0.7.0 é preservado. A notificação de erro agora prioriza a última mensagem do processo; o registro mantém a saída completa.

Origem: Wget para Windows. SHA-256 de referência: manifesto Scoop.

Instalação automática do Zephyr4Microchip (0.7.0)

Instale zconf-0.10.3.vsix usando Extensions > Install from VSIX... no VS Code. Na primeira ativação da extensão em uma janela confiável, a preparação começa automaticamente. Se o VS Code solicitar, use Developer: Reload Window. O VSIX já contém a extensão zConf; não é necessário instalar outro pacote zConf.

O download pode ter vários GB e demorar muitos minutos ou até horas, dependendo da conexão e do computador. Mantenha o VS Code aberto. A notificação mostra a etapa atual; a barra de status e o canal zConf — Instalação Zephyr4Microchip permitem acompanhar os comandos e as mensagens dos downloads. O progresso é por etapas, não uma previsão de tempo ou porcentagem exata dos bytes totais.

No Windows 10/11, o instalador:

1. Verifica e instala, quando necessário, Python 3.12, Git, CMake, Ninja, gperf, dtc e 7-Zip por meio do WinGet. O Wget é obtido do ZIP oficial verificado, conforme a correção 0.7.1 acima. O Windows pode pedir autorização para os instaladores das ferramentas. Se faltar WinGet, atualize o App Installer pela Microsoft Store e retome a instalação.
2. Cria um ambiente Python .venv, instala West e inicializa o manifesto oficial https://github.com/Zephyr4Microchip/microchip-zsdk, por padrão na branch main.
3. Executa west update para baixar Zephyr, HAL Microchip e os demais módulos definidos pelo manifesto. Instala os requisitos Python de todos os módulos.
4. Executa west zephyr-export e west sdk install, usando a versão de compiladores exigida pelo arquivo zephyr/SDK_VERSION. São instaladas as toolchains oferecidas pelo SDK para o sistema do computador.
5. Verifica West, compilador ARM, dependências Python, catálogo de dispositivos e leitura do modelo da placa padrão pic32ck_sg01_cult. A instalação só é marcada como concluída depois dessas verificações.
6. Configura o ambiente do backend, compilação e tarefas do zConf. Ao terminar, use Abrir ambiente e depois zConf: Novo projeto.

O destino padrão é mchp_zephyrproject na pasta do usuário, separado da extensão. Prefira caminho curto, sem espaços e fora de Dropbox/OneDrive para o SDK. Para alterar o destino, configure zconf.installDirectory com um caminho absoluto para uma pasta vazia e execute zConf: Instalar / retomar Zephyr4Microchip. Pastas existentes com arquivos não são sobrescritas. Um workspace já detectado é reutilizado, sem executar instalação automática sobre ele; o campo zconf.workspaceRoot permite selecionar esse ambiente.

Cancelamento, falhas e retomada

Use Cancelar na notificação. As etapas concluídas e os arquivos baixados permanecem na pasta; para continuar, execute zConf: Instalar / retomar Zephyr4Microchip. Etapas interrompidas são executadas novamente. Ferramentas externas podem precisar baixar novamente um arquivo incompleto; não há garantia de retomada por byte. Falhas e cancelamentos não reiniciam downloads sozinhos ao reabrir o VS Code. Duas janelas não instalam simultaneamente na mesma pasta.

Use zConf: Mostrar registro da instalação para ver detalhes. O canal informa também o caminho do arquivo de registro persistente da sessão. Se o Windows acabou de instalar ferramentas mas ainda não as encontra, reinicie o VS Code e retome. Problemas de rede, proxy, espaço livre ou permissões são reportados no registro; nenhuma dessas situações é tratada como instalação concluída.

Configurações adicionais: zconf.autoInstall desativa a preparação automática; zconf.sdkRevision permite uma branch/tag/commit para instalações novas. Uma retomada preserva o manifesto já baixado; para trocar a revisão, use outra pasta. As configurações de instalação são do computador, não do projeto aberto.

Escopo e validação

A instalação automática de ferramentas do sistema é implementada para Windows com WinGet. Em Linux/macOS, instale antes as dependências do sistema indicadas no guia do Zephyr; as etapas de ambiente virtual, repositórios e SDK são comuns. Em uma sessão remota/WSL, a instalação ocorre no host onde a extensão é executada.

Gravação e depuração de uma placa física continuam dependendo do probe, drivers USB e ferramentas do runner correspondente (por exemplo MPLAB IPE ou J-Link). Esses instaladores e licenças específicos da placa não são instalados pelo fluxo genérico. Os patches históricos correcoes-sdk/ da entrega 0.6.2 não são aplicados automaticamente à branch main, que pode conter revisões diferentes.

O novo instalador tem testes automatizados de fluxo com comandos simulados, integração com a API simulada do VS Code e execução real de subprocessos para validar argumentos, falhas, cancelamento e timeout. Os testes não equivalem a uma instalação completa em um Windows limpo nem a testes em placas físicas.

Referências: guia Microchip zSDK e dependências do Zephyr.

Histórico anterior

Esta versão aproxima o configurador do fluxo da extensão CMSIS configurator MCC-LIKE, mantendo o projeto Zephyr como base.

Atualização 0.6.2 — Correções encontradas pela matriz de MCUs

O modelo confere instâncias SERCOM/SPI no cabeçalho exato do dispositivo e reconhece o pacote SAM4SA. A seleção de periféricos verifica os acessos seguro e não seguro do mesmo controlador, permitindo configurar cada acesso separadamente. SERCOMs com a mesma interrupção física habilitam automaticamente o suporte de interrupções compartilhadas do Zephyr quando ativos em conjunto. O cache de modelos usa schema 5 e valida os metadados de interrupção.

Ao habilitar um periférico, a geração escreve os valores padrão obrigatórios do binding e preserva as escolhas da placa e do usuário. Os grupos de pinos gerados incluem o cabeçalho de pinmux identificado no SDK, inclusive em projetos existentes.

Para reproduzir os testes, use o SDK com os patches entregues junto ao relatório e as bibliotecas QTouch correspondentes ao manifesto do HAL. As correções do SDK abrangem registradores, interrupções, PWM, SPI, flash, RTC e o DAC de dois canais do SAML21. Os testes verificam criação, geração repetível, compilação, alvo e devicetree do firmware. A validação elétrica depende do hardware.

Atualização 0.6.1 — Validação entre famílias

O gerador de placa própria usa os clocks internos e, nos dispositivos com regiões de boot e programa separadas, seleciona a região de programa correspondente ao modelo. O devicetree gerado elimina propriedades incompatíveis ao trocar de modo, seleciona o dispositivo de entropia quando necessário e respeita as conexões herdadas da placa. Os drivers MCC só usam APIs encontradas no SDK local. Esta versão atualiza o cache de dispositivos para schema 4.

Atualização 0.6.0 — Fluxo MCC, prioridades 1 e 2

• Diagnósticos centraliza validações de propriedades, pinos herdados, clocks da CPU/PLL, dependências de middleware, callbacks e DMA. Cada problema abre sua configuração. Erros impedem gerar e compilar; avisos mantêm informações sobre limitações dos cálculos.
• Dependências aparecem no grafo. Habilitar TCP/IP/USB/FS tenta configurar os controladores declarados no SDK. Seletores permitem escolher rede, USB, partição ou SD; Resolver dependências habilita recursos existentes. Partições e conexões desconhecidas não são inventadas. LittleFS em flash e FATFS em SD ganham ZCONF_FS_MountConfigured quando o armazenamento foi selecionado, sem formatação automática.
• Configuração guiada de baud rate UART, velocidade I2C, frequência/duty PWM e canal/resolução/tempo de aquisição/taxa do exemplo ADC. Para UART SERCOM G1 com clock resolvido, mostra baud obtido e erro do divisor conforme o driver do SDK. A taxa ADC é de disparo por software; não equivale a uma garantia de amostragem por hardware. PWM informa períodos em ns, sujeitos à resolução do timer.
• Exemplos vinculados ao projeto: botão/IRQ com tratamento em thread, ADC periódico, UART RX/async e produtor/semáforo/consumidor. Criar código preserva arquivos existentes. Usar como aplicação troca somente uma entrada reconhecida de main em CMake, com backup, sem sobrescrever main.c ou callbacks do usuário.
• Encapsulamento lê a numeração física do ATDF exato do MCU. QFP tem vista superior; outros formatos têm tabela de posições, sem inventar geometria. Pinos de alimentação ficam indisponíveis; SWD e pinos usados são destacados. Arduino, mikroBUS, LEDs e botões da PIC32CK GC01/SG01 Curiosity Ultra vêm das tabelas 2-3, 2-10 e 2-11 do DS70005529C. Outras placas mostram apenas dados disponíveis, sem sugerir conectores não verificados.
• Árvore gráfica de clocks apresenta fontes, PLL, geradores e consumidores com frequências recalculadas e acesso ao editor. Limite da CPU vem do ATDF. Limites de PLL PIC32CK seguem o binding local; topologias desconhecidas continuam sem frequência calculada.
• Drivers: UART com RX por interrupção e callback preservada; UART DMA, SPI/I2C assíncronos e ADC async quando o driver e o modelo oferecem suporte. DMA usa triggers dos headers do MCU e canais livres, com verificação de conflitos. Há timeout de leitura UART e retornos de erro nativos. SPI/I2C seguem os tempos e semântica do driver Zephyr, sem criar promessa de cancelamento que ele não oferece.
• Build / Debug verifica ambiente Python/west, SDK, aplicação, firmware e runners. Detecta dispositivos USB conhecidos sem declarar a conexão de depuração validada. Gerar/compilar usa o projeto selecionado, com saída no canal zConf. Gravar e depurar recompilam antes de agir. Debug utiliza o runner configurado pelo Zephyr e GDB no terminal integrado; não instala ferramentas nem troca a configuração do probe. Comandos: zConf: Project Diagnostics e zConf: Build and Start Debugger.

Suporte verificado por compilação na Curiosity Ultra PIC32CK GC01 e em placa própria SAMD51. O DTS PIC32CK deste SDK não declara DMA; por isso UART DMA não é oferecida nessa placa, enquanto RX por interrupção está disponível. Gravação e depuração em hardware exigem probe e ferramentas do runner e não são executadas durante os testes de geração.

Validação desta versão

Testes de modelo, geração, diagnósticos, interface/eventos e integração do painel passaram, usando o modelo completo da PIC32CK GC01 e um modelo de placa própria SAMD51. As verificações da interface usam DOM simulado; não substituem inspeção visual no VS Code.

Compilações Zephyr concluídas: GC01 com RTOS, TCP/IP, USB, LittleFS, UART por interrupção e APIs assíncronas SPI/I2C/ADC; quatro exemplos configurados (botão, ADC, UART, tarefas); variante FATFS em SD; SAMD51 com UART assíncrono e DMA. A bancada nativa GPIO passou registro, despacho, rollback e repetição de inicialização. Não foi executada gravação nem teste funcional em hardware.

Atualização 0.5.0 — Eval board e devicetree da placa própria

• O assistente consulta novamente o catálogo do SDK ao criar o projeto, associa as eval boards ao part number exato e seleciona a primeira opção compatível. O usuário pode escolher outra placa compatível ou placa própria.
• Eval board: usa o DTS oficial do SDK como configuração base. O configurador não modifica os arquivos do SDK; grava mudanças em app.overlay e omite propriedades tipadas que já coincidem com a base. Alterar um sinal preserva os demais sinais do pinctrl herdado.
• LEDs e botões definidos no DTS aparecem no Pin Manager. Reutilizar o pino em uma configuração explícita desativa o consumidor original no overlay; remover a configuração restaura a base.
• Placa própria: gera boards/zconf/<alvo>/board.yml, Kconfig, defconfig, zconf-base.dtsi e <alvo>.dts, com BOARD_ROOT no CMake. As configurações são gravadas no DTS, sem criar app.overlay. Pinos e memória vêm do MCU selecionado, sem copiar ligações de uma eval board.
• PIC32CK e SAM D5x/E5x usam inicialmente a fonte interna de 48 MHz. Outras famílias exigem configuração dos clocks. A frequência da CPU também é editável na aba Clocks. Revise memória e conexões para o seu hardware; a geração não valida uma placa física.
• A criação de placa própria exige DTSI específico disponível no SDK. A interface informa quando esse suporte falta. A busca é local ao SDK instalado; não é um inventário mundial de placas.
• A visão geral apresenta os caminhos do DTS e referências oficiais encontradas na documentação da placa. Não há interpretação automática de PDFs arbitrários. Para PIC32CK GC01 Curiosity Ultra original, LEDs PD20/PB25 e botões PB26/PD2 foram conferidos no manual DS70005529C, tabela 2-11, e no DTS local.
• Referência: https://ww1.microchip.com/downloads/aemDocuments/documents/MCU32/ProductDocuments/UserGuides/PIC32CK-SG01-GC01-Curiosity-Ultra-User-Guide-DS70005529.pdf

Atualização 0.4.1 — Callbacks de interrupção GPIO/EIC

No Pin Manager, selecione uma função EIC_EXTINT ou configure o disparo no campo de interrupção do GPIO: subida, descida, ambas as bordas, nível alto ou baixo. O pino é configurado como entrada; disparos usam níveis físicos, independentemente de Active low. Esta integração utiliza o driver GPIO Microchip Port G1 + EIC G1 presente no SDK. NMI não é tratado como uma interrupção GPIO comum.

Ao gerar, o código configura os pinos, registra as callbacks com gpio_init_callback() e gpio_add_callback(), e só então habilita as interrupções. Com MCC, isso acontece em SYS_Initialize(), após inicializar os drivers e antes de iniciar as tarefas. Sem MCC, a aplicação chama ZCONF_PINS_Initialize() e verifica seu retorno. A inicialização é idempotente; falhas removem os registros já adicionados e permitem nova tentativa.

O tratamento do usuário fica em src/zconf_callbacks/pa0.c (exemplo PA0), na função ZCONF_PA0_InterruptCallback(). O nome físico é estável para preservar o código ao renomear o pino; pin_manager.h também oferece o alias <NOME>_InterruptCallback. O botão Editar callback da interrupção abre esse arquivo após gerar. Regenerar não sobrescreve o tratamento. Desabilitar a interrupção remove o arquivo da compilação, preservando-o no disco.

A callback executa no contexto da interrupção: use operações sem bloqueio, como k_sem_give() ou envio de trabalho para uma tarefa. Em disparo por nível, o tratamento deve resolver a fonte externa para evitar interrupções contínuas. Pinos sem rota compatível e atribuições duplicadas à mesma linha EXTINT são recusados. Seleções EIC_EXTINT antigas são convertidas para a configuração de callback na próxima carga/geração, usando borda de subida inicialmente.

Atualização 0.4.0 — RTOS e Middlewares

• RTOS: tarefas preemptivas, tamanho de pilha, prioridade, período do laço, início automático; semáforos com contagem inicial/limite e mutexes. Configura também pilha principal, fila de trabalho, heap, níveis de prioridade e fatiamento de tempo.
• Generate cria zconf_generated/rtos.h/.c e arquivos editáveis em src/zconf_tasks/. Estes arquivos são preservados, inclusive ao renomear uma tarefa. Excluir a tarefa a remove da compilação, preservando seu arquivo. IDs não são reutilizados.
• As tarefas iniciam suspensas. Com MCC ativo, SYS_Initialize() chama ZCONF_RTOS_Start() depois dos drivers; sem MCC, chame essa função na aplicação. Tarefas sem início automático podem ser iniciadas com k_thread_start(zconf_task_NOME).
• Middlewares: TCP/IP (IPv4/IPv6, TCP/UDP, DHCP ou IPv4 estático, DNS), USB CDC ACM na nova pilha Zephyr (controlador, VID/PID e descritores), LittleFS/FATFS (armazenamento, limite de arquivos e somente leitura).
• TCP/IP usa a interface de rede da placa. USB CDC ACM inicia no boot e preserva a console existente. A configuração FS gera ZCONF_FS_Mount(): a aplicação fornece o armazenamento e o ponto de montagem; a extensão não cria partições nem formata a memória.
• As opções entram no prj.conf, overlay e CMake. Overrides incompatíveis na aba Software são apontados antes da geração. As novas abas estão disponíveis em Português e English.

Atualização 0.3.2 — Marca e idiomas

Logo Microchip centralizado no topo e seletor Português / English no canto superior direito. A preferência é salva entre sessões. A troca atualiza as abas, botões, campos e textos de orientação sem alterar as configurações do projeto. O padrão inicial é Português.

Identificadores, nomes de arquivos, código gerado e descrições técnicas vindas do SDK permanecem no original. O logo é empacotado localmente, reutilizando o mesmo recurso da extensão CMSIS-MCC-like instalada; não depende de rede.

Atualização 0.3.1 — GPIO no Pin Manager

• A função GPIO resolve a porta real (porta, portb etc.) e habilita seu controlador. GPIO não é tratado como um periférico chamado GPIO, nem é inserido em um grupo pinctrl fictício.
• Ao escolher GPIO, edite o nome C, direção (entrada ou saída com estado inicial), pull-up/pull-down e polaridade Active low. As escolhas ficam em zconf.json e os pinos podem ser buscados pelo nome personalizado.
• Com MCC Drivers habilitado, Generate cria pin_manager.h/.c, incluídos em definitions.h. SYS_Initialize(0) aplica direção, estado inicial e pull. Para um pino LED_STATUS, use LED_STATUS_Set(), LED_STATUS_Clear(), LED_STATUS_Toggle() e LED_STATUS_Get(). Os níveis são lógicos e respeitam Active low; as funções retornam erro negativo ou, para Get, 0/1.
• Nomes inválidos/repetidos e pinos já ocupados pelo pinctrl de um periférico ativo são recusados. Remova a atribuição anterior ou desabilite o periférico antes de usar esse pino como GPIO.
• Sem MCC Drivers, o overlay fornece as propriedades pa0-gpios, pa1-gpios etc. em zephyr,user; a aplicação precisa configurar os pinos pela API GPIO do Zephyr.

Atualização 0.3.0 — Novo projeto

Abra zConf: Novo projeto ou a aba Novo projeto. Informe o nome, busque o part number e selecione uma das placas compatíveis. O catálogo é extraído dos arquivos SoC/board do SDK local, incluindo Microchip e Atmel; não é uma lista de todos os produtos comercializados.

Com uma placa selecionada, cria apps/<nome> com src/main.c, CMake, prj.conf, app.overlay, zconf.json, README e drivers MCC-like. O wrapper ADC fica desmarcado até você configurar seus canais. Valida o modelo da placa antes de criar, ativa a nova aplicação e usa um diretório de build próprio. Pastas existentes são recusadas.

Placa própria: a partir da versão 0.5.0, cria a definição de placa dentro da aplicação e ativa o projeto, conforme descrito acima. Revise os clocks e as conexões antes de usar no seu hardware.

A aba funciona mesmo se o modelo da placa atual falhar. Os part numbers disponíveis e as placas são lidos novamente antes de criar o projeto.

Atualização 0.2.2

• A seção Calculated resolve a origem do clock ADC pelo phandle/subsystem do devicetree, sem depender do nome do nó.
• Se a placa não declara uma rota, a extensão propõe uma usando o padrão do binding e a gera explicitamente quando o ADC está habilitado. Fontes existentes e edições são preservadas.
• Seletor GCLK source no ADC; mudanças recalculam GCLK_ADC, CTL_CLK, ADC_CLK e TAD e entram no overlay.
• Para PIC32CK GC01 com gclk0 = 120 MHz, CTLCKDIV = 1 e ADCDIV = 1: CTL_CLK = 60 MHz, ADC_CLK = 30 MHz e TAD = 33,333 ns. São valores calculados da configuração, não medições em hardware.
• Fonte desligada ou desconhecida recebe uma explicação. Divisores inválidos não produzem resultados enganosos.
• O wake-up é mostrado como valor enviado ao driver (WKUPEXP), sem convertê-lo indevidamente para microssegundos.
• Modelo atualizado para schema 3; caches anteriores são reconstruídos automaticamente.

Atualização 0.2.1

• ADC: valores efetivos preenchidos em Clock and timing. A prioridade é edição do usuário, valor da placa, padrão do binding e preset da placa Microchip de referência.
• ADC G2: CTLCKDIV = 1, ADCDIV = 1, wake-up = 6 (campo WKUPEXP) quando faltam valores na placa. ADC G1: prescaler = 4 quando não existe valor da placa/binding. O número de canais vem exclusivamente do modelo do dispositivo.
• Os defaults entram no overlay e em zconf.json ao habilitar/configurar ou gerar; a prévia usa os mesmos valores sem alterar o projeto em disco.
• Botão Restore defaults para reaplicar os valores da placa/preset ao ADC selecionado.
• Versão no título, cabeçalho e barra de status. Comandos zConf: Open MCC-like 0.2.1 e zConf: Show Loaded Version; o segundo informa também o diretório efetivamente carregado.

Novidades

• Área de trabalho com recursos ativos e catálogo pesquisável à esquerda, grafo do projeto ao centro e propriedades à direita.
• Grafo selecionável com estado dos periféricos, indicação dos wrappers e conflitos de pinos.
• Aba MCC Drivers para ativar a geração, selecionar as instâncias e personalizar os prefixos C.
• Drivers para UART/USART, I²C, SPI, GPIO, ADC e PWM sobre as APIs nativas Zephyr.
• definitions.h, SYS_Initialize(NULL), delay_ms() e delay_us().
• Prévia dos arquivos e integração automática de mcc_generated ao CMake da aplicação.
• Validação de nomes, colisões de prefixos, opções Kconfig incompatíveis, propriedades obrigatórias e canais ADC. Conflitos de pinos impedem a gravação.
• Correção da propriedade #pwm-cells na troca para PWM, do cabeçalho de constantes ADC no overlay e da navegação das abas pela árvore do VS Code.

Uso

1. Abra zConf: Open Configurator no workspace Zephyr e selecione a placa e a aplicação.
2. Selecione um recurso no grafo ou no catálogo. Configure modo, pinos e propriedades no painel direito.
3. Na aba MCC Drivers, marque Generate MCC-like driver layer. Projetos antigos permanecem com a camada desativada até essa escolha.
4. Confira Preview generated code e clique em Generate.
5. Inclua definitions.h em seu código e verifique o retorno de SYS_Initialize(NULL) antes de usar os drivers.

#include "definitions.h"

int main(void)
{
    int rc = SYS_Initialize(NULL);
    if (rc < 0) return rc;
    // Exemplo: disponível quando sercom5 está em UART e selecionado.
    return SERCOM5_USART_Write("Hello Zephyr!\r\n", 15);
}

Contrato dos drivers

Tipo	Operações	Comportamento
UART	Initialize, IsReady, Write, WriteByte, ReadByte	TX bloqueante; RX retorna -EAGAIN sem dados
I²C	Initialize, IsReady, Write, Read, WriteRead	Síncrono, endereço de 7 bits
SPI	Initialize, IsReady, WriteRead	Recebe const struct spi_config * persistente, incluindo CS e modo
GPIO	Initialize, IsReady, PinConfigure, PinSet, PinClear, PinToggle, PinRead	Configure direção e flags antes do uso; níveis lógicos Zephyr
ADC	Initialize, IsReady, ConversionGet	Configura canais do projeto; amostra bruta de até 16 bits em int32_t
PWM	Initialize, IsReady, Set	Canal, período e pulso em nanossegundos

Os prefixos padrão combinam instância e função, como SERCOM5_USART, SERCOM4_I2C, PORTD_SECURE_GPIO e TCC1_PWM. IsReady retorna bool; PinRead retorna 0/1 ou erro; as demais operações retornam 0 ou errno negativo. As funções de delay retornam void. delay_ms usa k_msleep e delay_us usa k_busy_wait.

O Zephyr continua responsável pela inicialização de hardware, clocks, pinctrl e interrupções. A camada oferece nomes inspirados no MCC, não compatibilidade integral com a API Harmony. Sem callbacks, DMA ou gerenciamento próprio de interrupções nesta versão. Não use operações bloqueantes em ISR. Não compartilhe a UART da console com um protocolo sem considerar a mistura de mensagens.

ADC requer canais e propriedades obrigatórias do controlador; os valores de clock devem ser adequados ao dispositivo. Dispositivos sem wrapper permanecem acessíveis pela API nativa Zephyr. Um build confirma a integração, mas não substitui a validação elétrica e funcional na placa.

Regeneração

app.overlay, prj.conf e CMakeLists.txt preservam o conteúdo fora dos blocos marcados. Os arquivos dentro de mcc_generated são inteiramente gerados; mantenha seu código fora dessa pasta. Um arquivo sem identificação de geração não é sobrescrito. Ao retirar uma instância, seu arquivo antigo permanece no disco e sai da lista CMake. Ao desativar a camada, a integração CMake é desativada; adapte as chamadas existentes na aplicação.

Verificação e empacotamento

ZCONF_WORKSPACE=/caminho/do/workspace node test/selftest.js /caminho/do/modelo.json
node test/mcc.test.js
node test/webview.test.js /caminho/do/modelo.json
python3 package-vsix.py
code --profile Zephyr --install-extension dist/zconf-0.2.2.vsix --force

O teste webview verifica eventos e montagem do DOM; não valida a aparência. As APIs usadas podem ser consultadas na documentação oficial de periféricos Zephyr.

---

zConf — an MCC-style configurator for Zephyr on Microchip devices

zConf is a VS Code extension that gives the Microchip zSDK the kind of graphical configuration MPLAB developers expect from MCC — peripheral selection, a pin manager, a clock configurator and a software (Kconfig) view — but it speaks Zephyr's own language throughout: it reads the devicetree and Kconfig of your workspace and writes a devicetree overlay and prj.conf. No parallel database, no code generator of its own, nothing that has to be kept in sync with upstream.

                 ┌─────────────────────────────────────────────┐
  board .dts ───►│ cpp  ──►  edtlib (Zephyr's own dts parser)   │
  bindings/  ───►│                                             │──► model JSON
  <soc>-pinctrl.h│ regex scan of the HAL pin-mux header        │    (.zconf-cache/)
  Kconfig tree ─►│ regex index of config symbols               │
                 └─────────────────────────────────────────────┘
                                      │
                                      ▼
                            zConf webview (GUI)
                                      │
                             edits land in zconf.json
                                      │
                                      ▼
                      app.overlay  +  prj.conf   (between markers)

What each tab does

Tab	MCC equivalent	What it actually edits
Overview	Project dashboard	nothing — board, SoC, counts, warnings, paths
Peripherals	Device/Project Resources	status, compatible (the peripheral's mode), and every property its binding declares
Pin Manager	Pin Manager / Pin Grid	a &pinctrl { <label>_zconf { … } } group plus pinctrl-0 on the node
Clocks	Clock Configurator	the properties of the devicetree clock subtree, with live frequency maths
Software	MCC "libraries" / project properties	CONFIG_* lines in prj.conf
Examples	MCC project templates	creates apps/<name> from a template or a Zephyr sample
Generate	Generate button	writes app.overlay, prj.conf, zconf.json

Quick settings

Each peripheral opens with the handful of fields that actually define its behaviour, above the full property table:

Category	Fields
UART	Baud rate (bps) with presets from 1200 to 3 Mbps, data bits, parity, stop bits, flow control
I2C	Bus speed, with Standard / Fast / Fast Plus / High Speed presets
SPI	SCK frequency
CAN	Nominal and data bitrate, sample point
Timer / PWM	Prescaler, counter width, channels
ADC	Channels, clock divider

A field only appears when the effective binding declares it, so switching a SERCOM from UART to I2C swaps Baud rate for Bus speed instead of offering something the driver would reject. Typing a value and clicking a preset both write the same devicetree property — current-speed = <921600>;.

ADC — a dedicated, MCC-shaped editor

The ADC gets its own screen instead of the generic property table, laid out the way MCC lays one out.

Clock and timing — the controller's dividers, with the derived figures computed from the clock tree and the formula the binding itself states:

Family	Formula	Properties
ADC G2 (PIC32CK SG/GC)	TAD = T_GCLK x (CTLCKDIV + 1) x (2 x ADCDIV)	ctrl-clock-div, adc-div-ratio, adc-wkup-clock-count
ADC G1 (SAM D5x/E5x, PIC32CX SG, PIC32CM JH)	f_ADC = f_GCLK / prescaler	prescaler

GCLK_ADC, CTL_CLK, ADC_CLK, TAD and the wake-up time are shown live. When the board's clock tree has no GCLK entry feeding that ADC, they read — and the panel says to add one on the Clocks tab rather than inventing a number.

Channels — add and remove rows; each writes a channel@N child node from the standard adc-controller.yaml child-binding:

&adc0 {
	#address-cells = <1>;
	#size-cells = <0>;

	channel@4 {
		reg = <4>;
		zephyr,gain = "ADC_GAIN_1";
		zephyr,reference = "ADC_REF_INTERNAL";
		zephyr,vref-mv = <3300>;
		zephyr,acquisition-time = <ADC_ACQ_TIME(ADC_ACQ_TIME_TICKS, 10)>;
		zephyr,resolution = <12>;
		zephyr,oversampling = <4>;
	};
};

Details that make it behave like MCC rather than like a form:

• The analog input dropdown is built from the MCHP_ADC_* macros in the dt-bindings header this board includes — AIN0…AINn plus the internal sources (temperature sensor, IVREF, bandgap, DAC, scaled supplies).
• Where the input is selected depends on the driver. G1 selects ADC_CONFIGURABLE_INPUTS, so reg is the channel id and zephyr,input-positive picks the pin. G2 does not, so the channel's reg is the analog input — zConf then labels reg "Analog input" and does not offer zephyr,input-positive at all, because the driver would ignore it.
• Differential is greyed out on inputs the driver rejects: adc_mchp_g2.c only accepts AIN0, AIN2 and AIN4, and the panel enforces exactly that.
• Acquisition time is composed from the ADC_ACQ_TIME(unit, value) macro — default / ticks / µs / ns — and ticks are shown converted to nanoseconds at the current ADC clock.
• Oversampling is entered as N and annotated with the 2^N samples it averages.
• The full property table is still one click away under All N devicetree properties; nothing is hidden permanently.

Ethernet PHY

A PHY node offers every PHY binding this workspace ships, Microchip parts first: KSZ8081, KSZ9131, LAN8742, VSC8541, T1S (10BASE-T1S), the generic MII PHY, and the third-party ones. Picking a part writes

&phy { compatible = "microchip,ksz8081"; status = "okay"; };

and nothing else: Zephyr's PHY drivers are default y gated on DT_HAS_<COMPAT>_ENABLED, so the devicetree alone pulls the driver in. zConf deliberately does not invent a CONFIG_PHY_* line.

Examples

The Examples tab creates apps/<name> from:

• zConf templates — four focused BSD-socket applications written for this SDK: TCP server, TCP client, UDP server, UDP client. Static IPv4 by default, DHCP one line away, each with a README saying how to test it with nc.
• Zephyr samples already in this workspace — web server (full HTTP/1.1+2, and a minimal one), echo server/client, HTTP client, WebSocket, MQTT, CoAP, Prometheus, DHCPv4, telnet, zperf, mDNS, plus blinky / hello world / shell.
• USB device — CDC ACM (virtual COM port), CDC-to-UART bridge, console over CDC, HID keyboard, HID mouse, mass storage, DFU, WebUSB.

Each entry carries what it needs (needs ethernet, needs USB device), and the badge turns red when the selected board's devicetree has no matching peripheral — checked against the board, not a list of board names.

USB host is a different story

Zephyr's USB host stack is marked [EXPERIMENTAL] and implements exactly one class: UVC. There is no CDC, HID or MSC host class. On top of that, no Microchip SoC in this zSDK has a UHC (host controller) driver — the only ones present are NXP's four and the external MAX3421E over SPI. So USB host · CDC ACM, USB host · HID and USB host · mass storage are listed as unavailable with that reason and point at the device-side equivalent. USB device is fully supported: udc_mchp_g1, udc_mchp_sam, udc_sam0, udc_sam_usbhs and udc_sam_udp cover the PIC32CK/CX/CZ, SAM D5x/E5x and SAMA7 parts, and nine boards in this zSDK declare zephyr_udc0.

Every entry is checked against the filesystem before it is offered. Things this zSDK does not have are listed as unavailable with the reason and the nearest alternative rather than quietly omitted — SNMP, for instance: neither Zephyr nor the Microchip modules carry an SNMP stack, so the tab says so and points at the Prometheus exporter.

Creating an example copies it, renames the CMake project(), adds the zConf marker regions to prj.conf and app.overlay, writes a zconf.json that records where it came from, and makes it the application the configurator edits. Also available as zConf: New Application from Example.

Peripheral modes

Microchip's multi-function blocks appear in the devicetree with a bare compatible until a mode is chosen:

sercom0: sercom@... { compatible = "microchip,sercom-g1"; status = "disabled"; };

Picking I2C in the Peripherals tab emits

&sercom0 {
	compatible = "microchip,sercom-g1-i2c";
	clock-frequency = <400000>;
	pinctrl-0 = <&sercom0_zconf>;
	pinctrl-names = "default";
	status = "okay";
};

and adds CONFIG_I2C=y to prj.conf — the same two-step (peripheral + driver) that MCC does for you. The property editor switches to the microchip,sercom-g1-i2c binding's own schema, so you only ever see properties that exist in that mode.

Nothing you wrote is overwritten

Generated content lives strictly between markers:

/* --- zconf:begin (generated — do not edit by hand) --- */
...
/* --- zconf:end --- */

Everything outside them is preserved verbatim on every regeneration, in both app.overlay and prj.conf. zconf.json is the source of truth for the generated region — commit it.

Install

./install.sh          # into ~/.vscode/extensions

Then Developer: Reload Window and run zConf: Open Configurator.

There is no build step: the extension is dependency-free JavaScript, and the model backend is a single Python file that uses the devicetree package already shipped inside zephyr/scripts/.

Mode	Layout	When
(default) --hybrid	real folder, src/ media/ backend/ linked to this checkout	development in the Default profile — edits apply after a window reload
--profile <name>	builds a .vsix and installs it	any named profile — the only way that works
--copy	full copy	handing the folder to someone else
--symlink	one symlink for the whole extension	only if you know your VS Code follows it
--uninstall	removes it	—

The .vsix is built by package-vsix.py (plain zipfile — no npm or vsce needed) and lands in dist/. A .vsix install copies the files, so re-run --profile after editing.

If the commands do not appear in the Command Palette

Two things bite here, in this order:

1. VS Code profiles. A folder in ~/.vscode/extensions belongs to the Default profile only. A named profile (Zephyr, MPLAB, …) keeps its own list in ~/.config/Code/User/profiles/<id>/extensions.json, and the only supported way to add to it is a .vsix:

   ./install.sh --profile Zephyr
   

   Check which profiles exist, and what each one has, with:

   cat ~/.config/Code/User/globalStorage/storage.json | python3 -m json.tool | grep -A20 userDataProfiles
   

2. Symlinks. VS Code scans its extensions folder with readdir(withFileTypes) and keeps entries whose isDirectory() is true — which is false for a symlink. A symlinked extension is skipped at scan time even though code --list-extensions still reports it. That is why the folder install is hybrid (real directory, linked subfolders) rather than one symlink.

Settings

Setting	Default	Meaning
zconf.workspaceRoot	(auto)	west topdir. Auto-detection looks for .west/, zephyr/Kconfig.zephyr or microchip-zsdk/west.yml — first in the open folder and up to four parents, then one level down into its subfolders. With no folder open it searches from $HOME the same way. Set this explicitly to override.
zconf.defaultBoard	pic32ck_sg01_cult	board target
zconf.defaultApp	apps/hello_mchp	application directory the GUI edits
zconf.buildDir	build	west build directory; if present, the Software tab shows the effective CONFIG_* of the last build
zconf.python	(auto)	defaults to <root>/.venv/bin/python, else python3
zconf.indexKconfig	true	index Kconfig symbols on model load

Commands

• zConf: Open Configurator
• zConf: Reload Device Model — re-runs the backend (do this after west update, a new board, or a HAL change)
• zConf: Generate (overlay + prj.conf) — works headless too, without opening the GUI
• zConf: Select Board / Select Application
• zConf: Build / Flash Application — validates, generates and invokes west for the selected application; Depurar starts a Cortex-Debug session with the VS Code debug controls (pyOCD/J-Link).
• zConf: Open Generated Overlay / Open zconf.json

Model cache

The backend writes <root>/.zconf-cache/<board>.json. It is a cache, safe to delete, and .gitignored. Rebuild it from the GUI, from zConf: Reload Device Model, from the zConf: Regenerate model cache task, or by hand:

python3 tools/zconf/backend/zconf_model.py \
    --workspace . --board pic32ck_sg01_cult \
    --out .zconf-cache/pic32ck_sg01_cult.json

Useful flags: --no-kconfig (much faster), --build-dir build (read effective CONFIG_*), --cpp /usr/bin/cpp.

Tests

node tools/zconf/test/selftest.js .zconf-cache/<board>.json

Covers property formatting, marker splicing, pin bookkeeping and conflict detection, project mutations, clock arithmetic (including that doubling the PLL feedback divider doubles the CPU clock) and a full generate → reload → regenerate round trip.

Limits worth knowing

• Kconfig dependencies are not evaluated. zConf writes the symbols you ask for; Kconfig resolves depends on at build time. For a dependency-aware tree use the menuconfig button, which is one click away in the Software tab and footer.

• The clock maths covers the four MCU clock topologies this zSDK ships:

  Family	Shape
  PIC32CK SG/GC	XOSC / XOSC32K / DFLL48M → pll → pll0 → pll0outN
  PIC32CX SG, SAM D5x/E5x	XOSCn / XOSC32K / DFLL → fdpll → fdpllN
  PIC32CZ CA	XOSC / DFLL48M → dpll → dpll0 → dpll0outN, mclkdomain
  PIC32CM SG/GC, JH, PL	XOSC / OSC48M / OSCHF → dpll or fdpll (with its output prescaler)

  all of them then feeding gclkgen → gclkperiph / mclkcpu. The resolver works by repeated passes rather than a fixed order, because a DFLL can be clocked from a GCLK that is itself fed by a PLL.

  This is checked against each board's own cpu0/clock-frequency: 13 of the 17 boards derive it from the tree and match exactly, one (sam_e54_cult) leaves the tree unconfigured so the declared value is shown and labelled as declared rather than derived, and the three SAMA7/SAM9X MPUs drive their clocks from the PMC, which is not modelled — they show — rather than a guess.

• The pin matrix comes from <soc>-pinctrl.h in modules/hal/microchip. A SoC without that header gets an empty Pin Manager, and the Overview tab says so.

• The model is built from the board devicetree, not from your overlay, so the GUI always shows board defaults plus your deltas. That is what keeps regeneration idempotent.