68K ou coisa assim, again

Software e Hardware para uC da Qualcomm, NXP, FreeScale e Motorola

Moderadores: 51, guest2003

Mensagempor msamsoniuk » 31 Mar 2009 17:39

depende muito da forma que vc vai trabalhar, mas programando em C a stack vai muito rapido e eu chutaria algo em torno de 1KB para o ISP e de 1 a 4KB para cada USP de cada thread que vc for usar.

eh questao de conceito... em compiladores para pequenos mcus como o sdcc a stack nunca eh usada para variaveis, pq elas ficam na verdade no bss, soh que isso bloqueia o uso de reentrancia nas funcoes. se vc tem mais memoria e pode armazenar variaveis em stack, vc pode usar reentrancia a torto e a direito. e isso obviamente vai consumindo mais e mais memoria, pq as variaveis de trabalho vao comecar a ficar na stack e ela vai ter q ser maior.

no contexto de uma unica thread isso nao parece muito claro, mas se vc imaginar 10 threads chamando o mesmo printf a ficha cai. se o printf nao for reentrante, nao vai funcionar :)

enigmabox escreveu:Marcelo,

Tu ta enxergando melhor que eu...hehe
Deve ser isso mesmo , esqueci e deixei como MOVEM.W no lugar de MOVEM.L. Por isso que depois da interrupção, bagunça o A0 e D0, pois movimenta apenas o LSB do LONG A0/D0.

As rotinas de erro, fiz de modo simples para apenas ver qual erro deu na tela e parar a cpu, depois implemento com outros recursos. O legal seria como vc falou, na interrupção de erro, visualizar em qual ponto deu pane.

Por enquanto no 68681, estou lendo byte por byte, depois vou habilitar a leitura da fifo(3bytes) quando tiver cheia. Agora somente verifico o bit RxRDY e os de erro do SRA, se tiver tudo OK, transfiro o byte recebido pela porta A (RHRA) para uma variavel na memoria RAM, para posterior conversão ASCII para HEXA.
Quanto vc recomenda de espaço para as stacks? Estou usando 50h de espaço para cada stack onde posso guardar até 20 endereços. Acho que somente vai dar problema se tiver muitas subrotinas chamando outras, ai pode encavalar um espaço de stack com outro.
Valeu pela ajuda, vou ver se continuo com os testes hoje.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor enigmabox » 03 Abr 2009 07:51

Marcelo Sam,

Grato pelas dicas, depois de apanhar um pouco e fazer alguns testes, funcionou o modo de interrupção como deveria.
Parti o sistema de varios modos como MSP, ISP e USP, conferindo o modo e espaço utilizado atraves dos leds que liguei ao FC0-FC2.
Não funcionava direito antes, porque não entendia bem os modos de operação e defini os endereços da stack incorretamente. Isto é, eu estava com o 68000 na cabeça , assim defini em org 0, o endereço SP em 80040, mas depois na rotina principal eu carregava o ISP com outro endereço, por pensar que era outro modo de operação. Mas no mc68030 apos o reset a cpu parte como ISP que é o SP do 68000, que seria o modo compativel do 68000. Essa foi a confusão que fiz!
Com os comandos ORI e ADDI modifico o SR(bits S e M) e carrego o A7 com o end. da stack a ser utilizada.
Depois de corrigir os erros, as microchaves que liguei para simular o buserror, address erros e illegal instruction estão obedecendo a comandos.
Estou pensando tb futuramente, em usar o timer dentro do 68681, para gerar o tempo de varredura para um sistema multitarefa. Assim posso ligar este sinal em alguma INT do 68030.
Mas antes tenho que dominar bem esta cpu que é bem mais avançada que um 68000 basico. Que por enquanto está indomável!
:twisted:
enigmabox
 

Mensagempor msamsoniuk » 03 Abr 2009 10:33

hehehe eh realmente um processador de verdade neh... ateh eu tenho medo dele! soh quero ver a hora que vc habilitar as caches! =)
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor enigmabox » 03 Abr 2009 11:03

