test man*~

Finalmente consegui setar o clock para 48MHz usando o PLL e o clock interno de 8MHz e piscar um led. Tive muito problema ao ativar o PLL (PLLON), ocorria que o bit que indica que o PLL está ativo (PLLRDY) não estava setando (ele é setado por hardware)... Depois de umas 3 horas descobri onde estava o erro... Esses microcontroladores possuem proteção contra iniciante esse era o problema. Vou colocar o código aqui, quem sabe um dia sirva para alguém não perder várias horas como eu perdi . Usando o STM32CubeMX (gerador de código de inicialização) é muito simples, com 1 minuto dá para configurar o clock e fazer o led piscar. #include "stm32f072xb.h" #include "stm32f0xx.h" #include "stdio.h" void DelayNaoExato(uint32_t Valor){ volatile uint32_t i, j; for(i=0; i<Valor; i++) j++; } int main (void) { /********************* ALTERANDO O CLOCK PARA HSI8 - PLL - 48MHZ *********************/ // Seleciona como clock do sistema o HSI (8MHz) - CFGR > SW = 00 (no reset já fica no HSI) RCC->CFGR &= ~RCC_CFGR_SW; // Espera o clock ser mudado para o HSI interno while((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_HSI) { // Rotina para indicação de falha na alteração da fonte do clock } // Desabilitando o PLL para que ele aceite alterações nos registradores - CR > PLL_ON = 0 RCC->CR &= ~RCC_CR_PLLON; // Espera o PLL ser efetivamente desligado, no if qualquer coisa diferente de zero é true while(RCC->CR & RCC_CR_PLLRDY) { // Rotina para indicação de falha na alteração da fonte do clock } // Zera os bits da seleção de clock para o pll. CFGR > PLLSRC = 00 RCC->CFGR &= ~RCC_CFGR_PLLSRC; // ** Seleciona o HSI (8MHz) como fonte de clock do PLL. CFGR > PLLSRC = 01 RCC->CFGR |= RCC_CFGR_PLLSRC_HSI_PREDIV; // Zera todos os bits do PREDiv. CFGR2 > PREDIV = 0000 RCC->CFGR2 &= ~RCC_CFGR2_PREDIV; // ** PREDiv dividindo o HSI por 2 (8MHz / 2 = 4MHz). CFGR2 > PREDIV = 0010 RCC->CFGR2 |= RCC_CFGR2_PREDIV_DIV2; // Zera todos os bits do PLLMUL. CFGR > PLLMUL = 0000 RCC->CFGR &= ~RCC_CFGR_PLLMUL; // ** Multiplicador do PLL selecionado para 12 (4MHz * 12 = 48MHz). CFGR > PLLMUL = 1010 RCC->CFGR |= RCC_CFGR_PLLMUL12; // ** Zera todos os bits do AHB prescaler (AHB = 48MHz). CFGR > HPRE = 0000 RCC->CFGR &= ~RCC_CFGR_HPRE; // ** Zera todos os bits do APB1 prescaler (PCLK1 = 48MHz). CFGR > PPRE = 000 RCC->CFGR &= ~RCC_CFGR_PPRE; // Seleciona a latencia para "one wait state" e habilita prefetch buffer (deveser usado parawait state 1). FLASH->ACR |= FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY; // Espera o prefetch ser efetivamente ativado while((FLASH->ACR & FLASH_ACR_PRFTBS) == 0){ // Rotina para indicação de falha na ativação do prefetch } // Habilita novamente o PLL RCC->CR |= RCC_CR_PLLON; // Espera o PLL estabilizar while((RCC->CR & RCC_CR_PLLRDY) == 0){ // Rotina para indicação não pode ser ativado } // Seleciona o PLL como clock para o microcontrolador. SW = 10 RCC->CFGR |= RCC_CFGR_SW_PLL; while((RCC->CFGR & RCC_CFGR_SWS_PLL) != RCC_CFGR_SWS_PLL){ // Rotina para indicação de falha na alteração da fonte do clock } /*************************************************************************************/ /*************************** ALTERANDO O CLOCK PARA HSI48 ****************************/ /* FLASH->ACR |= FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY; RCC->APB1ENR |= RCC_APB1ENR_PWREN; while((FLASH->ACR & FLASH_ACR_PRFTBS) == 0){ } // Liga o oscilador interno HSI48 RCC->CR2 |= RCC_CR2_HSI48ON; // Espera o oscilador interno HSI48 se estabilizar while((RCC->CR2 & RCC_CR2_HSI48RDY) == 0){ // Rotina para indicação não pode ser ativado } // Seleciona o oscilador interno HSI48 como clock do sistema RCC->CFGR |= RCC_CFGR_SW_HSI48; // Espera a mudanca de clock terminar while((RCC->CFGR & RCC_CFGR_SWS_HSI48) != RCC_CFGR_SWS_HSI48){ // Rotina para indicação de falha na alteração da fonte do clock } */ /*************************************************************************************/ /*************************** SETANDO O PINO A5 COMO SAÍDA ****************************/ // Habilita o clock para os GPIO do port A RCC->AHBENR |= RCC_AHBENR_GPIOAEN; // Zera os bits referentes ao pino A5 MODER5 = 00 GPIOA->MODER &= ~GPIO_MODER_MODER5; // Seta o pino A5 para saida MODER5 = 01 GPIOA->MODER |= GPIO_MODER_MODER5_0; // Seta o pino para saida push pull GPIOA->OTYPER &= ~GPIO_OTYPER_OT_5; // Saída para altas velocidades, "this controls the rise time and fall time of the output signal" GPIOA->OSPEEDR |= GPIO_OSPEEDER_OSPEEDR5; // Desabilita os resistores de pull up e pull down. PUPDR5 = 00 GPIOA->PUPDR &= ~GPIO_PUPDR_PUPDR5; while(1) { // Liga o pino A5 GPIOA->BSRR |= GPIO_BSRR_BS_5; // Espera por um tempo nao especifico DelayNaoExato(200000); // Desiga o pino A5 GPIOA->BSRR |= GPIO_BSRR_BR_5; // Espera por um tempo nao especifico DelayNaoExato(200000); } }

