LIN Driver (Lin)

O driver LIN encapsula o hardware LIN do microcontrolador e disponibiliza à LIN Interface serviços relacionados a canais para frames, estado de suspensão e wake-up. Canais master disparam frames de forma assíncrona com Lin_SendFrame e os avaliam por meio de Lin_GetStatus. Canais slave reagem a cada cabeçalho recebido com uma indicação para a LIN Interface e, em seguida, transmitem, recebem ou ignoram a resposta ([SWS_Lin_00280]). Quais serviços estão disponíveis depende do tipo de nó configurado; os serviços de master existem apenas havendo pelo menos um canal master ([SWS_Lin_00287]).

mais ›

O driver LIN Lin é o driver de hardware da pilha LIN. Ele encapsula controladores LIN ou SCI/UARTs (SWS LIN Driver p. 9) e oferece à LIN Interface serviços relativos a canais para frames, estado de suspensão e wake-up. Ele requer obrigatoriamente Dem_SetEventStatus, EcuM_SetWakeupEvent e LinIf_WakeupConfirmation ([SWS_Lin_00234]). Opcionalmente, utiliza DET, Icu e os callbacks de slave da LinIf ([SWS_Lin_00235]).

Diagrama de contexto: Lin situa-se entre LinIf e o hardware LIN e reporta wake-ups e erros ao EcuM, LinIf, DEM e DET. Fontes: [SWS_Lin_00234], [SWS_Lin_00235]

Lin_Init transfere o módulo de LIN_UNINIT para LIN_INIT ([SWS_Lin_00006], SWS LIN Driver p. 24). Depois disso, cada canal comuta entre LIN_CH_OPERATIONAL, LIN_CH_SLEEP_PENDING (apenas master) e LIN_CH_SLEEP. Para isso, estão disponíveis Lin_GoToSleep, Lin_GoToSleepInternal, Lin_Wakeup e Lin_WakeupInternal ([SWS_Lin_00166], [SWS_Lin_00167], [SWS_Lin_00169], [SWS_Lin_00256]).

Diagrama de estados: estados do módulo e estados dos canais com suas transições. Que Lin_GetStatus conclui a etapa para LIN_CH_SLEEP é uma interpretação do diagrama. Fontes: SWS LIN Driver p. 24, [SWS_Lin_00166]

Canais mestre e escravo operam de forma fundamentalmente diferente. Um mestre dispara frames assincronamente com Lin_SendFrame e consulta o resultado mais tarde com Lin_GetStatus ([SWS_Lin_00191], [SWS_Lin_00168]). Esses serviços existem apenas quando pelo menos um canal está configurado como mestre ([SWS_Lin_00287]). Um escravo notifica cada header via LinIf_HeaderIndication ([SWS_Lin_00280]). Em função de Drc, ele então transmite, recebe ou ignora a resposta e a conclui com LinIf_TxConfirmation ou LinIf_RxIndication ([SWS_Lin_00282], [SWS_Lin_00274], [SWS_Lin_00275]).

Lin_CheckWakeup verifica wake-ups do barramento e os reporta ao EcuM e LinIf ([SWS_Lin_00160]). Em caso de erro, usos indevidos vão para a DET, como LIN_E_UNINIT ([SWS_Lin_00258]). Um timeout de hardware é reportado como LIN_E_TIMEOUT ao DEM ([SWS_Lin_00290]). Um canal mestre retorna erros de barramento como status; um canal escravo os reporta via LinIf_LinErrorIndication ([SWS_Lin_00233], [SWS_Lin_00277]).

mais ›

Função, limite do sistema e relação de instâncias do driver LIN

O driver LIN Lin encapsula o hardware LIN do microcontrolador. Ele disponibiliza ao LIN Interface (LinIf) serviços relacionados ao canal: transmitir e receber frames, colocar canais em sleep e acordá-los, bem como verificar wake-ups. Todos os serviços estão disponíveis via Lin.h ([SWS_Lin_00191], [SWS_Lin_00160]). Como hardware, a especificação menciona três tipos de LIN-Hardware-Units: controladores LIN completos, SCI/UARTs simples e SCI/UARTs estendidas. Cada uma é conectada a um cluster LIN por meio de CIs transceptores (SWS LIN Driver p. 9). O próprio driver não disponibiliza funções de callback (SWS LIN Driver p. 49). Em vez disso, ele chama funções de seu ambiente.