Marcelo,

Eu estou acostumado com o assembler do Z80/8051/68hc11 e 6502, quando mudei para 68030, foi uma mudança radical. É a mesma coisa mudar de um fusquinha 66 para uma BMW de ultima geração, ou mudar de um barraco para um castelo. Fiquei perdido com tanto recurso.
Achei parecido com o assembler do 6502, que tem algumas instruções parecidas e com o mesmo nome que o da motorola, assim a transição ficou um pouco mais facil, em relação as subrotinas de comparação(CMP BEQ, etc). Mas ainda tenho que sair da mania do 8 bits.
Tem varias subrotinas que fiz e que estou refazendo para ter mais eficiencia em no 68030.
Pelo menos fico mais aliviado que as interrupções funcionaram.
Aos poucos vou habilitando os recursos novos até chegar o momento da habilitação do cache. Quero só ver no que vai dar!
:shock:
Quando o meu monitor do sistema estiver mais adiantado, eu postarei mais algumas fotos.
enigmabox
 

Mensagempor msamsoniuk » 03 Abr 2009 11:50

pois eh, eu acho que a motorola podia ter investido mais no coldfire para ele ter pelo menos os recursos do 68030, pois eh um processador realmente muito robusto. hoje ele perde em performance para o coldfire, mas em funcionalidade eh realmente imbativel, nao eh atoa que foi usado tantos anos em workstations unix e computadores desktop.

uma dica legal para ver como usar bem o assembler dele eh compilar codigo no gcc gerando o assembler! daih vc consegue visualizar melhor como usar as instrucoes de alto nivel que trabalham na stack, como pea, link, unlk, movem, etc. uma outra coisa interessante, mas raramente utilizada, sao as instrucoes com ciclo RMW (read-modify-write), para semaforos e listas linkadas em sistemas SMP.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor enigmabox » 03 Abr 2009 16:08

Marcelo,
A motorola devia deixar o nucleo dos microcontroladores como a cpu 68030, ao inves de ficar retirando o que acham que eram instruções obsoletas. Assim criaram o nucleo CPU32.
Da CPU32, retiraram mais ainda, caminhando quase para uma cpu risc, e fizeram o coldfire.
Já q vc tocou no assunto. No gcc como faço para indicar o inicio do programa, como um ORG? Ou monta o codigo direto no endereço 0?
Será que dá pra pegar o codigo objeto do gcc e criar um Srecord ou desmembrar o binario para arquivos ODD e EVEN?
Tenho uma maquina com linux instalada com o GCC, vou brincar um pouco depois para saber como é a conversão do C para o assembler.
Por falar em SMP, como tá sua placa? Tem previsão para as duas CPUs trocarem tiros? :D
enigmabox
 

Mensagempor msamsoniuk » 04 Abr 2009 01:53

pois eh, eu tb fiquei meio cabreiro quando comecei a mexer com o coldfire, mas no fim das contas ateh que ele se saiu muito bem. apesar do core ser mais simples, o nivel de complexidade em termos de perifericos aumenta bastante em comparacao com os 680x0 e 683xx, embora nao tenha a mesma funcionalidade de produtos como o 68302 ou 68360.

sobre o gcc eu recomendaria vc dar uma zoiada em um rascunho de sistema operacional que eu escrevi faz alguns anos com um colega:

http://liquidfire.sourceforge.net/liquid-current

e jah adianto que *nao* usamos uma boa solucao... simplesmente escrevemos todo o codigo usando labels, compilamos para gerar os elfs independentes de posicao e na hora de linkar posicionamos os blocos nos respectivos enderecos, gerando uma imagem binaria.

recentemente, trabalhando com o coldfire, eu usei uma solucao melhorzinha, que foi aplicar uma serie de labels e, na hora de linkar, usar um linker script, assim eh possivel posicionar explicitamente os blocos para que fiquem em determinados enderecos. tambem descobri que eh possivel linkar os objetos elf de modo a produzir nao apenas saida binaria como no exemplo acima, mas tambem S19, atraves da opcao --oformat srec.