Esse cara aqui explica. Porém, as peripheral libraries não estão disponíveis para os PIC16.

Eu não sei o que está acontecendo. Normalmente nesses projetos você começa do básico e vai evoluindo, quando você pega tudo pronto e aparece um problema fica difícil resolver... O bacana seria, 1° passo: Apenas ler o LM35; 2° passo: Converter a leitura para temperatura; 3° passo: Fazer o PWM controlar o brilho do LED; 4° passo: Controlar o aquecimento do resistor com o PWM... E assim por diante até o PID ter sido implementado. Ainda acho que seria bacana você fazer o seu do zero, sem bibliotecas, do zero mesmo...

Sim esqueci de remover o antigo input. Eu acho que essas seriam as modificações. Para faixa de 0 a 50°C conforme comentários. Você também pode colocar um delay para o Arduino não ficar calculando o PID direto... //Declaração de variáveis float TemperaturaCelsius; : : // Lendo a temperatura do HTU TemperaturaCelsius = htu.getTemperature_C(); // O PID reconhece os valores de 0 para 0% e 1023 para 100% (correto?) // assim é necessário adequar a temperatura para essa faixa // // 0°C -> 0 // 50°c -> 1023 // // Assim: // // TemperaturaCelsius -> Input // 50°C -> 1023 // // Input = (TemperaturaCelsius * 1023) / 50; // Input = (TemperaturaCelsius * 20,46; // // Aqui vem o código para o PID Input = TemperaturaCelsius * 20.46; // Adaptando a temperatura lida para a faixa do PID 0 -> 1023 //Input = analogRead(inputPin); myPID.Compute(); analogWrite(outputPin,Output); // Delay para calcula o PID a cada 250mS, isso influencia na parametrização delay(300);

Acho que é neste trecho que o PID é executado: //pid-related code Input = analogRead(inputPin); myPID.Compute(); analogWrite(outputPin,Output); Assim você precisa adicionar o código do sensor digital ai. Usando a biblioteca da fonte que você postou ficaria mais ou menos assim: //Declaração de variáveis float TemperaturaCelsius; : : // Lendo a temperatura do HTU TemperaturaCelsius = htu.getTemperature_C(); // O PID reconhece os valores de 0 para 0% e 1023 para 100% (correto?) // assim é necessário adequar a temperatura para essa faixa // // 0°C -> 0 // 50°c -> 1023 // // Assim: // // TemperaturaCelsius -> Input // 50°C -> 1023 // // Input = (TemperaturaCelsius * 1023) / 50; // Input = (TemperaturaCelsius * 20,46; // // Aqui vem o código para o PID Input = TemperaturaCelsius * 20.46; // Adaptando a temperatura lida para a faixa do PID 0 -> 1023 Input = analogRead(inputPin); myPID.Compute(); analogWrite(outputPin,Output); Existe a possibilidade de você desenvolver seu próprio PID, daí você pode imprimir os valores no serial monitor do Arduino mesmo, ficaria bem baca e você entenderia realmente como o PID funciona, se estiver disposto te passo um código esqueleto...