Interfaces externas obrigatórias são Dem_SetEventStatus, EcuM_SetWakeupEvent e LinIf_WakeupConfirmation ([SWS_Lin_00234]). Opcionalmente, o driver utiliza, entre outros:

• Det_ReportError e EcuM_CheckWakeup,
• Icu_EnableNotification e Icu_DisableNotification,
• para canais escravos, os callbacks LinIf_HeaderIndication, LinIf_RxIndication e LinIf_LinErrorIndication ([SWS_Lin_00235]).

[SWS_Lin_00226] lista os tipos importados como NetworkHandleType, EcuM_WakeupSourceType ou Std_ReturnType.

Diagrama de contexto: Lin situa-se entre LinIf e a LIN-Hardware-Unit. O driver reporta wake-ups ao EcuM e LinIf, e erros ao DEM e DET. Fontes: [SWS_Lin_00234], [SWS_Lin_00235], SWS LIN Driver p. 9

O driver é particionável. Ele opera em cada partição como uma instância independente, e uma chamada de API afeta apenas a partição na qual é realizada ([SWS_Lin_CONSTR_00270]). Se LinEcucPartitionRef referencia partições, LinChannelEcucPartitionRef deve referenciar exatamente uma delas ([SWS_Lin_CONSTR_00291]). LinChannel e LinTrcvChannel de um canal de comunicação devem referenciar a mesma partição ([SWS_Lin_CONSTR_00279]). O módulo rejeita mapeamentos de partição que a implementação não suporta ([SWS_Lin_00269]). Por canal, configuram-se, entre outros, baud rate, ID do canal, LinChannelWakeupSupport e o tipo de nó LinNodeType. Esta descrição de container provém de um release posterior (SWS LIN Driver p. 60).

Estados do módulo e dos canais, de Lin_Init até o estado de sleep

Após o reset, o módulo está no estado LIN_UNINIT e inutilizável. Lin_Init o conduz para LIN_INIT; ali, cada canal disponível está pronto para operação (SWS LIN Driver p. 24). Lin_Init recebe um ponteiro para uma estrutura Lin_ConfigType. O seu conteúdo é específico do hardware; ela contém os dados de inicialização para o driver, a Hardware-Unit e os canais ([SWS_Lin_00006], [SWS_Lin_00227]). O ambiente deve chamar Lin_Init apenas uma vez em tempo de execução (SWS LIN Driver p. 24).

Dentro de LIN_INIT, cada canal possui um estado próprio:

• LIN_CH_OPERATIONAL: O canal participa do cluster.
• LIN_CH_SLEEP: A detecção de wake-up está ativa; o hardware está, se aplicável, em modo de baixo consumo.
• LIN_CH_SLEEP_PENDING: apenas em canais mestre, após Lin_GoToSleep.

Evidências: SWS LIN Driver p. 24, [SWS_Lin_00166]. Lin_GoToSleepInternal define o canal diretamente como LIN_CH_SLEEP ([SWS_Lin_00167]). Lin_Wakeup conduz de volta para LIN_CH_OPERATIONAL com pulso de wake-up; Lin_WakeupInternal, sem pulso ([SWS_Lin_00169], [SWS_Lin_00256]).

Interpretação: É provável que Lin_GetStatus conclua a transição de LIN_CH_SLEEP_PENDING para LIN_CH_SLEEP. Pergunta Q-bb592e1d2ab668f0 (aberta) O diagrama apresenta Lin_GetStatus como transição na parte do mestre, e a LIN Interface espera o valor de retorno LIN_CH_SLEEP na verificação do comando go-to-sleep (SWS LIN Interface p. 56).

Diagrama de estados: Lin_Init eleva o módulo de LIN_UNINIT para LIN_INIT. Nele, cada canal alterna entre operação e sleep por meio de serviços de sleep e wake-up; a transição via Lin_GetStatus é uma interpretação. Fontes: SWS LIN Driver p. 24, [SWS_Lin_00166], [SWS_Lin_00167], [SWS_Lin_00169], [SWS_Lin_00256]