sobre a minha placa SMP, parada ateh o inverno neh... e para piorar precisei depenar e vender o HC908 de controle dela! hehehe mas logo eu monto outro para dar continuidade ao projeto! jah comecei a confeccionar o circuitinho de interface do HC908 com o bus do 68EC000 e esta relativamente simples e facil, pq eu resolvi usar apenas 8 bits de largura (muito trampo fazer com 16 bits)... uma hora sai :)
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor enigmabox » 04 Abr 2009 08:02

Na epoca, desisti da seria 683xx para aprendizado, pois acho que a cpu 68030 é mais versatil, apesar de ter que ligar varios perifericos externamente, o resultado no final acho que fica melhor.
Na linha 683xx nem dá pra ligar uma FPU como a 68882.
Outro nucleo que começei a brincar mas parei no momento foi o DSP mc56F8013, que tem um nucleo hibrido de 3 cpus 32bits. Acho que esta seria uma boa opção de mcu/dsp, mas o nucleo é muito mais simples que um core 68k.
Usar um mcu , como o coldfire, com tudo imbutido dependendo do projeto, fica dificil, falo em relação da ampliação do hardware. Pois vc tem que analisar os perifericos que o nucleo tem e ver se serve para a aplicação. Se o fabricante nao dispor de uma mcu com os perifericos que vc quer utilizar, tem que optar por uma cpu. Ou fazer um barramento externo, ligando os perifericos via usb, ou I2C.
Para celulares, tv de plasma,lcd, cameras digitais,etc é uma ótima opção, mas para o ramo industrial, como plc, hardwares expecificos, como inversores de motor, acho que tem que ser uma cpu ou um mcu da linha 683xx.
Outra coisa que vi alguns dizerem é que a linha coldfire, nao é muito boa para se trabalhar com sinais de video. Nao sei se é verdade.
No monitor do sistema, estou fazendo varias subrotinas para calculo de cursor, calculo de pixel, conversores de base numerica, etc.
Reservei um espaço na ram para as variaveis, tais como, linha, coluna, x1, y1, x2, y2, resultados, etc
Assim, carrego as variaveis com os valores, chamo a subrotina que deixa tb o resultado na area de variaveis. Assim nao preciso ficar pensando onde usei o registro A0, D1, A5, etc....
Estou fazendo "alla antica", como a apple fazia. Não é tão rapido como usar modo direto com os registros da cpu, mas fica mais eficiente e organizado.
Para a parte grafica estou me baseando em um livro antigo da micro$ofre "Programmers guide to PC & PS2 - Video Systems de 1987". É direcionado a programação do 8088/8086 e 6845, mas a parte matematica e logica se aplica a qualquer cpu. Isso vai me ajudar quando eu fizer uma nova placa de video com resolução mais alta.
Porque nao usa um mc68hc11 na placa, junto com o par de mc68EC000?
Mais pra frente eu vou usar C para o 68030, por enquanto quero aprender bem este novo assembler.
enigmabox
 

Mensagempor msamsoniuk » 04 Abr 2009 12:03

enigmabox escreveu:Na epoca, desisti da seria 683xx para aprendizado, pois acho que a cpu 68030 é mais versatil, apesar de ter que ligar varios perifericos externamente, o resultado no final acho que fica melhor.
Na linha 683xx nem dá pra ligar uma FPU como a 68882.


acho que depende muito da aplicacao... vc pode focar em sistemas menos expansiveis e mais expansiveis. no caso de sistemas menos expansiveis, os 683xx, coldfires e ateh mesmo algumas montagens mais restritas com os 680x0 acabam resolvendo.

no caso de montagens mais expansiveis, uma coisa que eu achei muito interessante no 68302 e 68360 eh o fato de ser possivel desligar o core deles e pendurar eles como perifericos avancados em qq 680x0. no caso do 68302, que jah tem um core 68000 capaz de ir ateh os 33MHz, faz sentido usar como periferico avancado para o 68020 ou 68030, em funcao do bus assincrono de 16 bits. no caso do 68360, que tem um core cpu32+ (quase um 68030) e roda ateh os 40MHz, vc pode usar como "chipset" periferico de um 68040 ou 68060, suportando inclusive acessos sincronos de 32 bits em burst! :)