Isso, eu usei essa função "bytematch" para fazer o painel de LEDs, inicialmente o robô também a usava mas tive que mudar por causa do CRC, visto que esse pode ser qualquer caractere de 0 a 255 (CRC8)... Talvez uma solução seria usar um CRC de 7 bits e colocar ele deslocado para a esquerda assim o CRC nunca seria o caractere do bytematch, foi a primeira vez que desenvolvi o CRC e também foi a primeira vez que o usei... Mais pra frente eu com certeza me depararei com esse problema, porém eu já estarei "armado" hehe. Verificação de erro é muito bom, o código fica muito robusto!!

No circuito do lado esquerdo a entrada analógica do Arduino deveria ser conectada entre o resistor e o capacitor. Cara isso não está parecendo ruído do LM35, há algo de errado em algum lugar. Ruído de 35% do total da leitura (1023)... Isso está muito estranho. Repare a saída (variável manipulada) do PID, ela não está modulando coisa alguma... Ela está tabalhando em 0 ou 100% basicamente como um controlador ON / OFF. Mas enfim, poste o código do Arduino para que nós possamos analisar e tentar encaixar o HTU21D nele. ---- Uma coisa meio que off topic, você possui o LabVIEW? Se sim, instale o labVIEW Interface for Arduino (LIFA) abra o exemplo PID auto tuning, adicione o Arduino ao código do LabVIEW e veja o ajuste que o auto tuning fará...

Agora sim, final verdadeiro do projeto, ensinando movimentos ao robô movendo ele com as minhas mãos. Vou emprestar o robô para que um amigo do serviço leve para o seu filho que acabou de entrar para o grupo de robótica de escola (concorreu com 400 alunos )... Incrível como esse projeto abriu a minha mente, usar um compilador diferente com linguagem diferente foi uma experiência muito boa... Valeu pela iniciativa de publicar a apostila @aphawk... Ah é, no comentário anterior eu disse que deveria haver alguma forma de melhorar a comunicação... E realmente há... Depois de ler um pouco vi que um Real Time Operating System (RTOS) seria a solução (preguiçosa) para todos os problemas do código HAHAHAHAHA... Pedacinho do código do labview, só por curiosidade mesmo... Hehe

Não consegui entender o que você disse aqui. O sinal enviado pelo LM35 está com ruído, daí você quer usar outro sensor para tentar eliminá-lo, é isso? O sinal representa a temperatura, se ele está variando (grandes variações) significa que a temperatura está variando também... Ele será constante se a temperatura também o for. Não seria a parametrização do controlador PID que está muito fora? Proporcional muito baixo se comparado ao integral...

Você está usando o Atmel studio né? Ele é bacana exatamente para você criar as suas próriasbibliotecas =D... Se você quiser bibliotecas prontas para AVR acho que seria legal você dar uma olha no BASCOM AVR... Ele usa o Basic mas é extremamente parecido com o C Olha aqui. Serial com buffer. É meio que loucura indicar outro compilador e por cima com linguagem diferente, mas para bibliotecas dos periféricos (usart, i2c, timers, adc, spi, etc.) prontas realmente vale à pena dar uma olhada.

Não sei se isso é o que está causando problema. O módulo está com bateria? Esses módulos vem com um circuito para recarregar a bateria (LIR2032) porém esse circuito é de uma qualidade muito duvidosa... Assim várias pessoas (e eu também) o removem... Olhe esta imagem repare que ele remove o diodo e os resistores. Olha o que eu fiz (também tinha dó pois achava os módulos bonitinho =D, até que eu ví alguns vídeo do GratScott!): Antes, depois. Agora, talvez nem é isso... Estranho não funcionar.

O LED power do módulo DS1307 não acende? A ligação está mais ou menos assim?

HEHE os conversores de nível que você está falando deve ser algo deste tipo (ou similar) ele funcionará mesmo, porém eu ainda preferiria colocar os pull-up com os 3V3... Mas não é seu e você quer que fique bonito, ai é melhor usar o conversor mesmo.