Descrição de frames via Lin_PduType e mapeamento de dados

Entre LinIf e o driver, Lin_PduType descreve um frame. A estrutura contém Pid, o modelo de checksum Cs, a direção da resposta Drc, o comprimento dos dados Dl e o ponteiro de dados SduPtr ([SWS_Lin_00232]). Os tipos dos elementos:

• Lin_FramePidType: identificador 0…0x3F com dois bits de paridade, faixa de valores 0…0xFE ([SWS_Lin_00228]).
• Lin_FrameDlType: 1…8 bytes de dados ([SWS_Lin_00231]).
• Lin_FrameCsModelType: LIN_ENHANCED_CS ou LIN_CLASSIC_CS ([SWS_Lin_00229]). O driver deve ser capaz de calcular ambos os checksums ([SWS_Lin_00019]).

Lin_FrameResponseType define como o nó trata a resposta ([SWS_Lin_00230]): ele mesmo a transmite (LIN_FRAMERESPONSE_TX), recebe uma resposta externa relevante (LIN_FRAMERESPONSE_RX) ou a ignora (LIN_FRAMERESPONSE_IGNORE). Na memória, o byte transmitido primeiro fica no elemento 0, e o transmitido por último, no elemento n-1 (SWS LIN Driver p. 30). Se o hardware não puder armazenar bytes em buffer, como em uma UART simples, o driver disponibiliza um buffer temporário. A transmissão com verificação por releitura e a recepção operam de forma não bloqueante (SWS LIN Driver p. 28).

Canais mestre: Lin_SendFrame e consulta de status

Em canais mestre, LinIf dispara cada frame com o serviço assíncrono Lin_SendFrame. O serviço transmite o header LIN e, se aplicável, a resposta ([SWS_Lin_00191]). Isso se aplica a entradas de recepção, transmissão e slave-to-slave da tabela de escalonamento (SWS LIN Interface p. 34, SWS LIN Interface p. 37, SWS LIN Interface p. 40).

LinIf consulta o resultado com o serviço síncrono Lin_GetStatus: no mínimo após o comprimento máximo do frame, no máximo na próxima entrada pendente da tabela de escalonamento (SWS LIN Interface p. 35, [SWS_Lin_00168]). O serviço retorna um Lin_StatusType, como LIN_TX_OK, LIN_TX_BUSY, LIN_RX_OK, LIN_RX_BUSY ou LIN_RX_NO_RESPONSE. Via Lin_SduPtr, ele também retorna um ponteiro para o buffer de recepção shadow ou de hardware ([SWS_Lin_00233]).

Os dados recebidos permanecem consistentes até que o próximo frame seja recebido com sucesso ou o estado do canal mude. O processamento completo de recepção pode residir em Lin_GetStatus (SWS LIN Driver p. 30). Para frames disparados por eventos, aplica-se (SWS LIN Interface p. 127, SWS LIN Interface p. 129):

• LIN_RX_NO_RESPONSE não avalia LinIf como erro.
• LIN_RX_ERROR é considerado uma colisão e conduz à mudança para o escalonamento de resolução de colisão.

Lin_SendFrame, Lin_GoToSleep e Lin_GetStatus existem apenas se pelo menos um canal estiver configurado como mestre via LinNodeType ([SWS_Lin_00287], [SWS_Lin_00288], [SWS_Lin_00289]). No R20-11, esses serviços são especificados como não reentrantes ([SWS_Lin_00168]). Versões posteriores permitem reentrância para diferentes canais (SWS LIN Driver p. 48); para o R20-11, aplica-se o requisito.

Diagrama de sequência: O mestre dispara um frame assincronamente com Lin_SendFrame e avalia o resultado em chamadas posteriores da MainFunction via Lin_GetStatus. Fontes: [SWS_Lin_00191], [SWS_Lin_00168], SWS LIN Interface p. 128, SWS LIN Interface p. 129, SWS LIN Interface p. 40

Canais escravos: processamento de resposta orientado por header