infelizmente, este potencial para montagens mais expansiveis foi perdido na familia coldfire. outra perda importante eh que os blocos de perifericos inteligentes dos 68302 e 68360 foram movidos para os powerquicc.

Outro nucleo que começei a brincar mas parei no momento foi o DSP mc56F8013, que tem um nucleo hibrido de 3 cpus 32bits. Acho que esta seria uma boa opção de mcu/dsp, mas o nucleo é muito mais simples que um core 68k.


eu acho mais interessante aquela familia starcore deles, mas sao DSPs mais cavalos para mim! hehehe estes dias eles lancaram um six-core de 1GHz que atinge 48 mil MMACs... bem que eu gostaria de ter alguma aplicacao que usasse tudo isso :)

Usar um mcu , como o coldfire, com tudo imbutido dependendo do projeto, fica dificil, falo em relação da ampliação do hardware. Pois vc tem que analisar os perifericos que o nucleo tem e ver se serve para a aplicação. Se o fabricante nao dispor de uma mcu com os perifericos que vc quer utilizar, tem que optar por uma cpu. Ou fazer um barramento externo, ligando os perifericos via usb, ou I2C.

Para celulares, tv de plasma,lcd, cameras digitais,etc é uma ótima opção, mas para o ramo industrial, como plc, hardwares expecificos, como inversores de motor, acho que tem que ser uma cpu ou um mcu da linha 683xx


eu diria que vc tem menos flexibilidade de expansao, pq obviamente vc nao pode trocar o chip inteiro, mas ateh certo limite nao eh tao restritivo assim. por exemplo, o MCF5270 possui uma fast-ethernet on-chip e 4 canais de DMA que podem transferir dados muito rapidamente entre perifericos e a memoria SDRAM. quer dizer, nada impede que vc conecte os perifericos diretamente no bus dele e aproveite os canais de DMA.

por outro lado, tem as limitacoes que a gente conhece. por exemplo, para usar duas ethernets, vc pode plugar um periferico extra, mas dae nao tem os infinitos ring-buffers que aumentam cavalarmente a performance. ou vc muda de coldfire e pega um com duas fast-ethernets ou monta dois coldfires em sistemas independentes interconectados via DMA.

uma solucao que eu acho que se encaixa melhor ao coldfire (ao menos no MCF5270 e similares) eh pensar nele como um gateway de rede para interfaces paralelas hi-speed, onde a funcao dele eh simplesmente rodar um uclinux fazendo toda a interface entre o mundo externo da fast-ethernet e as paralelas hi-speed ativadas via DMA.

daih nesta paralela hi-speed vc coloca sua aplicacao especifica: uma FPGA, um DSP ou mesmo outro mcu mais especializado (683xx) para a interface com a aplicacao final. essa ideia da interface hi-speed pode ser modelada na interface IDE por exemplo.

Outra coisa que vi alguns dizerem é que a linha coldfire, nao é muito boa para se trabalhar com sinais de video. Nao sei se é verdade.


comparado com um blackfin sim! :)

mas se for analisar a complexidade de um BF537 com suporte a video e fast-ethernet (BGA) em comparacao com um MCF5270 trabalhando com um BF531 (ambos QFP e considerando que podemos ligar 4x BF531 via DMA ao MCF5270), talvez a ultima solucao fique mais simples e acessivel.