Os resistores de pull-up devem estar ligados ao 3,3V, daí basta você assegurar que o dispositivo de maior tensão reconhece o 3,3V como nível alto (ver no datasheet). Isso pode ser feito pois nenhum dos dispositivos I2C coloca a linha em nível alto, o que eles fazem é deixar a linha flutuar assim os pull-up puxam a linha para o estado alto (open-drain). Por esse mesmo motivo o barramento I2C pode ser usado com vários mestres (multimestre) pois não haverá curto-circuito. Provavelmente ele retirou o resistor do módulo e adicionou resistores de pull-up externos conectados ao 3,3V. Neste caso suspeito que eles alimentaram o módulo com 3,3V. Porém o DS1307 espera um VCC de 4,5V no mínimo. De qualquer forma, o mais correto é mudar a tensão dos pull-ups... Essa é uma característica da I2C, fácil comunicação entre dispositivos com tensões de alimentação diferentes. Pegue o ferro de solda coloque o pouco de estanho e empurre que eles sairão tranquilo HEHE

Você pode usar a função port_a_pullups(0BXXXXXX); // X pode ser 1 ou 0 para pull-up habilidado ou desabilitato Ou então você pode usar o próprio CCS para gerar a função para você: Ainda há uma outra forma, você pode endereçar o registrador (ou fazer o CCS gerar uma lista com os endereços de todos os registradores) e então escrever diretamente nele: #byte MCU_WPUA = 0x095 #bit MCU_WPUA0 = MCU_WPUA.0 #bit MCU_WPUA1 = MCU_WPUA.1 #bit MCU_WPUA2 = MCU_WPUA.2 #bit MCU_WPUA4 = MCU_WPUA.4 #bit MCU_WPUA5 = MCU_WPUA.5 : : MCU_WPUA.MCU_WPUA0 = 1; // Ativa o pull-up resistor do pino A0 MCU_WPUA.MCU_WPUA4 = 0; // Desativa o pull-up resistor do pino A4

A versão 5.070 do CCS suporta esse modelo de PIC. O PICkit 3 suporta. Os pull-up resistors são ativados individualmente através do registrador WPUA (ou não?), assim você ativa somente os que você quer.

É bom você trabalhar com uma janela para ligar e desligar o dispositivo de refrigeração. O ideal mesmo seria você usar um controlador PID, ou apenas o PI (existem várias bibliotecas para o Arduíno), e é muito bacana ver a temperatura cravada no set-point ... Mas daí você teria que ter um circuito para controle da senoide e as coisas começariam a complicar... Código com a janela é mais ou menos assim: // Com esse código o dispositivo de refrigeração (cooler ou outro) // é ligado quando a temperatura ultrapassa 30° e desligado quando // ela cai abaixo de 25° byte LimiteSuperior, LimiteInferior; // Declaração das variáveis LimiteSuperior = 30; // Valor em que o dispositivo de refrigeração é LIGADO LimiteInferior = 25; // Valor em que o dispositivo de refrigeração é DESLIGADO if(ds.getTemperature_C() > LimiteSuperior) // Se a temperatura for maior que o limite superior digitalWrite(10, HIGH); // Liga o dispositivo de refrigeração else if(ds.getTemperature_C() < LimiteInferior)) // Se a temperatura for menor que o limite inferior digitalWrite(10, LOW); // Desliga o dispositivo de refrigeração }

Com certeza vou fazê-lo

Primeiro será necessário você usar um pino para o botão, no seu código o pino disponível é o 2 né? Então: int Contador = 0; // Variável usada para contar a quantidade de vezes que o botão foi apertado int Botao = 2; // Pino usadao para leitura do botão pinMode(Botao, INPUT); // Define o pino 2 (Botao) como entrada Depois você deverá retirar a parte que lê o potenciômetro e adicionar o código para a leitura no botão: void loop() { //int tpot = analogRead(pin_pot); //pausa = analogRead(pin_tempo) + 1; //if (tpot > 99) tpot=99; //display_value(tpot); if(digitalRead(Botao) == HIGH) { // Verifica se o botão foi apertado (nível logico alto) e se foi Contador += 1; // Incrementa avariavel Contador if(Contador > 99) // Se contador for maior que 99 (conta até 99) Contador = 0; // Zera a variável Contador display_value(Contador); // Envia o novo valor para o display while(digitalRead(Botao) == HIGH) // Espera o botão ser liberado } } Não testei, nem mesmo na simulação...