Um canal escravo deve ser capaz de receber um header a qualquer momento em LIN_CH_OPERATIONAL ([SWS_Lin_00272]). Para cada header, o driver chama LinIf_HeaderIndication. Nisso, PduPtr->Pid contém o PID recebido e PduPtr->SduPtr aponta para seu buffer de hardware ou shadow ([SWS_Lin_00280]). Se o hardware não detectar PIDs inválidos, o driver repassa o PID sem verificação ([SWS_Lin_00271]). Após o retorno E_OK, ele avalia PduPtr->Drc ([SWS_Lin_00282]):

• Em LIN_FRAMERESPONSE_TX, ele utiliza Cs, Dl e SduPtr para transmitir a resposta ([SWS_Lin_00283]).
• Em LIN_FRAMERESPONSE_RX, ele configura a recepção com Cs e Dl ([SWS_Lin_00284]).

Se LinIf_HeaderIndication retornar E_NOT_OK ou se Drc for igual a LIN_FRAMERESPONSE_IGNORE, o driver ignora a resposta ([SWS_Lin_00286]). Até o próximo header, ele não reporta nada ([SWS_Lin_00276]). Ele repassa diretamente uma resposta recebida com sucesso via LinIf_RxIndication e confirma uma transmitida via LinIf_TxConfirmation ([SWS_Lin_00274], [SWS_Lin_00275]). Cada resposta relevante deve ser concluída com um desses callbacks ou com LinIf_LinErrorIndication antes que o próximo header seja reportado ([SWS_Lin_00285]). O diagrama de recepção distingue duas variantes de hardware: controlador LIN em hardware e UART simples, na qual o driver copia cada byte para um buffer por interrupção (SWS LIN Driver p. 57).

Diagrama de sequência: Em um canal escravo, cada header dispara uma indicação para LinIf. Em função de Drc, o driver transmite, recebe ou ignora a resposta. Fontes: [SWS_Lin_00280], [SWS_Lin_00282], [SWS_Lin_00283], [SWS_Lin_00284], [SWS_Lin_00286], [SWS_Lin_00274], [SWS_Lin_00275], SWS LIN Interface p. 121, SWS LIN Interface p. 132

Sleep, acordar e detecção de wake-up

Apenas um mestre pode transmitir o comando go-to-sleep. Lin_GoToSleep o envia assincronamente conforme a LIN 2.1 e define o canal como LIN_CH_SLEEP_PENDING mesmo em caso de falha na transmissão. Se LinChannelWakeupSupport estiver configurado, o serviço ativa também o monitoramento do barramento ([SWS_Lin_00166], SWS LIN Driver p. 43). Para escravos, Lin_GoToSleep não é aplicável; eles utilizam Lin_GoToSleepInternal (SWS LIN Driver p. 31). Esse serviço define LIN_CH_SLEEP de forma síncrona, ativa a detecção de wake-up e, opcionalmente, coloca o hardware em um modo de economia de energia ([SWS_Lin_00167], SWS LIN Driver p. 44). Cada canal aceita solicitações de sleep independentemente dos demais (SWS LIN Driver p. 31).

Para acordar, há dois serviços disponíveis. Lin_Wakeup envia um pulso de wake-up no barramento; Lin_WakeupInternal coloca o canal em operação sem pulso ([SWS_Lin_00169], [SWS_Lin_00262]). Lin_CheckWakeup verifica um wake-up do barramento. Se o serviço reconhece um evento, como um nível RxD permanentemente baixo, reporta-o imediatamente via EcuM_SetWakeupEvent ao EcuM e via LinIf_WakeupConfirmation a LinIf ([SWS_Lin_00160], SWS LIN Driver p. 42). LinIf_CheckWakeup decide com base na fonte de wake-up se Lin_CheckWakeup ou LinTrcv_CheckWakeup é chamado (SWS LIN Interface p. 112). O LIN não necessita de validação de wake-up (SWS EcuM p. 173).

Diagrama de sequência: Um wake-up do barramento é repassado via EcuM e LinIf_CheckWakeup para Lin_CheckWakeup. O driver reporta um evento detectado ao EcuM e LinIf. Fontes: [SWS_Lin_00160], [SWS_Lin_00234], SWS LIN Driver p. 42, SWS LIN Interface p. 112, SWS EcuM p. 147