No monitor do sistema, estou fazendo varias subrotinas para calculo de cursor, calculo de pixel, conversores de base numerica, etc.
Reservei um espaço na ram para as variaveis, tais como, linha, coluna, x1, y1, x2, y2, resultados, etc
Assim, carrego as variaveis com os valores, chamo a subrotina que deixa tb o resultado na area de variaveis. Assim nao preciso ficar pensando onde usei o registro A0, D1, A5, etc....
Estou fazendo "alla antica", como a apple fazia. Não é tão rapido como usar modo direto com os registros da cpu, mas fica mais eficiente e organizado.
Para a parte grafica estou me baseando em um livro antigo da micro$ofre "Programmers guide to PC & PS2 - Video Systems de 1987". É direcionado a programação do 8088/8086 e 6845, mas a parte matematica e logica se aplica a qualquer cpu. Isso vai me ajudar quando eu fizer uma nova placa de video com resolução mais alta.


naquele codigo do microkernel q te passei estes dias tem um suporte a fb do 68328 no meio dos drivers... ele eh bem simples, um conjunto de rotinas justamente para printar caracteres no frame buffer e algumas funcionalidades para scroll, pixels e linhas :)

Porque nao usa um mc68hc11 na placa, junto com o par de mc68EC000?
Mais pra frente eu vou usar C para o 68030, por enquanto quero aprender bem este novo assembler.


eh que eu soh tenho ferramentas para os HC908 aqui! :)
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor enigmabox » 06 Abr 2009 07:52

Marcelo,
Pelo que percebo na sua explanação, o modo mais rapido e uma tendencia é usar o modo DMA e ethernet. Usando outras interfaces seriais como SPI,I2C,Can,USB, o sistema não tem muita eficiencia, a menos que sejam ligado varios perifericos em rede, mas ai é melhor Ethernet.
Tudo vai depender dos perifericos que vc usara na aplicação, depois é só escolher a MCU.
Por enquanto quero aprender bem o 68030, depois passo para algo mais rapido como um Coldfire.
Não sabia que na linha 683xx dá pra desligar a CPU e usar como periferico, muito interessante!. Vou pesquisar mais sobre isso.
Será que na linha Coldfire, já tem periferico Sata ou Fireware? Seriam tb duas interfaces de grande velocidade.
Estou dando uma olhada no seu microkernel, apesar de nao usar a linguagem C por enquanto com o 68030. Depois farei alguns testes compilando com o GCC.
Te disse sobre o mc68hc11, porque já tem um monitor na Rom interna. É só ligar um max232 no 68hc11 e via serial conectar no PC. Assim com o monitor pode-se transferir programas para o 68hc11 ou usar o assembler/disassembler interno. Nem precisa gravar eprom, dá pra usar uma ram com bateria.
Uma ideia que tive era, atraves do monitor do 68hc11, transferir um programa para uma posição de memoria, que poderia ser uma area compartilhada com o 68K.
Ferramentas para o mc68hc11 tá cheia na net, dá pra usar o SDCC,GCC, etc. O nucleo é bem parecido com o HC08, assim passar de um para o outro é facil. Há varios anos atras comprei varios mc68hc11a1fn, se precisar de algum me avise, ou tb de alguma ferramenta.
enigmabox
 

Mensagempor msamsoniuk » 06 Abr 2009 11:09

enigmabox escreveu:Marcelo,
Pelo que percebo na sua explanação, o modo mais rapido e uma tendencia é usar o modo DMA e ethernet. Usando outras interfaces seriais como SPI,I2C,Can,USB, o sistema não tem muita eficiencia, a menos que sejam ligado varios perifericos em rede, mas ai é melhor Ethernet.


ethernet eu acho que eh tendencia para interconexao de sistemas, justamente pq as interfaces ethernet sao rapidas e eficientes. mas para interface com perifericos no mesmo sistema, as interfaces seriais nao deixam de serem eficientes, eh questao apenas de saber se elas vao trancar ou nao o processamento. por exemplo, se vc tiver que atender a interface SPI byte a byte via interrupcao, a coisa fica bem feia! hehehe mas se tiver opcao de atender a SPI via DMA, o impacto fica bem pequeno, mas eh uma interface apenas para uso local.

Tudo vai depender dos perifericos que vc usara na aplicação, depois é só escolher a MCU.
Por enquanto quero aprender bem o 68030, depois passo para algo mais rapido como um Coldfire.
Não sabia que na linha 683xx dá pra desligar a CPU e usar como periferico, muito interessante!. Vou pesquisar mais sobre isso.


