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 1
  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
  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
  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
  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
  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
  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
  • Create New...