Comportamento em caso de erro

Com a detecção de erros de desenvolvimento ativada, os serviços reportam o uso indevido à DET ([SWS_Lin_00258], [SWS_Lin_00259], [SWS_Lin_00260]; para Lin_Wakeup, de forma análoga SWS LIN Driver p. 45):

• LIN_E_UNINIT em caso de chamada antes da inicialização,
• LIN_E_INVALID_CHANNEL em caso de canal inválido ou inativo,
• LIN_E_STATE_TRANSITION em caso de wake-up fora de LIN_CH_SLEEP.

Lin_GetVersionInfo reporta um ponteiro NULL com LIN_E_PARAM_POINTER ([SWS_Lin_00161], SWS LIN Driver p. 41). Com a DET desativada, Lin_CheckWakeup retorna E_NOT_OK para um canal inválido (SWS LIN Driver p. 42). Em geral, E_NOT_OK e LIN_NOT_OK indicam que ocorreu um erro de desenvolvimento ou de produção ([SWS_Lin_00191], [SWS_Lin_00233]).

LIN_E_TIMEOUT está especificado como erro de produção. Se for necessário aguardar uma alteração de status após uma modificação em registradores de controle do hardware, um timeout configurável protege essa espera. Se ele expirar, o erro é reportado ([SWS_Lin_00290]). A notificação segue via Dem_SetEventStatus ([SWS_Lin_00234]) para o evento referenciado em LinDemEventParameterRefs (SWS LIN Driver p. 65).

O driver reporta erros de comunicação de maneira distinta dependendo do tipo de nó. Canais mestre os retornam como status de Lin_GetStatus ([SWS_Lin_00233]):

• LIN_TX_HEADER_ERROR em caso de erros de releitura, paridade ou barramento no header,
• LIN_TX_ERROR em caso de falha na transmissão da resposta,
• LIN_RX_ERROR em caso de erros de enquadramento, overrun ou checksum, bem como resposta curta demais.

Canais escravos abortam o processamento do frame e chamam LinIf_LinErrorIndication com um Lin_SlaveErrorType ([SWS_Lin_00277], [SWS_Lin_91140]). Eles reportam eventos inválidos de barramento enquanto aguardam um header como LIN_ERR_HEADER ([SWS_Lin_00281]).

Diagrama de atividades: Erros de desenvolvimento vão para a DET, o timeout de hardware para o DEM. Um canal mestre reporta erros de comunicação de barramento como status; um canal escravo, como indicação de erro. Fontes: [SWS_Lin_00258], [SWS_Lin_00290], [SWS_Lin_00233], [SWS_Lin_00277], [SWS_Lin_00281], [SWS_Lin_00235]

Evidências mais detalhadas

• Serviços do mestre: transmissão com [SWS_Lin_00191], status com [SWS_Lin_00168], valores de status em [SWS_Lin_00233].
• Fluxo do escravo desde a indicação do header até a conclusão: [SWS_Lin_00280] a [SWS_Lin_00286], complementado por [SWS_Lin_00272] a [SWS_Lin_00277].
• Sleep e wake-up: [SWS_Lin_00166], [SWS_Lin_00167], [SWS_Lin_00169], [SWS_Lin_00256], [SWS_Lin_00262]. A detecção de wake-up é descrita por [SWS_Lin_00160].
• Descrição de frame: [SWS_Lin_00232] com os tipos de elemento [SWS_Lin_00228] a [SWS_Lin_00231].
• Dependência do tipo de nó: [SWS_Lin_00287] a [SWS_Lin_00289]. Particionamento: [SWS_Lin_CONSTR_00270], [SWS_Lin_CONSTR_00279], [SWS_Lin_CONSTR_00291].
• Máquina de estados e estados dos canais: SWS LIN Driver p. 24.
• Histórico de alterações: Lin_SendFrame originou-se de Lin_SendHeader e Lin_SendResponse; LIN_E_TIMEOUT foi definido como erro de produção (SWS LIN Driver p. 4).