Segue um exemplo, aqui o PIC soma uma variável a cada segundo, e a cada soma manda o valor para o Arduíno que então imprimi o valor recebido no monitor serial. A comunicação é via I2C pois assim a serial fica livre para debugs... Download. Conexão: PIC SCL -------- ARDUINO SCL PIC SDA -------- ARDUINO SDA Com resistores de Pull Up (2k2 a 10k) em ambas as linhas conforme imagem abaixo. Código do PIC (MikroC PRO for PIC): // HS crystal externo 8MHz unsigned char Valor = 0; void main() { delay_ms(500); // Delay 0,5 segundo espera o Arduino se estabilizar. TRISB.RB0 = 0; // set direction to be output I2C1_Init(100000); // Inicializa i2c com o clock de 100KHz while(1) { latb.RB0 ^= 1; // Muda o estado do pino B0 (toggle) // Enviado dados para o AVR I2C1_Start(); // Inicia a comunicação I2C I2C1_Wr(0x58); // Envia o endereço I2C do Arduino I2C1_Wr(Valor); // Envia a variável valor para o Arduino I2C1_Stop(); // Aqui o AVR irá para a função de recebimento de bytes Valor += 1; // Incrementa 1 à variável valor if(Valor > 254) // Zera a variável quando ela alcançar 255 valor = 0; delay_ms(500); // Delay 0,5 segundo } } Código do Arduíno: #include <Wire.h> int LedPin = 13; // BuiltIn Led na placa do Arduino byte ByteRecebido; // Essa variável possui a quantidade de bytes a serem enviados pelo PIC volatile int QuantidadeBytesEsperados = 1; void setup() { pinMode(LedPin, OUTPUT); Serial.begin(9600); // Inicia a comunicação serial com velocidade de 9600 Serial.println("Testando comunicacao entre Arduino e PIC"); Wire.begin(0x2C); // Inicia a comunicação I2C como escravo de endereço 0x2C (0010 1100) -> O Arduino desconsidera o bit de leitura ou escrita // Mas o MikroC não, assim no MikroC deve ser usado 0x58 (0101 100X) onde X é o bit de leitura ou escrita // Escrita = 0 (0x58)| Leitura = 1 (0x59) Wire.setClock(100000); // I2C 100KHz Wire.onReceive(receiveEvent); // Função a ser executada quanto "QuantidadeBytesEsperados" bytes é enviado pelo mestre } void loop() { digitalWrite(LedPin, HIGH); // Pino digital 13 do Arduino em nível lógico alto delay(500); // Delay 0,5 segundo digitalWrite(LedPin, LOW); // Pino digital 13 do Arduino em nível lógico baixo delay(500); // Delay 0,5 segundo } void receiveEvent(int QuantidadeBytesEsperados) { ByteRecebido = Wire.read(); // Pega o valor enviado pelo PIC Serial.print("Valor recebido: "); // Imprimi o valor recebido na serial Serial.println(ByteRecebido); }