bom, eu vi essa opcao apenas no 68302 e 68360. no 68306, que eu conheco melhor, isso nao eh possivel. o 68306 ateh aceita trabalhar em SMP, mas os outros processadores do conjunto nunca podem monopolizar longamente a ocupacao do bus, senao o refresh da DRAM falha! hehehe :)

Será que na linha Coldfire, já tem periferico Sata ou Fireware? Seriam tb duas interfaces de grande velocidade.


eu acho que os CFv4 tem interface sata e pci... e se tem pci, por tabela vc tem qq outra interface (firewire, scsi, wifi, etc). mas comeca a ficar mais caro e complexo neh... eh aquilo q eu jah comentei estes dias, se vc pode trabalhar com BGA e PCBs complexas e caras, vc tem mais opcoes de componentes avancados!

mas acho que a freescale mantem os 680x0 e 683xx em producao justamente pq *muita* gente nao consegue migrar para os componentes mais complexos.

Estou dando uma olhada no seu microkernel, apesar de nao usar a linguagem C por enquanto com o 68030. Depois farei alguns testes compilando com o GCC.


eh um codigo bem antigo, mas tem umas ideias boas referentes a integracao de codigo C e asm com ferramentas gnu no 68000.

Te disse sobre o mc68hc11, porque já tem um monitor na Rom interna. É só ligar um max232 no 68hc11 e via serial conectar no PC. Assim com o monitor pode-se transferir programas para o 68hc11 ou usar o assembler/disassembler interno. Nem precisa gravar eprom, dá pra usar uma ram com bateria.

Uma ideia que tive era, atraves do monitor do 68hc11, transferir um programa para uma posição de memoria, que poderia ser uma area compartilhada com o 68K.

Ferramentas para o mc68hc11 tá cheia na net, dá pra usar o SDCC,GCC, etc. O nucleo é bem parecido com o HC08, assim passar de um para o outro é facil. Há varios anos atras comprei varios mc68hc11a1fn, se precisar de algum me avise, ou tb de alguma ferramenta.


pois eh, eu tenho um estoque grande de HC908 aqui tambem! :)

enfim, eu estou fazendo algo similar... o HC908 roda um supervisor que me permite descarregar um S19 na sram do 68000. na verdade o meu conceito original era isso que vc descreveu, mas na hora de implementar o hardware achei complexo montar 3 latches extras para os 24 bits do bus e entao estou tentando uma solucao alternativa.

a minha ideia eh usar o proprio 68000 para gerar os enderecos da sram enquanto o HC908 faz a gravacao. o conceito eh um pouco mais complexo, mas simplifica o hardware: vou precisar apenas de 1 buffer bidirecional e muito menos fiacao!... bom, ainda te que ser implementado. se funcionar eu descrevo melhor a ideia! hehehe :)

por sinal, a forma que eu gravo a flash do HC908 eh exatamente essa q vc descreveu: tenho um max232 ligado a ele e booto ele ativando uma rom especial que contem um pequeno programa monitor. ele nao parece ser tao avancado quanto o do HC11, mas contem justamente o necessario para gravar a flash via serial... no momento estou usando o SDCC como compilador.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor enigmabox » 06 Abr 2009 12:06

Marcelo,

A vantagem que vejo no hc908 é a flash e a freq. maior de operação. No hc11 pelo menos na versao que tenho, não tem, mas em seu lugar tem eeprom de 512 bytes + Ram + ADC, etc. O que pode ser habilitado no hc11 é a rom com o monitor Buffalo. Neste monitor, vc pode criar o codigo, colocar em qualquer espaço do hc11, assemblar, debugar. Resumindo, vc não necessita de nenhum aplicativo extra. Somente o Hiperterminal da MS para comunicar.
Esta ideia que vc está adotando , entendi, vc tinha explicado anteriormente. Parece que funciona, são sei se é o mesmo que o Mastk, tá usando para carregar o Srecord.
Nesta semana, vou fazer os primeiros testes de carregamento de programa com o Srecord. Já consegui fazer o Mc68030 comunicar com o Mc68681. Voltei atras no momento e não estou usando mais a interrupção INT5 para o 68681, estou usando o modo convencional. Analiso o SRA do 68681, se recebe algo , copio o RHRA do 68681 para a ram do mc68681. Já fiz uns testes de visualizar os dados do cabeçalho do S0 no monitor de TV e até agora tudo tá funcionando bem.
enigmabox
 

