MCF 52235

[danielvaz]

Alguém já utilizou o MCF52235, com ethernet embarcada? Estou com um kit da freescale (M52235EVB) e estou tentando fazer um servidor udp, mas estou tendo alguns problemas no de diz respeito a pilha. Já consigo escutar em uma porta, receber, tratar e enviar pacotes, mas quando esses pacotes chegam a uma taxa alta, meu buffer de pacotes enche. Como estou numa rede onde há um índice alto de pacotes de broadcast, acho que a placa fica capturando tais pacotes e zoa a apalicação no sentido de espaço na pila. Qualquer ajuda é bem vinda!

Estou usando o RTOS e a pilha TCP/UDP/IP da NICHELITE.

[msamsoniuk]

nao teria como ter um buffer maior ou entao comecar a descartar frames qdo o buffer encher ? uma outra solucao poderia ser nao capturar pacotes de broadcast. eu nao conheco nem o controlador fastethernet do 52235, mas em outros controladores normalmente existe uma tabela com os diversos MACs que vc quer q o controlador receba e o ff:ff:ff:ff:ff:ff costuma estar na lista. vc pode remover e entao fazer com que o controlador receba como valido apenas pacotes com o MAC da sua placa, dae vc minimiza o trafego.

por outro lado, talvez seu codigo devesse ser mais veloz para descartar pacotes q nao interessam... esse crash ocorre qdo vc esta debugando ou em condicao normal de processamento ?

[danielvaz]

Acho que agora sei qual é o problema.
Dando uma olhada mais a fundo na APPNOTE que fala sobre a implementação da pilha tcp/ip/udp para o MCU, verifiquei que a alocação de pacotes que entram/saem é feita por um gerenciador dedicado, isto é, não se mistura memória dos pacotes e HEAP.
Na inicialização é separado uma parte da memória que será usada apenas para os pacotes de dados, sendo assim não é possível essa parte da memória voltar a ser heap.
O problema está no número de pacotes que é disponibilizado. A pilha padrão disponibiliza 8 pacotes de 1542 bytes, e 6 pacotes de 200 bytes. É claro que a pilha é totalmente configurável e creio que a solução está em diminuir o número de bytes de cada pacote e aumentar o número total de pacotes para que não haja o uso de todos os pacotes. Como a comunicação RTP se dá de uma maneira muito rápida, os pacotes devem chegar a uma taxa elevada, e sendo assim devem acabar lotando rapidamente o buffer de 8 pacotes.
O FEC já filtra pacotes broadcast, vou tentar executar a customização da pilha ip/udp e assim que tiver algo mais prático entro em contato.

Desde já agradeço pela ajuda!
=)

[danielvaz]

Boa tarde,
Fiz algumas modificações na pilha fornecida pela NicheLite:
ipport.h -> numbigbuf -> de 8 pra 16
fecport.h -> maxethpkt -> de 0x0005ee pra 0x000258 (1520 pra 600)
pkt_alloc.c -> BIGBUFSIZE 636 (pode reduzir pra 616 - 600 + 16)
m_arp.c -> comentei if (ethhdr < pkt->nb_buff) panic("et_send: prepend");

Agora o módulo consegue enviar o que recebe, já tenho um eco-phone voip!
A única coisa estranha foi o esquema do if, não sei porque ele dá problemas nesse if. Talvez precise dar mais uma olhada no código pra saber porque a condição do if está sendo obedecida e chamando a função panic(). Com a anulação do if() o módulo se comportou como esperado. Qualquer idéia sobre o if() ficarei grato!

Obs: O módulo e o programa funcionam melhor quando rodam em modo normal, em modo background tem algumas dores de cabeça.

Abraços
--
Daniel Vaz

[msamsoniuk]

tah ficando bacana o projetinho hein! quando que sai as fotos ? hehehe =)

na verdade eu acho que vc vai usar frames maiores apenas durante a fase de negociacao de chamada SIP. os frames podem ateh arranhar os 1524 bytes, mas sao poucos e numa cadencia bem tranquila... soh depois que ele ativa o stream RTP bidirecional eh que vc tem o turbilhao de 50 frames/segundo, mas dae todos com apenas 200 bytes de tamanho (jah somando os 20 bytes do header IP, os 8 bytes do header UDP, os 12 bytes do header RTP e os 160 bytes do stream G.711).

