Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About schneiderj

  • Rank
  1. Hello, I am using that library with success from the beginning I boot Boostc compiler. I would like to use USB connection of the PIC family and following Dave's suggestion I will use the Library from Ian Harris. To begin I first would like to have the functionality I had on my 18F4520 working. One is the LCD display. I wrote a small part of code to test it... but the LCD is not initialized (using the USB demo card from Microchip). Turning around issue did not improve the situation. To try to see where is the problem coming I mount a new demo system where I can rapidly replace the 18F4550 by 18F4520 and vice versa. My code and hardware are working properly with the 18F4520, but not with 18F4550. I have a led on RB0, and this one is flashing with the two processor and by the way I know that the PIC program is OK. But not the LCD part for the 4550. Here is the code of lcd_Driver initialization into the main file : // Add the following after #include <system.h> in you source file: // #define LCD_ARGS 2, /* Interface type: mode 0 = 8bit, 1 = 4bit(low nibble), 2 = 4bit(upper nibble) */ \ 0, /* Use busy signal: 1 = use busy, 0 = use time delays */\ PORTB, TRISB, /* Data port and data port tris register */ \ PORTC, TRISC, /* Control port and control port tris register */ \ 4, /* Bit number of control port is connected to RS */ \ 6, /* Bit number of control port is connected to RW */ \ 7 /* Bit number of control port is connected to Enable */ #include "lcd_driver.h" I suspect that not the issue, not such. What is your opinion ? A second question : can the config bits have influence on this part of application ? Thanks you for your help, Jena-Marie
  2. Hello Dave, thanks you for your reply. I will beginn with that library first and will give you some feedback latter (more than one month, not yet). Jean-Marie
  3. Hello, I would like to test USB feature of the 18F4550 and would like to use example from Microchip written in C18. But as I would like to continue to use BoostC, I would like to know If some one as already try to translate the C18 code to BoostC ? Is that a lot of work ? Thanks you for your reply, Jean-Marie
  4. Hi Reynard, I found some problem in my code and it seams that better results are obtained. But after I2C working properly for few minutes, I obtaine a NACK (after the slave has been asked and had answered more than 50 times (for each, receiving one byte and latter sending 4 bytes). You can see the sequence in the picture : - the first pulse is master sending a byte to the slave to tell it that he must prepare data's to send - the second the the slave sending the data's - the third is two in fact : communication with an A2D (ADS1100) and then writing the 6 bytes to an eeprom. Then the cycle roll-over. But on the third cycle of the picture the address is not received by slave and a NACK is put. The SCL is set low and never return to an hight state. I presume that come from the slave which was not ready to read this new request, but why ? Is that coming from the SSP module which was not free and how can I know origin of this trouble ? Or other thing ? Thanks you for your comments, Jean-Marie
  5. OK, I begin (or expecting) to understand : the last read operation should be completed by setting ACKDT bit. Is that correct ? But in that situation how can I know that the master as correctly received the last byte ? Jean-Marie Edit : I modify my code and set AKDT after the last write operation. SDA return to the "normal state". Many tanks !
  6. Reynard, After the read section I send a stop : code is as follow : void ConnexionJulabo_Read(unsigned char Temperature[]) { unsigned char Adresse[1]; Adresse[0] = 0b10011001; // adresse en mode écriture I2Cjms_Initialise(); I2CjmsWrite(Adresse, 1); Temperature[0] = I2CjmsReadSimple(); Temperature[1] = I2CjmsReadSimple(); Temperature[2] = I2CjmsReadSimple(); Temperature[3] = I2CjmsReadSimple(); I2Cjms_Stop(); } void I2Cjms_Stop() { b_SSPIF = 0; b_PEN = 1; // send a stop while ((b_ACKSTAT != 0) & (b_SSPIF == 0)) { Start_Flag = 0; } b_SSPIF = 0; b_SSPEN = 0; // disable the SSP module } I use the same stop function after write action and in that case the STOP bit is send. The logic analyser I am using is very nice and not expensive (not to expensive). You can found information here : Intronix logicport Jean-Marie
  7. Thanks Reynard. But that did not solve my problem. Some news : I use the the asm file for 18F of the AN734, compile it and programme the 18F4520. Then from the master I send a write order for 4 bytes and a read order of 4 bytes also. I obtain exactly the same behaviour than with my own C code : after the read operation the SDA remain low. The first part of the picture correspond to the write operation. The second is the read one : After this if I perform a new write operation from the master, the master ramin in the initialisation function, which same normal as the SDA is low. If I reset the slave before performing this second write operation, the master work fine. So my slave procedure or the AN736 procedure give the same result : said the SDA line remain low after the read operation. And as a reset of the slave allow the SDA to be hight again I think the problem is coming from the slave. If that supposition correct ? If yes what is the problem ?
  8. Thanks for your replies. RSABear I saw your code, but I found it difficult to read. Thanks Reynard, I made confusion with BF. Now the code is : if((b_S == 1) & (b_DA == 0) & (b_RW == 1)) // & (b_BF == 1)) { unsigned char i = sspbuf; while(b_BF== 1); sspbuf = I2C_Donnee[Compteur]; do { // Yes - Write data again clear_bit( sspcon1, WCOL); // Done waiting, clear the WCOL flag sspbuf = I2C_Donnee[Compteur]; // Write the data to the SSP Buffer register } while ( test_bit(sspcon1, WCOL) == 1); b_CKP = 1; b_SSPIF = 0; Compteur++; return 0; } // Read operation, last byte is a data byte if((b_S == 1) & (b_DA == 1) & (b_RW == 1)) // & (b_BF == 0)) { while(b_BF == 1); sspbuf = I2C_Donnee[Compteur]; do { // Yes - Write data again clear_bit( sspcon1, WCOL); // Done waiting, clear the WCOL flag sspbuf = I2C_Donnee[Compteur]; // Write the data to the SSP Buffer register } while ( test_bit(sspcon1, WCOL) == 1); b_CKP = 1; b_SSPIF = 0; Compteur++; return 0; } But every thinks is not working correctly : after living the if statement the SDA remain at level 0. And I see that BF bit is set. But I don't why. Jean-Marie
  9. Hello, I have wrote a function to have a 18F4520 working as an I2C slaves. The write procedure work fine (at least till now). But the read one let me craze ! In the application note AN734 for state 3 it is explained for new 18F and asm code is : ; State 3: I2C read operation, last byte was an address byte ; SSPSTAT bits: S = 1, D_A = 0, R_W = 1 (see Appendix C for more information) SSP_Handler movf SSPSTAT,W; Get the value of SSPSTAT andlw b'00101101'; Mask out unimportant bits in SSPSTAT. movwf Temp; for comparision checking. State3: movf Temp,W; andlw b'00101100'; Mask BF bit in SSPSTAT xorlw b'00001100' btfss STATUS,Z; Are we in State3? goto State4; No, check for next state..... movf SSPBUF,W clrf Index; Clear the buffer index. load RXBuffer,Index ; Point to the buffer movf INDF0,W; Get the byte from buffer. call WriteI2C; Write the byte to SSPBUF incf Index,F; Increment the buffer index. return I have difficulties to understand the following lines : movf SSPBUF,W --- SSPBUF is loaded into the working buffer load RXBuffer,Index ; Point to the buffer movf INDF0,W ; Get the byte from buffer. -------- First data we wants to send to the master is loaded into the working buffer call WriteI2C ; Write the byte to SSPBUF Then we went to WriteI2C : WriteI2C btfsc SSPSTAT,BF ; Is the buffer full? goto WriteI2C ; Yes, keep waiting. DoI2CWrite bcf SSPCON1,WCOL ; Clear the WCOL flag. movwf SSPBUF ; Write the byte in WREG btfsc SSPCON1,WCOL ; Was there a write collision? goto DoI2CWrite return I wrote my code as follow, but the b_S is never cleared. What is wrong in my interpretation ? if((b_S == 1) & (b_DA == 0) & (b_RW == 1)) // & (b_BF == 1)) { unsigned char i = 0; i = sspbuf; while(b_S == 1); do { // Yes - Write data again clear_bit( sspcon1, WCOL); // Done waiting, clear the WCOL flag sspbuf = 145; // Write the data to the SSP Buffer register } while ( test_bit(sspcon1, WCOL) == 1); b_CKP = 1; b_SSPIF = 0; return 0; } Thanks you for your help, Jean-Marie
  10. Hi Pavel, I will try your new driver this week end if I find some free time, with application I am currently developing. Jean-Marie
  11. Hello ! Me again... I have write my own driver for EUSART communication. And with it I did not have the problem I had with the Boostc driver. Hop that can help some one else. Jean-Marie
  12. Sorry to come back with this, but I am unable to find an issue. If synchronization loss is the probleme how can I verify that correctly ? Any idea to help me ? Jean-Marie
  13. Hello Dave. That works also with my installation. Thanks for your help, Jean-Marie
  14. Hello Reynard, You are write. In fact I use the Boostc librairy without knowing a lot about its implementation ! That save time, but now I think I have loose time ! In the Boostc library I was unable to find BRG16 nor BAUDCON (RS232_driver.h). I found that : TXSTA = 0xA4, thus BRGH = 1 and SYNC = 0 From the datasheet : From the driver we have : UART_INIT<USART_ARGS>( 1, ((20000000 / (9600 * 16L)) - 1L) ); by the way, if I did not make confusion I have SPBRG = 129. For the moment I could not verify that on the harware, as I am unable to linke my project with MPLAB. I will let you know, Jean-Marie
  • Create New...