Mensagempor msamsoniuk » 06 Abr 2009 12:48

bom, eu acho que vc e o mastk estao usando a ideia do microcontrolador supervisor tomar o bus como se fosse um DMA e gravar direto na ram, enquanto o 680x0 esta em tri-state.

da forma que estou fazendo, o 68000 nao entra em tri-state e o HC908 funciona emulando uma flash. o truque de nao ter o bus de enderecos, apenas o chip-select, consiste em adivinhar qual endereco o 68000 estara solicitando! na pratica isso nao eh complexo: apos soltar o reset, o 68000 faz 8 acessos seguidos para puxar os 8 bytes do SP e PC. depois disso, ele faz 2 acessos para puxar os 2 byes de alguma instrucao no endereco de PC que eu especifiquei. basta entao eu fornecer a seguinte sequencia de instrucoes para o 68000, sem me preocupar onde o PC esta:

Código: Selecionar todos
  ...
start:
  move.l #FLASH_BASE,%a0
  move.l #SRAM_BASE,%a1
  move.l #SRAM_SIZE,%d0
shadow:
  move.l %a0@+,%a1@+
  dbt d0 loop
  clr.b SWITCH_MEMORY
  ...


obviamente, durante a instrucao move.l do loop eu preciso fornecer 4 bytes extras referentes ao acesso do ponteiro a0. estes 4 bytes sao justamente o bloco de btyes que o 68000 vai mover para mim para a sram! :)

eu tambem nao me preocupo com a temporizacao entre o HC908 e 68000 pq o bus eh assincrono. quando o 68000 inicia um ciclo de acesso, ele ativa o chip-select do HC908 e do buffer, tirando o buffer de tri-state e setando a direcao como leitura. o HC9008 reage colocando o dado no bus e ativa DTACK. o 68000 recebe o DTACK e termina o acesso, desligando o chip-select e desativando o buffer tri-state junto. obviamente vou precisar de uma logica extra para ativar e desativar DTACK, visto que o HC908 nao consegue remover DTACK rapido o suficiente para evitar um falso-DTACK no proximo acesso.

bom, na medida que este segmento faz parte do codigo real na sram, finalizada a transferencia eu posso simplesmente acessar um endereco que dispara o switch dos chipselects da flash e da sram, de modo que a proxima instrucao jah eh obtida da sram com zero wait-states.

obviamente, o numero de bytes que eu forneco tem que casar exatamente com o que seria fornecido pelo mesmo codigo rodando na sram, de modo que o PC aponte exatamente para a instrucao correta apos o switch para a sram.

feito o switch, o 68000 passa a usar o HC908 apenas como dispositivo de IO. neste caso a ideia eh descarregar na sram apenas um pequeno supervisor de boot, de modo que seja possivel transferir imagens maiores para a sram e completar o boot com o codigo rodando na sram e usando o HC908 apenas como periferico serial.

eu perco algumas funcionalidades de debug com isso: nao posso arbitrariamente ver variaveis na memoria ou fazer alteracoes, mas por outro lado o sistema se torna mais simples por eu nao precisar ligar o bus de enderecos... ao mesmo tempo, ele cria a logica assincrona necessaria para a comunicacao direta entra o 68000 e o HC908, de modo que o HC908 se torna um periferico valioso! :)

este componente que estou usando possui bastante recursos: UART, SPI, ADC, KBD, TBM e dois modulos TIM. o problema eh o encapsulamento de apenas 28 pinos, entao na pratica eu acabo comprometendo quase toda a funcionalidade para a interface com o 68000. embora eu possa perfeitamente multiplexar essas funcionalidades, no momento eu estou visualizando utilizar apenas a UART neste prototipo.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor enigmabox » 06 Abr 2009 16:21

