Jump to content

schneiderj

EstablishedMember
  • Content Count

    76
  • Joined

  • Last visited

Everything posted by schneiderj

  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
  15. Which version of MPLAB are you using? This is an internal error, so you should never get to see it. The only thing I can think of is the the order of linkage is different between MPLAB and SourceBoost IDE, but even so this message should never appear. Please send all the project files to support@sourceboost.com so we can take a look. Regards Dave Dave thanks you for your answer. I send you the project. MPLAB version is 8.43.00.00 Jean-Marie
  16. Hello, I have a new computer and I try to compile the project I am working on (in MPLAB ide). Compilation was OK, but during the next step it was not successful, and I have the following info in the build windows : And a windows tell me "failed to load PousseSeringue.cof". I found a message on this forum but it is quit old and had no relation with my situation (http://forum.sourceboost.com/index.php?s=&...post&p=7638) : I have no information in the "project:Directories). I perform compîlation in the sourceboost IDE, it works fine ! NB : I have installed the last v
  17. Thanks for your suggestion. I am using external oscillator with the following reference : http://fr.farnell.com/jsp/search/productde...amp;Ntt=1611820 I think that a quit good reference for what I am doing. What did you thinks ? Jean-Marie
  18. I am continuing to try to find where is the problem coming. By disabling the glitches option, I till have the same value in the LogicAnalyseur. I take a look with the oscilo with sampling at 125 k. The baud rate is found at almost 9600 in the two directions. Now instead from the PC I send the string "03 REMOTE STOP". Pic read "03 REMOOE STOP" If I send : UUUUUUUUUUUUU read UUUUUUUUUUUUU 11111111111111 read 11111111111111 03 R111TE STOP read 03 R1111E STOP 0123456789 read 0123456689 All the time it is the character eight which take the value of the seven on
  19. I think that I found the problem : I have modfied the declaration of ReponseValide and the code as follow : char* ReponseValide; ReponseValide = strstr( Reponse, ReponseAttendue); I had no more problem with that code. Jean-Marie
  20. Hello, Following my message about usart problem, I test the communication between my PC and the PIC instead to have the real situation. Depanding of what I am doing I obtain various results. The code : while(ConnexionRS232) { strcpy(Commande, "status"); // determiune si le Cryostat est commande par RS232 // 02 correspond à REMOTE START // 03 correspond à REMOTE STOP strcpy(Reponse, RS232liaison(Commande)); delay_ms(500); strcpy(ReponseAttendue, "03"); strcpy(ReponseValide, strstr( ReponseAttendue, Reponse)); strcpy(ReponseAttendue, "02"); strcat(ReponseValide, strs
  21. Hello, I am surprise that you code compile : where is the line #include "rs232_driver.h" ?
  22. Thanks reynard for your answer. I try other interpreter combination : http://schneiderj.net/Electronique/Images/...%208%20bits.JPG http://schneiderj.net/Electronique/Images/...20interpret.JPG And only 8 bits with no parity or 7 bits with taking no care of parity interpret correctly the message. 7 bits and odd give locks like what I observe with MPLAB during debugging. I did not take care of the first non printable character : it is the software control byte. I use the character <CR> to determine the end of the message. The next one is not considered. Jean-Marie
  23. Hello again, I have found the documentation of the cryostat I am using. The RS232 parameter are : baud rate : 9600 (could be modified) Parity : even (could be modified) Handshake hardware (could be software) data bits 7 (could not modified) stop bit : 1 (could not modified) And if I understand correctly the 18F4520 data sheet I can only set data bits to 8 or 9. Is there a way to solve that issue ? Jean-Marie
  24. Thanks Dave. Thats could explain de problem. How can I check that accuracy ? With my LogicAnalyser by increasing the sampling rate probably... Jean-Marie Edit : with the data's I have on my computer (sampled at 100 kHz for a 9600 baud rate for the serie connection), I found for the data's send by the PIC 1 char take 1.04 ms 7 char take 7.27 ms For the data's send by the cryostat : 1 char take 1.04 ms 7 char take 7.28 ms
×
×
  • Create New...