eu lembro que nos meus testes no MPC860 eu estava usando queues de 32 frames nas SCCs para conseguir segurar o tranco do stream RTP com relativa tranquilidade.

vc disse q estava usando queues de 8x 1524 bytes e 6x 200 bytes, talvez uma ideia fosse mudar para uma queue de 4x 1524 bytes e 32x 200 bytes, ocupa menos espaco e permite mais frames justamente para o stream RTP na queue.

[helton]

Marcelo, uma dúvida, voce estava usando algum SO para os MPC860
(unix ?)

[danielvaz]

heheh! Por enquanto sem fotos, mas futuramente acho que sai um videozinho no youtube :P

na verdade eu acho que vc vai usar frames maiores apenas durante a fase de negociacao de chamada SIP. os frames podem ateh arranhar os 1524 bytes, mas sao poucos e numa cadencia bem tranquila...

Realmente, a cadência é de boa.

soh depois que ele ativa o stream RTP bidirecional eh que vc tem o turbilhao de 50 frames/segundo, mas dae todos com apenas 200 bytes de tamanho (jah somando os 20 bytes do header IP, os 8 bytes do header UDP, os 12 bytes do header RTP e os 160 bytes do stream G.711).

Aqui que mora o problema com a pilha implementada e fornecida pela NicheLite. A pilha usa duas filas, uma para pacotes BIG e outra para pacotes LITTLE. O número de pacotes de cada fila pode ser modificado. O problema é que a pilha interpreta todo pacote que entra na interface, como sendo um pacote BIG (logo a fila de pacotes little só servem para transmissão), sendo assim minha pilha BIG deve ter um tamanho adequado pra suportar os pacotes que chegam, e como é o RTP que vai me dar a taxa mais elevada, devo me preocupar com isso.
Então creio eu que se usar 4 pacotes de 1542 bytes, os pacotes RTP começaram a ser descartados, e até mesmo começarei a ter problemas na hora de transmitir pacotes, pois a fila é usada tanto na transmissão quanto na recepcção.
Por isso eu resolvi mudar o tamanho dos pacotes do tipo BIG de 1542 pra 636, sendo assim eu posso alocar maior número de pacotes, garantindo que não haja descarte de pacotes RTP e também que não haja falta de memória na hora de alocar espaço na transmissão de meus pacotes RTP.

[msamsoniuk]

Marcelo, uma dúvida, voce estava usando algum SO para os MPC860
(unix ?)

tudo com linux =P

[msamsoniuk]

Aqui que mora o problema com a pilha implementada e fornecida pela NicheLite. A pilha usa duas filas, uma para pacotes BIG e outra para pacotes LITTLE. O número de pacotes de cada fila pode ser modificado. O problema é que a pilha interpreta todo pacote que entra na interface, como sendo um pacote BIG (logo a fila de pacotes little só servem para transmissão), sendo assim minha pilha BIG deve ter um tamanho adequado pra suportar os pacotes que chegam, e como é o RTP que vai me dar a taxa mais elevada, devo me preocupar com isso.
Então creio eu que se usar 4 pacotes de 1542 bytes, os pacotes RTP começaram a ser descartados, e até mesmo começarei a ter problemas na hora de transmitir pacotes, pois a fila é usada tanto na transmissão quanto na recepcção.
Por isso eu resolvi mudar o tamanho dos pacotes do tipo BIG de 1542 pra 636, sendo assim eu posso alocar maior número de pacotes, garantindo que não haja descarte de pacotes RTP e também que não haja falta de memória na hora de alocar espaço na transmissão de meus pacotes RTP.

que dureza hein, no powerpc eh assim tb, mas eu tenho memoria suficiente para 32 frames de 1524 bytes no RX =~

[Kremer]

