Jump to content

Remi Sans Famille

  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Remi Sans Famille

  • Rank
  • Birthday 09/01/1951

Profile Information

  • Gender
  • Location
    Amsterdam, Netherlands
  • Interests
    Robotics, hydrofoils & sailboats
  1. I2C Basics

    Amsterdam, 6th dec 2013/7th dec 2013 Hello Mityeltu, In my opinion we live in a 8-bit hexadecimal world. So why bothering about confusing 7 bits addresses which have to be converted to 8 bits by shifting every time? I think it's easier to consider the slave as having one constant (unchangeable) WriteToSlaveAddress (even) and one constant ReadFromSlaveAddress (odd, namely WriteToSlaveAddress + 1). So two addresses of 8 bits each. A useful document that could help would be: http://www.robot-electronics.co.uk/acatalog/I2C_Tutorial.html Another absolute must is the AN734.pdf of Microchip available at: https://www.engr.usask.ca/classes/CME/331/AN734.pdf especially the states on page 5. The third (variable) address of the slave would be the place (register) from which you will read from or write to firstly. However, some devices send back their ReadFromSlaveAddress as a bonus firstly after which follows the data. Somehow you should try knowing what is happening inside your master-controller. My humble method is outputting data and/or values of registers and/or remarks like my own invented error-messages, to the serial port TX after which comes a MAX232 IC that converts and reverses the 5 Volt TTL level to -10 .. +10 Volt RS232 level after which comes the input of the serial port of a PC that runs a simple Pascal or C program that displays anything in a readable shape on a monitor. A master could be, indeed, the 16F877 and a slave (if you want to build one) could be the 16F88. I think that the last one is not very appropriate as a master (in a convenient language like Sourceboost C) unless you like bit-banging. Hopefully you have an oscilloscope, I2C can be hard. Regards, Remi
  2. 18F4680 Some Strange Things

    Come Awa ' In Well Reynard, thanks a lot!! Like you wrote, it appeared to be the _CONFIG4L extended enable instruction. I will now meticulously go into the configuration bits. I want to know all about it, it's the base. What I tried before, was skipping /* commenting out */ that special line, but strangely(!) enough the controller seems to remember previous settings. The Velleman VM134 programmer has the option to erase the PIC firstly. There are a lot of variables to set and variable methods, when combined make a lot of different ways. But for me the main reassurance is that the sourceboost compiler is OK. Which is my best Santa Claus (in Holland 5 December) present ever. Again thanks, Remi
  3. 18F4680 Some Strange Things

    Hi Dave, It is very silent round my little problem. I have been experimenting a lot because I thought that my configuration bits were not OK. But I have not been able to detect faults in my program yet. Hopefully you will find the time to have another look at it and perhaps inform me what I have to alter to make it working. Helas the 16F877 is to small for my purpose, that's why I bought several 18F4680's which are still unused. Please help. Sincerely, Remi
  4. 18F4680 Some Strange Things

    Corrigendum: "]" added at line: SerialMessageToPC("]\n\r"); //on screen PC: "ab+d++++]" instead of: "abcd++++]" Hello Dave, thank you for your interest. I stripped as much as I could from the program but not things from which I think they can cause problems. Nevertheless there are 92 lines. The "rubbish" my program produces is old information which has been left in the controller. Here you go: #include <system.h> // stripped version, controller=18F4680, from Remi Sans Famille. #define slaveCMPS10_ADRES_0xC0 0xC0 #define slaveLCD_ADDRESS_0x50 0x50 #define slaveGPS_ADDRESS_0x40 0x40 #define MasterInputSize_43 43 #define LcdSize_32 32 #pragma CLOCK_FREQ 20000000 #pragma DATA _CONFIG1H, 0b11000010 #pragma DATA _CONFIG2L, 0b00011111 #pragma DATA _CONFIG2H, 0b00011111 #pragma DATA _CONFIG3H, 0b10000100 #pragma DATA _CONFIG4L, 0b11000101 #pragma DATA _CONFIG5L, 0b00001111 #pragma DATA _CONFIG5H, 0b11000000 #pragma DATA _CONFIG6L, 0b00001111 #pragma DATA _CONFIG6H, 0b11100000 #pragma DATA _CONFIG7L, 0b00001111 #pragma DATA _CONFIG7H, 0b01000000 #pragma DATA WDTCON, 0b00000001 //----------------------------------------------------------------------------------------------- const char HexSigns[] = "0123456789ABCDEF"; const char CompassText[] = "< van kompas >"; const char GPSText[] = "< van GPS >"; char LcdBuffer32[LcdSize_32 + 1] = "++++++++++++++++++++++++++++++++"; unsigned char ReceivedByte = 0; unsigned char MasterInputBuffer[MasterInputSize_43 + 1]; //----------------------------------------------------------------------------------------------- void initialise(void) { trisb = 0b11111101; spbrg = 129; //baud rate generator register, 129 -> 9600 baud at 20 Mhz txsta = 0b00100100; rcsta = 0b10010000; pie1 = 0b00101000; t1con = 0b00010001; intcon = 0b11000000; sspcon1 = 0b00111000; } //----------------------------------------------------------------------------------------------- void interrupt(void) { if (test_bit(pir1,RCIF)) ReceivedByte = rcreg; //clear flag if (test_bit(pir1,SSPIF)) clear_bit(pir1,SSPIF); //clear flag if (test_bit(pir2,BCLIF)) clear_bit(pir2,BCLIF); //clear flag } //----------------------------------------------------------------------------------------------- void SerialMessageToPC(char *p) //9600 Bd, PC displays the message { while (*p != '\0') { while (!test_bit(pir1,4)); txreg = *p; //send to max232, text will displayed by PC p++; } while (!test_bit(pir1,4)); } //----------------------------------------------------------------------------------------------- void AskCMPS10Compass(void) { unsigned char i; for (i = 0; i < LcdSize_32; i++) { LcdBuffer32 = '+'; } i = 0; LcdBuffer32 = 'a'; i = 1; LcdBuffer32 = 'b'; LcdBuffer32[2] = 'c'; /* [2] !! */ i = 3; LcdBuffer32 = 'd'; i = 8; LcdBuffer32 = '\0'; SerialMessageToPC(LcdBuffer32); SerialMessageToPC("]\n\r"); //on screen PC: "ab+d++++]" instead of: "abcd++++]" } //----------------------------------------------------------------------------------------------- void main(void) { const char Hopla[] = "Hopla"; initialise(); while (1) { AskCMPS10Compass(); delay_ms(255); SerialMessageToPC(HexSigns); SerialMessageToPC("\n\r"); // rubbish on screen SerialMessageToPC(CompassText); SerialMessageToPC("\n\r"); // rubbish on screen SerialMessageToPC(GPSText); SerialMessageToPC("\n\r"); // rubbish on screen SerialMessageToPC(Hopla); SerialMessageToPC("\n\r"); // rubbish on screen delay_ms(255); delay_ms(255); portb.1 ^= 1; //heartbeat, LED is connected, works fine } } //----------------------------------- the end ----------------------------------------------------
  5. corrigendum: 16F887 should be 16F877, line 5 Hi guys, I found some irregularities which I cannot explain. Perhaps it's the programmer (Velleman VM134=K8076) that I bought because I have to wait for the second EBlock 006, already ordered. The old EB006 also gave problems with the 18F4680. What happened? I had no difficulties at all programming a 16F877. But when I loaded the same program (mutatis mutandis) in a 18F4680 some strange things happen. Example A. It doesn't like if arrays are addressed directly. For instance: LcdBuffer[5] = 'A'; has no effect at all. I have to use a variable, so: char i; i = 5; LcdBuffer = 'A'; Which is understood. Example B. If I declare three const arrays of char then the order seems to be important. const char HexSigns[] = "0123456789ABCDEF"; const char CompasText[] = "From compas"; const char GPSText[] = "From GPS"; produces nonsense with HexSigns. I have to do it like: const char CompasText[] = "From compas"; const char GPSText[] = "From GPS"; const char HexSigns[] = "0123456789ABCDEF"; Same lines, different order. I tried both examples out several times because I searched the fault in my own program of course. Perhaps it's the compiler, but I am not sure about that. I suppose that there are complications when indexing. Hopefully the EB006 arrives soon. What can it be? Remi
  6. Sourceboost Ide License Not Valid ?

    Quoting Pavel: "By 'impossible' do you mean that the name and key fields become grayed out. That's how it is supposed to work. Just press the OK button and this will show another form to enter your IDE license name and key." I hardly believed my eyes but this works! So simple. Grayed out. That's the expression. Thanks a lot for your very quick reaction !! Regards, Remi
  7. Sourceboost Ide License Not Valid ?

    I also tried the solution with the "Default Lite Key" and key: "0D7D-A279-549A-DD9B-6CB0-1709-E31A-1276-C085-7220-5A41" but it doesn't work. There are some things I don't understand: My license says: BoostC Full for PICmicro v6.xx & V7.xx Activation Name: Farn .... Key: 00000G-TA9... The version is 6.60 I was glad that there is a 7.20 update which may work even better. Having installed 7.20, it is impossible in the radio-box of preg.exe to choose "SourceBoost IDE". It is however possible to choose "BoostC compiler" but after typing in my own key this results in: "Your SourceBoost IDE license is not valid for this SourceBoost IDE version". Or: "Invalid name or key (not registered)" Pavel advised me to try the above mentioned "Default Lite Key" ("0D7D-A279-54...") but that doesn't work either, perhaps because I don't have a Lite Version but instead the Full Version. For me it's OK to have the old IDE (6.60) and only the new (7.70) BoostC compiler, but perhaps it's more complicated than I think. Which magician knows the magic words to let this work? Regards, Remi