Marcelo,
Pode ser que eu use a ideia do microcontrolador futuramente, como o Mastk esta usando, no momento estou gravando eprom´s(EVEN e ODD) para o 68030. Assim o programa vem via serial do PC para o MC68030 via MC68681. Por isso que estou fazendo um pequeno monitor no sistema, para não ficar gravando eprom a cada mudança de software.
É só dar reset na placa que entra no modo monitor, esperando o codigo Srecord do PC.
Pelo que entendi no inicio do carregamento do software o 68000 vai ficar entre o hc908 e a memoria, tranferindo de modo indireto as instruções para a ram. Depois que carregou os dados necessarios é só botar o 74hc245 em tri-state e botar o 68lc000 para funcionar na ram. Acho que funciona sim, apesar de ser bem engenhoso a coisa!
Outra coisa, como nao há isolaçao do bus de endereços, entre o 68000 e o hc908, acho que tu tem que colocar os portos do hc908 em 1 e modo leitura para nao atrapalhar o 68000, ficando assim o hc908 em modo IO.
Pena que tem poucos pinos, no 68hc11 tem 52pinos.
Será que não vai ter que colocar resistores pull-up em cada linha de endereços, no seu sistema?
No 68030 sem ligar os buffers 74hc245, hc244 e 573, deu problema. Se desligo a placa de video da placa principal, boto o MC68030 para funcionar, dá pane. Por não ter resistores pull-up eu acho.
enigmabox
 

Mensagempor msamsoniuk » 06 Abr 2009 18:22

essa solucao com um microcontrolador de supervisao eh bem bacana, pq eh uma especie de desenvolvimento em estagios: primeiro vc desenvolve o firmware basico do microcontrolador de supervisao, o que eh relativamente mais simples, fazendo apenas a interface entre o PC e o microprocessador principal. feito isso vc parte para o desenvolvimento do firmware do processador principal, contando jah com os recursos de supervisao do microcontrolador. estando todo o firwmare pronto, vc aproveita o microcontrolador de supervisao como um periferico inteligente.

eh claro, isso eh uma solucao de baixo custo, usando microcontroladores baratos e acessiveis.

por outro lado, um importante know how de como conectar eficientemente um microcontrolador em um microprocessador principal. em uma solucao mais definitiva, obviamente uma eprom ou flash de boot seria algo com performance melhor, da mesma forma q um 68681 realmente eh mais eficiente que um hc908 tentando fazer o mesmo trabalho, mas se comecarmos a pensar em um hc908 com interface usb ou spi, por exemplo, esta especie de coprocessamento comeca a valer a pena, mesmo que a interface entre o microcontrolador e o processador principal nao seja tao eficiente.

outra situacao interessante eh diagnostico e gerenciamento: vc pode utilizar o microcontrolador de supervisao para diagnosticar o processador principal e encontrar uma serie de problemas de funcionamento. neste ambito a solucao comeca a parecer valer a pena ateh mesmo em solucoes comerciais. um exemplo disso eh que algumas maquinas hp e sun possuem placas de supervisao. na maquina da sun que vi isso, por exemplo, tinhamos 4 processadores ultrasparc de alta velocidade supervisionados por um "pequeno" powerpc 860 com interface de supervisao pela serial e pela ethernet :)

sobre os resistores, vc tem que colocar resistor pelo menos no pino AS, visto que soh se deve decodificar algo em A0-31 quando AS esta presente! se o 68000 estiver com o bus em tri-state e A0-31 estiver pipocando por algum motivo, o pino AS com o resistor impede a ativacao de qq chip-select por engano. e claro, por via das duvidas eh sempre bom colocar resistores garantindo estados bem determinados para todos os pinos de controle.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

AnteriorPróximo

Voltar para NXP (ex-FreeScale (ex-Motorola))

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

x