Oba, chegando agora na conversa depois de uma longa imersão em outros problemas!!!
Também uso muito o 52235 e estou atualmente com uma placa com 2 deles para um projeto legal de indicação de pesagem com células de carga digital via tcp/ip, onde o digitalizador tb é feito com ele e faz parte da linha de produtos.
Nesta placa foi conseguido utilizar inclusive todos os pinos dos dois chips!!!
Só espero que você não tenha que colocar também um webserver aí dentro (mas suponho que sim).
Sobre todos estes detalhes de buffers a serem utilizados pela FEC, vocês não acham que demorou pra freescale lançar uma versão de 64K nesta família? Seria algo do tipo seus problemas se acabaram!!!

[danielvaz]

Só espero que você não tenha que colocar também um webserver aí dentro (mas suponho que sim).

Minha aplicação não exige webserver, e pelo que andei lendo nos forums da freescale e se não estou enganado, parece que você teve alguns pepinos em rodar webserver neste coldfire, espero que já tenha solucionado o problema.

Sobre todos estes detalhes de buffers a serem utilizados pela FEC, vocês não acham que demorou pra freescale lançar uma versão de 64K nesta família? Seria algo do tipo seus problemas se acabaram!!!

Com certeza meus problemas quase que acabariam, mas acho que os 64k de SRAM devem vir na nova família ETHERNET+USB que está pra chegar!
Outra coisa que ajudaria bastante, no meu ponto de vista, é uma documentação melhor para a pilha tcp/ip/udp. Meu projeto estou fazendo em cima da aplicação UDP_SERVER e tipo, não consigo ainda criar um projeto totalmente em branco e adicionar apenas meu código, talvez seja porque estou iniciando ainda.
Abraços!

[msamsoniuk]

eu acho q o grande problema eh que o esquema de ring buffers da FEC desperdica muito espaco, outros mcus simplesmente colocam 1 ou 2 buffers e gerenciam isso via interrupcao frame a frame... entao uma jogada seria colocar 2 buffers tipo um ping pong, digamos de 8KB cada um, entao qdo recebe um frame em um, jah pode receber outro frame seguido no outro, mas gera uma interrupcao e vc simplesmente move o dma do primeiro um pouco mais adiante no buffer de 8KB, assim, se vc receber um frame grande ele recebe, mas se receber varios frames pequenos eles vao sendo colados na sequencia do frame grande e sem espacos entre eles, isso dae vai formando uma queue q pode ter ateh 2x 8KB, mas sem preocupacao de ter frames grande sou pequenos ocupando espaco atoa.

outra coisa eh que eu imagino q a FEC dele tem uma especie de buffer elastico, q nao contem um frame inteiro claro, mas q deve ter pelo menos uns 128 bytes, assim vc ganharia algum tempo p/ trabalhar entre dois frames grudados.

[danielvaz]

Com certeza se conseguisse melhorar essa alocação de buffers o programa seria bastante interessante, no entanto o que parece ser um pouco complicado neste caso é que a pilha já está pronta. Talvez o que pode ser estudado é o uso de uma nova pilha ou refazer a parte de alocação de buffers para esta pilha, mas não sei qual seria o nível de dificuldade em reimplementar a alocação e a busca de uma nova pilha com solução de memória mais dinâmica.
Por enquanto vou utilizar a pilha modificada, e citarei no projeto os devidos problemas e as soluções propostas e discutidas aqui no fórum.

Abraços

[msamsoniuk]

poderia fazer um contato com o pessoal q desenvolve o RTOS e explicar o problema, numa dessas eles tem dicas e solucoes. como eh um projeto em parte subsidiado pela freescale, poderia envolver tb um engenheiro de aplicacao, pois certamente eh do interesse deles encontrar e divulgar solucoes que permitam explorar melhor os recursos do componente.

[Kremer]

Minha aplicação não exige webserver, e pelo que andei lendo nos forums da freescale e se não estou enganado, parece que você teve alguns pepinos em rodar webserver neste coldfire, espero que já tenha solucionado o problema.

Bem, resolvi e não resolvi ao mesmo tempo. Digo isso porque esta funcionando bem até, mas matou completamente a RAM para o caso de multiplas conexoes na porta 80. Pra uma sem problemas, da até pra criar outras tasks e alocar 2K de stack para cada nova task que roda tranquilo.
Estou esperando esta novidade ai dos coldfires com 64K também.

Abraço