test man*~

Boa tarde pessoal estou com uma dúvida, quero saber o que a função read_adc() do CCS realmente faz... Dei uma olhada no arquivo .lst gerado e aqui está ele: .................... leitura=read_adc();0598: BSF FC2.1 -> Seta o bit 1 do registrador 0xFC2059A: BTFSC FC2.1 -> Testa se o bit 1 do registrador 0xFC2 é zero e se for pula a próxima linha059C: BRA 059A -> Volta para a linha de cima059E: MOVFF FC3,21 05A2: MOVFF FC4,22 O registrador 0xFC2 é o ADCON0 do PIC18F4550 e o bit 1 é o GO/*DONE. Aqui estão as dúvidas: A minha interpretação (depois do "->") do trecho do código acima está correta? O código acima espera o término da conversão ad para continuar o processo correto? Obrigado a quem responder!

Entendo, obrigado MOR_AL! Para concluir o tópico. Parece que no modo slave a função "i2c_write" não retorna o valor corretamente, assim deve ser usado o bit R/W do registrador SSPSTAT, esse bit é setado quando o endereço é recebido com o R/W (endereço + R/W) bit 1 e é zerado por uma condição de stop, start OU NACK DO MESTRE (que é o que eu estava querendo). Essa informação está na Application Note 734 da Microchip. Com isso agora consigo fazer o slave perceber que o mestre não quer ler mais bytes e ele está funcionando igual ao DS1307 (em termos de sequencia de comunicação). A função "i2c_isr_state" também parece não funcionar perfeitamente para todos os casos o Ttelmah postou um código mais eficiente (parece ser, não testei... Mas ele faz o que a Application note 734 sugere)... É isso, valeu!

Li o seu trabalho, queria ter lido antes de começar a fazer o programa para o DS1307 ... Uma dúvida; vamos supor um caso de multimestre (M1 e M2) se o M1 está transmitindo o M2 espera uma condição de stop no barramento para assim tentar iniciar uma comunicação, nos casos das figuras 9 e 10 se após a introdução do endereço da palavra (e a condição de stop) o M2 também iniciar uma comunicação pode ser que o M1 perca a arbitrariedade e assim ele não conseguirá ler os dados devendo esperar uma condição de stop (do M2) para reiniciar o procedimento, podendo perder a arbitrariedade novamente (na próxima tentativa) após o envio do endereço (endereço da palavra) e assim por diante... Por isso não seria melhor ter usado o repeated start? Pois daquela forma o M1 deve (caso haja outros mestres aguardando para se comunicar) ganhar a arbitrariedade 2 vezes consecutivas. Se for pensar bem você fez apenas para um único mestre então isso não importa né? Sou eu quem está viajando Gostei bastante da parte IV...

Muito obrigado... Vou ler antes de dormir hehe!!!! Hoje eu testei o código na prática, descobri que não é possível colocar breakpoint dentro de interrupção (pelo menos eu não consegui, provavelmente há como ) então fiz o PIC slave mandar todos os ACKS recebidos durante a transmissão para a serial e para a minha surpresa o slave funcionou exatamente como o proteus simulou , a função "i2c_write" sempre retorna o valor 1 (com o PIC no slave mode) independente de qual foi o ACk enviado pelo master... Dei uma pesquisada e descobri que outros tiveram esse problema: http://www.ccsinfo.com/forum/viewtopic.php?p=93584 http://www.ccsinfo.com/forum/viewtopic.php?p=60862 havia pesquisado antes e não encontrei coisa alguma mas agora encontrei . No segundo link o Ttelmah diz para usar o bit R/W do registrador SSPSTAT que é zerado quando a condição NACK é detectada... Isso resolve o problema . Vou ler a parte do MSSP do datasheet e depois vou testar o código novamente... Muito obrigado pelo link do trabalho mais tarde vou lê-lo. Após testar o código usando o R/W do SSPASTAT eu posto o resultado aqui para concluir o tópico!

Muito obrigado cara... Mande-me por favor! Vou ler ele ... Eu decidi montar, debugar com o Pickit2, colocar um breakpoint no lugar onde o primeiro ack é recebido e ver o que acontece... Eu comecei fazendo uma comunicação com o DS1307 daí achei o I2C muito interessante e adicionei uma memória EEPROM ao barramento, pretendo adicionar um PIC slave e depois mais 2 mestres... Tudo ocorreu bem na simulação até ocorrer esse problema no ACK... Mas enfim, obrigado pela resposta e aguardo o seu trabalho!

Boa note pessoal, Estou fazendo uma comunicação I2C entre dois PICs e estou com um problema, Tudo está ocorrendo de forma correta exceto o fato do PIC slave não pegar corretamente o ACK enviado pelo mestre após ele (o escravo) ter transmitido um byte. Pedaço do código, parte onde o slave envia o dado para o mestre: Uso o CCS ack=i2c_write(buffer[endereco]);//buffer[4] endereco++;//Endereco de 0 a 3 Após todas as escritas o ACK sempre é 1 (NO ACK), mesmo o mestre enviando o 0 (ACK). O mestre recebe os dados e envia o ACK corretamente o problema é o slave. Minha dúvida é a seguinte, como estou somente na simulação isso pode ser um erro do Proteus? Usei o I2C debbuger e simulei passo a passo (com o .cof) antes do mestre enviar o ACK o slave termina a instrução "i2c_write(buffer[endereco])" e atribui o valor 1 para a variável ACK e depois disso o mestre envia o ACK... alguém já teve este problema? Muito obrigado aos que responderem!

Quanto tempo não passo por aqui =D... O SHT1x e 7x não são I2C, em algum lugar do datasheet está escrito (não me lembro onde). Eu já usei 2 deles, são ótimos por sinal, repetitibilidade excelente mas realmente são caros. Na época comprei no mercado livre 2xSHT11 por R$100,00 mas não sei se encontra ainda. No início estava usando esse driver para simular (proteus): http://www.ccsinfo.com/forum/viewtopic.php?t=28564 Dava um erro na medição então eu resolvi criar um driver, o erro ficou igualzinho hehe! Uns amigos meus usaram o DHt11 e falaram que ele é muito bom mesmo...

Exemplo teclado matrial + enviar dado para serial + display LCD 16x2. Código CCS - Circuito PROTEUS! Download

Valeu ai Mulder! Vou brincar com isso nas férias /gg

Boa noite pessoal. Sink00, infomações valiosas essas... Valeu cara! (já copiei em um notepad =D) MatheusLPS, segue o vídeo com o acendimento dos LEDs. Percebi que ao dar o comando para acender o LED, no exato momento, a comunicação meio que dá uma travada, coloquei dois capacitores em paralelo à alimentação ai diminuiu, depois alimentei o circuito com uma fonte externa, ai ficou quase imperceptível. Valeu matheuzão...

Vou fazer o esquema de acender leds. Tem que verificar se vai acontecer algo quando o PIC acender ou apagá-los, como você disse... Assim que fizé-lo, posto aqui. Cara, uma dúvida. Qual a principal diferença entre a configuração HID e BULK? HID já tem drivers instalados e é mais lenta? Valeu pela ajuda em Matheus! Se não fosse você, acho que nem teria tentado mexer com USB.

O PICkit2 não reconheceu o PIC18F4550 (reconhece outros 18F's), mas o JDM reconheceu, estranho. Aê jovem! Fiz um teste com leitura de uma entrada analógica e plotagem das amostras no labVIEW, o capacitor usado foi de 224M (220nF). Segue o vídeo. Obs: A forma que consegui passar os dois vídeos ao mesmo tempo foi esta. Espere os dois vídeos carregarem, e depois aperte double up . USB PIC18F4550 labVIEW teste. (vídeo da esquerda adiantado 1 segundo, em relação ao vídeo da direita) *** EDIT Esqueci de tirar uns jumpers do gravador, por isto ele não estava reconhecendo.

Aff cara, não é possível... Iria começar a testar hoje, mas o PIC18F4550 veio queimado. Vou entrar em contato com a loja para eles trocarem (espero).

O pedido chegou, mas não tinha os capacitores (220/470n) na loja... Um amigo comprará eles pra mim, e ai sim começarei os testes... Pelo jeito, não terei problemas de fazer uma interface usando o labview, quando estiver finalizada coloco ela aqui... Mas quero aprender pelo menos o básico do visual C#, já arrumei umas vídeo aulas e apostilas. Qual eu baixo aqui: downloads Visual C# o Visual C# 2010 expres? Outra coisa, você poderia postar o seu projeto novamente Matheus? Quando vou baixar ele pelo 4shared da erro. Valeu ai cara!

Matheus, estava lendo um artigo ontem, e este dizia que o comprimento máximo do cabo USB é 5m. Você já já pensou em algo para aumentar essa distância? Tipo um módulo wireless que substitua o cabo...

Bem pensado, ótima dica! Vou fazê-lo. Segunda-feira começa a maratona de testes.. heh

Ok... Comprei o PIC, só falta chegar, vou fazer uma plaquinha para ir testando... Assim que fizer um led acender a apagar através de um comando no labVIEW eu posto aqui. Uploaded with ImageShack.us

Matheus (koala) você teve algum problema com o capacitor do VUSB? O cara aqui: http://www.vabsco.com/bardhp/ Fala que usou um de 200nF ceramico e teve problemas, e então trocou por um de 470nF também ceramico e os problemas se foram... Você usou 47uF, era polarizado? O terminal positivo ficou no pino VUSB? Entre o VCC e GND do USB você colocou um de 100nF mas isso foi apenas para deixar bem contínuo né? Vou encomendar o PIC, ai já vou pedir tudo de uma vez...

Esta sim matheus... Vou postar ele completo. Cara estou até emocionado, USB não é um bicho de 7 cabeças, é um bicho de 1000 cabeças HAHAHAHEHEHEHE, no codigo tem um esquema de VID e PID e para alterar essas duas coisas tem que alterar no driver também, e eu não sei como montar um driver para USB, eu peguei o que veio pronto e editei as coisas e deu certo (O.O)... Aprender este troço vai dar um trabalho louco HAHEHAHEHA... Código PIC (sem alteração) ///////////////////////////////////////////////////////////////////////// //// SineWaveUSB.c //// //// //// //// A continuacion se describe el programa de prueba para la //// //// comunicacion USB. Este programa es el más sencillo. //// //// //// //// Espera recibir 3 bytes de la PC. El primer byte es el modo //// //// En este programa solo se maneja el modo cero. //// //// Los otros dos bytes son datos y en este ejemplo se ignoran. //// //// //// //// El pic simplemente envìa los 256 bytes de una onda senoidal //// //// lo más rápido que puede. //// //// //// //// Configurar el programa en el host para recibir 256 bytes.- //// //// //// //// //// //// //// //// Rafael Rodriguez Covarrubias //// //// IICO-UASLP //// //// [email protected] //// ///////////////////////////////////////////////////////////////////////// #include <18F2550.h> #fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL3,CPUDIV1,VREGEN #use delay(clock=48000000) #define USB_HID_DEVICE FALSE //No se trata de un dispositivo HID #define USB_EP1_TX_ENABLE USB_ENABLE_BULK //Se habilita EP1(EndPoint1) for IN bulk transfers #define USB_EP1_RX_ENABLE USB_ENABLE_BULK //Se habilita EP1(EndPoint1) for OUT bulk transfers #define USB_EP1_TX_SIZE 64 //Memoria a reservar para el endpoint tx (Inpipe) #define USB_EP1_RX_SIZE 3 //Memoria a reservar para el endpoint rx (Outpipe) #include <pic18_usb.h> //Carga de las librerias USB. #include <usb_desc_scope_alt.h> //Carga el header con las definiciones. #include <usb.c> char sine_wave[256]={ 127, 130, 133, 136, 139, 142, 145, 148, 151, 154, 157, 160, 163, 166, 169, 172, 175, 178, 181, 184, 186, 189, 192, 195, 197, 200, 202, 205, 207, 210, 212, 214, 216, 219, 221, 223, 225, 227, 229, 230, 232, 234, 236, 237, 239, 240, 241, 243, 244, 245, 246, 247, 248, 249, 250, 250, 251, 252, 252, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 253, 252, 252, 251, 250, 250, 249, 248, 247, 246, 245, 244, 242, 241, 240, 238, 237, 235, 234, 232, 230, 228, 226, 224, 222, 220, 218, 216, 214, 211, 209, 207, 204, 202, 199, 197, 194, 191, 189, 186, 183, 180, 178, 175, 172, 169, 166, 163, 160, 157, 154, 151, 148, 145, 142, 138, 135, 132, 129, 127, 124, 121, 118, 114, 111, 108, 105, 102, 99, 96, 93, 90, 87, 84, 81, 78, 75, 73, 70, 67, 64, 62, 59, 56, 54, 51, 49, 46, 44, 42, 39, 37, 35, 33, 31, 29, 27, 25, 23, 22, 20, 18, 17, 15, 14, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 3, 3, 4, 5, 5, 6, 7, 8, 9, 11, 12, 13, 14, 16, 17, 19, 21, 22, 24, 26, 28, 30, 32, 34, 36, 38, 41, 43, 45, 48, 50, 53, 55, 58, 60, 63, 66, 69, 71, 74, 77, 80, 83, 86, 89, 92, 95, 98, 101, 104, 107, 110, 113, 116, 119, 122, 125 }; #define mode usb_indata[0] void main(void) { int8 usb_indata[3]; //declaramos variables usb_init(); //Se inicializa USB y espera que sea enumerado por la PC usb_task(); usb_wait_for_enumeration(); while (TRUE) //Ciclo principal { if(usb_enumerated()) //Si el PIC ha sido enumerado por la PC { if (usb_kbhit(1)) //y si hay un dato en el buffer de entrada USB. { usb_get_packet(1, usb_indata, 3); //Leemos el paquete de 3 bytes que hay en el OutPipe //(Leemos de la PC) if (mode == 0) //Si el primer byte (modo) es cero { //entonces lee los ADC's y envia //los datos (4 bytes) usb_puts(1,sine_wave,256,50); //Colocamos los 4 bytes en el InPipe.(Enviamos a la PC) } } } } } [/spoiler] Cabeçalho que pelo que eu pude entender até agora, está ligado ao driver e tem o nomezinho que aprece quando a instalação do driver é solicitada, e também o tal de VID e PID: /////////////////////////////////////////////////////////////////////////// //// usb_desc_scope.h //// //// //// //// Este programa unicamente se modificó al final en las strings //// //// que identifican el dispositivo. //// //// Aqui se puede definir outro VID&PID. Por ahora esta definido como //// //// VID 0x04D8&PID 0x0003 //// //// //// /////////////////////////////////////////////////////////////////////////// #IFNDEF __USB_DESCRIPTORS__ #DEFINE __USB_DESCRIPTORS__ #include <usb.h> ////////////////////////////////////////////////////////////////// /// /// start config descriptor /// right now we only support one configuration descriptor. /// the config, interface, class, and endpoint goes into this array. /// ////////////////////////////////////////////////////////////////// #DEFINE USB_TOTAL_CONFIG_LEN 32 //config+interface+class+endpoint //configuration descriptor char const USB_CONFIG_DESC[] = { //config_descriptor for config index 1 USB_DESC_CONFIG_LEN, //length of descriptor size USB_DESC_CONFIG_TYPE, //constant CONFIGURATION (0x02) USB_TOTAL_CONFIG_LEN,0, //size of all data returned for this config 1, //number of interfaces this device supports 0x01, //identifier for this configuration. (IF we had more than one configurations) 0x00, //index of string descriptor for this configuration 0xC0, //bit 6=1 if self powered, bit 5=1 if supports remote wakeup (we don't), bits 0-4 reserved and bit7=1 0x32, //maximum bus power required (maximum milliamperes/2) (0x32 = 100mA) //interface descriptor 0 alt 0 USB_DESC_INTERFACE_LEN, //length of descriptor USB_DESC_INTERFACE_TYPE, //constant INTERFACE (0x04) 0x00, //number defining this interface (IF we had more than one interface) 0x00, //alternate setting 2, //number of endpoints, not counting endpoint 0. 0xFF, //class code, FF = vendor defined 0xFF, //subclass code, FF = vendor 0xFF, //protocol code, FF = vendor 0x00, //index of string descriptor for interface //endpoint descriptor USB_DESC_ENDPOINT_LEN, //length of descriptor USB_DESC_ENDPOINT_TYPE, //constant ENDPOINT (0x05) 0x81, //endpoint number and direction (0x81 = EP1 IN) 0x02, //transfer type supported (0 is control, 1 is iso, 2 is bulk, 3 is interrupt) USB_EP1_TX_SIZE & 0xFF,USB_EP1_TX_SIZE >> 8, //maximum packet size supported 0x01, //polling interval in ms. (for interrupt transfers ONLY) //endpoint descriptor USB_DESC_ENDPOINT_LEN, //length of descriptor USB_DESC_ENDPOINT_TYPE, //constant ENDPOINT (0x05) 0x01, //endpoint number and direction (0x01 = EP1 OUT) 0x02, //transfer type supported (0 is control, 1 is iso, 2 is bulk, 3 is interrupt) USB_EP1_RX_SIZE & 0xFF,USB_EP1_RX_SIZE >> 8, //maximum packet size supported 0x01, //polling interval in ms. (for interrupt transfers ONLY) }; //****** BEGIN CONFIG DESCRIPTOR LOOKUP TABLES ******** //since we can't make pointers to constants in certain pic16s, this is an offset table to find // a specific descriptor in the above table. //NOTE: DO TO A LIMITATION OF THE CCS CODE, ALL HID INTERFACES MUST START AT 0 AND BE SEQUENTIAL // FOR EXAMPLE, IF YOU HAVE 2 HID INTERFACES THEY MUST BE INTERFACE 0 AND INTERFACE 1 #define USB_NUM_HID_INTERFACES 0 //the maximum number of interfaces seen on any config //for example, if config 1 has 1 interface and config 2 has 2 interfaces you must define this as 2 #define USB_MAX_NUM_INTERFACES 1 //define how many interfaces there are per config. [0] is the first config, etc. const char USB_NUM_INTERFACES[USB_NUM_CONFIGURATIONS]={1}; #if (sizeof(USB_CONFIG_DESC) != USB_TOTAL_CONFIG_LEN) #error USB_TOTAL_CONFIG_LEN not defined correctly #endif ////////////////////////////////////////////////////////////////// /// /// start device descriptors /// ////////////////////////////////////////////////////////////////// //device descriptor char const USB_DEVICE_DESC[] ={ USB_DESC_DEVICE_LEN, //the length of this report 0x01, //constant DEVICE (0x01) 0x10,0x01, //usb version in bcd 0x00, //class code (if 0, interface defines class. FF is vendor defined) 0x00, //subclass code 0x00, //protocol code USB_MAX_EP0_PACKET_LENGTH, //max packet size for endpoint 0. (SLOW SPEED SPECIFIES 8) 0xD8,0x04, //vendor id (0x04D8 is Microchip) 0x03,0x00, //product id (0x0003) 0x00,0x01, //device release number 0x01, //index of string description of manufacturer. therefore we point to string_1 array (see below) 0x02, //index of string descriptor of the product 0x00, //index of string descriptor of serial number USB_NUM_CONFIGURATIONS //number of possible configurations }; ////////////////////////////////////////////////////////////////// /// /// start string descriptors /// String 0 is a special language string, and must be defined. People in U.S.A. can leave this alone. /// /// You must define the length else get_next_string_character() will not see the string /// Current code only supports 10 strings (0 thru 9) /// ////////////////////////////////////////////////////////////////// //the offset of the starting location of each string. //offset[0] is the start of string 0, offset[1] is the start of string 1, etc. const char USB_STRING_DESC_OFFSET[]={0,4,14}; #define USB_STRING_DESC_COUNT sizeof(USB_STRING_DESC_OFFSET) char const USB_STRING_DESC[]={ //string 0 4, //length of string index USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING) 0x09,0x04, //Microsoft Defined for US-English //string 1 10, //length of string index USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING) 'I',0, 'I',0, 'C',0, 'O',0, //string 2 32, //length of string index USB_DESC_STRING_TYPE, //descriptor type 0x03 (STRING) 'F',0, 'l',0, 'o',0, 'w',0, ' ',0, 'C',0, 'o',0, 'n',0, 't',0, 'r',0, 'o',0, 'l',0, 'l',0, 'e',0, 'r',0 }; #ENDIF [/spoiler] Arquivo .INF que eu alterei e consegui alterar o que me parece ser o endereço do dispositivo USB. ; Installation file for mchpusb driver ; Copyright (C) 2004 by Microchip Technology, Inc. ; All rights reserved [Version] Signature=$WINDOWS NT$ Class=%ClassName% ClassGuid={4D36E97E-E325-11CE-BFC1-08002BE10318} Provider=%MFGNAME% CatalogFile=mchpusb.cat DriverVer=08/06/2007 [Manufacturer] %MFGNAME%=DeviceList [DestinationDirs] DefaultDestDir=10,System32\Drivers [SourceDisksFiles] mchpusb.sys=1 wdmstub.sys=1 [SourceDisksNames] 1=%INSTDISK%,,, [DeviceList] %DESCRIPTION%=DriverInstall,USB\VID_04D8&PID_0003 ;------------------------------------------------------------------------------ ; Windows 2000/XP Sections ;------------------------------------------------------------------------------ [DriverInstall.ntx86] CopyFiles=DriverCopyFiles [DriverCopyFiles] mchpusb.sys,,,2 [DriverInstall.ntx86.Services] AddService=MCHPUSB,2,DriverService [DriverService] ServiceType=1 StartType=3 ErrorControl=1 ServiceBinary=%10%\system32\drivers\mchpusb.sys AddReg=TraceFlags ;------------------------------------------------------------------------------ ; Windows 98/Me Sections ;------------------------------------------------------------------------------ [DriverInstall] AddReg=DriverAddReg CopyFiles=DriverCopyFiles,StubCopyFiles DriverVer=08/06/2007 ; TODO replace with real info [DriverAddReg] HKR,,DevLoader,,*ntkern HKR,,NTMPDriver,,"wdmstub.sys,mchpusb.sys" [StubCopyFiles] wdmstub.sys,,,2 ;------------------------------------------------------------------------------ ; String Definitions ;------------------------------------------------------------------------------ [Strings] MFGNAME="IICO" INSTDISK="FlowController Installation Disc" DESCRIPTION="Flow Controller" ClassName="PIC 18Fxx5x USB Devices" [/spoiler] Vou ter que ler muito sobre o protocolo USB. Links interessantes: http://www.pads.ufrj.br/~rapoport/usb/usb4.html http://homepages.dcc.ufmg.br/~adrianoc/usb/

Matheus, olhando este código você sabe me dizer se é bulk ou hid ou alguma outra coisa? #include <18F2550.h> #fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN #use delay(clock=48000000) #define USB_HID_DEVICE FALSE //No se trata de un dispositivo HID #define USB_EP1_TX_ENABLE USB_ENABLE_BULK //Se habilita EP1(EndPoint1) for IN bulk transfers #define USB_EP1_RX_ENABLE USB_ENABLE_BULK //Se habilita EP1(EndPoint1) for OUT bulk transfers #define USB_EP1_TX_SIZE 3 //Memoria a reservar para el endpoint tx (Inpipe) #define USB_EP1_RX_SIZE 3 //Memoria a reservar para el endpoint rx (Outpipe) #include <pic18_usb.h> //Carga de las librerias USB. #include <usb_desc_scope_alt.h> //Carga el header con las definiciones. #include <usb.c> char sine_wave[3]={1, 2, 3}; #define mode usb_indata[0] void main(void) { int8 usb_indata[3]; //declaramos variables usb_init(); //Se inicializa USB y espera que sea enumerado por la PC usb_task(); usb_wait_for_enumeration(); while (TRUE) //Ciclo principal { if(usb_enumerated()) //Si el PIC ha sido enumerado por la PC { if (usb_kbhit(1)) //y si hay un dato en el buffer de entrada USB. { usb_get_packet(1, usb_indata, 3); //Leemos el paquete de 3 bytes que hay en el OutPipe //(Leemos de la PC) if ((usb_indata[0] == 1)&&(usb_indata[1] == 0)&&(usb_indata[2] == 0)) //Si el primer byte (modo) es cero { //entonces lee los ADC's y envia //los datos (4 bytes usb_puts(1,sine_wave,3,50); //Colocamos los 4 bytes en el InPipe.(Enviamos a la PC) sine_wave[0]=2; } } } } } Consegui fazer o labview enviar um pacote, o PIC entender e devolver um outro pacote. O que são os números 1 na primeira, e 1-50 na sgunda função? usb_get_packet(1, usb_indata, 3); usb_puts(1,sine_wave,3,50) Uma dúvida, entre o VCC e o GND do USB você coloca algum capacitor? Valeu cara!

Valeu Mateus, o maior problema meu é montar a interface mesmo... Vou focar em uma e mandar ver, vou continuar com o Labview que tenho um pouco de experiencia... Valeu cara. **** EDIT. Se alguém estiver na mesma busca que eu: http://www.edaboard.com/thread113553.html Um ponta pé inicial!

Matheus... Cara... Te perguntar, você tem algum exemplo de código para o USB HID? E alguns para montar a interface usando o C#? Ele é gratuito né? A licença do LABView é o olho da cara @#$%@%$!!!

HEhHEhehEhE, eu apanhei bastante e não aprendi... ¬¬" Muito bom Matheus, também estou aguardando o restante do projeto!

AlyssonMachado, caraca... Você desenvolveu a biblioteca? Parabéns ai amigo!!!!!!!!!!!!! Quando fui montar no protoboard para testar deu muita zebra até funcionar, porém, quando montei na placa (fiz uma pequena plaquinha) nunca deu zebra, está funcionando até hoje com a bateria e nem atrasou, já faz 4 mêses... Segue o link do código feito no CCS, e do esquema para simulação no proteus: http://www.easy-share.com/1911330587/RTC_ds1307_PIC_PROTEUS_CCS.rar Dica: Meu PC é bem velhinho (parceiro de guerra =}), então quando vou fazer simulações no proteus eu vou em System > Set animations options e desmarco a opção Show logic state of pins... Quando não faço isso, o RTC fica locão e mostra 455:115:100 para hora =D'... - Quando o PIC é ligado sem utilizar o comando ds1307_set_date_time o valor exibido é "00:00:00". Ligue o PIC, depois desligue e grave ele sem o comandos ds1307_init() e ds1307_set_date_time, e então ligue ele de novo... Só usei esses comandos para configurar a hora na primeira vez, depois não o usei mais

Valeu paulao hawk!!!