Depois que você falou sobre a diminuição da velocidade eu dei uma analisada no código, atentando-me para a temporização, e percebi que realmente há muitas falhas, não só com a interrupção do Timer, mas também com várias outras coisas como o próprio protocolo criado para comunicação: $ - Início do pacote BYTE1 + BYTE2 - Tamanho do pacote BYTE3 + BYTE4 - Comando BYTE5 . BYTEn - Dados [CRC] Ele pode ser melhorado, ainda não tenho certeza como, tenho algumas ideias, mas não certeza. O microcontrolador fazer todas aquelas verificações para todos os bytes recebidos é meio complicado, deve haver uma forma mais eficiente de fazê-lo, não há necessidade de mudar o protocolo em si, há uma necessidade de mudar como ele é executado no AVR. Porém, resolvi dar o projeto como concluído, pois para cada coisa que eu implementava apareciam ao menos dois problemas (código mal planejado), é como se o código estivesse no limite da temporização, e se eu continuasse insistindo eu com certeza ficaria até o fim do ano nesse robô. Ex.: era para o AVR perguntar de 3 em 3 segundos se a outra placa, a SSC-32U, estava presente, programei deu certo, porém apareceu um problema em outro lugar (também relacionada com a interrupção do Timer1)... Assim resolvi concluir, guardar as falhas e tentar corrigi-las nos próximos projetos, de todas elas a maior com certeza foi a falta de um planejamento geral antes de começar a programar, acho que essa foi a maior falha, chegou uma hora que eu perdi o controle do programa de tal forma que o problema aparecia e eu não fazia a mínima ideia de onde atuar para corrigi-lo, foi frustrante ... Um dia (em algum ponto no futuro) pretendo construir outro braço usando motores de passo e imprimindo ou usinando as partes com uma impressora 3D ou uma CNC daí com certeza a comunicação ficará mais rápida (espero)... Mas é isso ai, o negócio é sempre tentar melhorar, se for comparar o meu primeiro projeto com PIC com esse robô... Vish, nem dá para comparar está em um nível totalmente diferente ... Eu estou meio que querendo parar de usar bibliotecas prontas dos compiladores, como vou ter que ler datasheet (apesar de já ter lido boa parte do ATmega328P) já pulo direto para os ARM... A propósito, a Universidade do Texas disponibiliza através do Edx (professores doutores Valvano e Ramesh) um curso que usa o M4 da Texas Instruments, se você comprar o kit (de qualquer lugar, pode ser até do Aliexpress) para fazer a parte prática, na conclusão do curso você pode solicitar um certificado registrado (pagando US$50,00 ou US$99,00)... Valeu aí Paulão @aphawk , ainda coloco outro vídeo ensinando o robô com as mãos, vale lembrar que tudo começou na sua apostila HEHE.

Você estava certo mesmo Paulão @aphawk tive que reduzir a velocidade da serial (das duas) para 9600, todos os meus problemas, apareceram outros, foram embora depois que o fiz... Isso fez aumentar a minha vontade de usar os ARM, o DMA é muito show, ele é capaz de enviar dados pela serial sem intervenção da CPU ! Dei uma brincada com o Keil uVision (simulação) e é bem bacana de usar, e possui versão grátis (sem limitações) para os STM32F0 e STM32L0 (ARM Cortex M0), ainda há o coocox (esse é free mesmo) e suporta os ARM Cortex M4... Enfim... Voltando ao AVR, mais uma parte do robô, dessa vez mostrando o supervisório e ensinando um movimento a ele através do computador, no próximo mostro o ensinamento manual (movendo o robô com as mãos).

Dá para você preparar o byte toda vez antes de enviar, dai você configura o pino desejado e então envia o byte, tipo: #define Pino0 0b00000001 #define Pino1 0b00000010 #define Pino2 0b00000100 #define Pino3 0b00001000 #define Pino4 0b00010000 #define Pino5 0b00100000 #define Pino6 0b01000000 #define Pino7 0b10000000 byte SaidasPinos07=0; // Assim vamos supor que vocês quer setar uma saída: SaidasPinos07 |= Pino0; // seta o pino 0 //Aqui vai o código para enviar byte para as saídas expandidas com estado atualizado // E quando você quiser zerar uma saída SaidasPinos07 &= ~Pino7; // zera o pino 7 //Aqui vai o código para enviar byte para as saídas expandidas com estado atualizado Se for entradas você pode fazer o seguinte: #define Pino0 0b00000001 #define Pino1 0b00000010 #define Pino2 0b00000100 #define Pino3 0b00001000 #define Pino4 0b00010000 #define Pino5 0b00100000 #define Pino6 0b01000000 #define Pino7 0b10000000 byte EntradasPinos07=0; // Verificando o estado de uma entrada //Aqui vai o código para pegar o byte para as entradas expandidas (do Pino0 ao Pino7) if(EntradasPinos07 & Pino0) // Pino0 = 1 -> Pino zero em nível lógico alto 5V (Ard. UNO) else // Pino0 = 0 -> Pino zero em nível lógico baixo 0V

Outros 7 Como assim ? São 8kBytes (capacidade total para a 24C64) assim os 13 bits são suficientes para endereçar a memória inteira. 64 k bits = 8 k bytes ou eu estou comendo mosca? Hehe

Tipo, são 64kbits (8kbytes - 8k x 8bits) e 32kbits (4kbytes - 4k x 8bits) por isso os endereços podem ser de 12 ou 13 bits dependendo da eeprom que você vai usar... 24c32 - 32kbits e 24c64 - 64kbits... Estou no celular daí nem da pra entender o código =D