Jump to content

Ettore

EstablishedMember
  • Content Count

    28
  • Joined

  • Last visited

Everything posted by Ettore

  1. I think no one is moaning about the SB quality. I for one have advised SB to many forum customers of the Company I work for. However this distracts about the real question of the thread: is or not SB dead ? The missing direct support from SB creators would suggest just it is. And if so then I'm not entirely sure is XC8 the reason why! I think the forum Administrators should shed some light on; and publicly not by e-mail! Just as new potential customers should be aware whether or not SB is in good shape.
  2. For other simulators I'm not sure of but for Labcenter Proteus VSM it's entirely not true. The Microchip read-modify-write mechanism is fully modeled in Proteus VSM such that if you have pins that share analog features and you cannot disable them then you will get 0 readings for that pin when you implement bit operations. Also, when you implement bit operations you'll get a pin state that also depends by the input logical states exactly as in the reality. Even the electrical noise falls in this category; it (the noise) may always be simulated by a digital pattern generator connected to the re
  3. I have found in your code a number of small problems. I'm not sure whether these do affect on the simulator but certainly they do on the real hardware. 1) The following pragma line is wrong: 'System Config2 W_PROT_OFF, PLLX4_DISABLE,STAK_OVF_RESET #pragma DATA _CONFIG2, _WRT_OFF & _PLLEN_OFF, _STVREN_ON You should remove the comma before _STVREN_ON and replace it with & (ampersand). In different words it becomes: 'System Config2 W_PROT_OFF, PLLX4_DISABLE,STAK_OVF_RESET #pragma DATA _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_ON 2) Enabling th
  4. The CLOCK_FREQ pragma change only affects the software delay routines. Timers shouldn't get effected by those change, though. The blink period will only depend by the prescaler - 1:8 with your setting - and FOSC. You should get a TMR1IF overflow every TCY*8*65536 i.e. 524ms @ FOSC=4MHz which is exactly what I did. I'm not sure why you didn't get the correct time with delay_ms. Perhaps your XTAL is not oscillating to the correct frequency value ? Try _HS_OSC rather than _XT_OSC as a config bit set.
  5. I think is because of the analog input AN4 multiplexed with digital I/O pin RC0. Analog features are enabled by default and disable the digital input buffer that reads '0's as a result. Adding the line: ansel = 0b11001111; at the start of your program will disable AN4 and AN5 and you get full I/O features for RC<1:0> and, at the end of the day, the led will flash under timer control. As an aside, the CLOCK_FREQ pragma is the FOSC not the TCY (FOSC/4) frequency!
  6. That's why .casm file is for ! .casm file should be there in your project folder along with .asm and lst files.
  7. The pins RB<0:5> are set as analog inputs by default and - as datasheet clearly states - "setting a pin to an analog input automatically disables the digital input circuitry, weak pull-ups, and interrupt-on-change if available". So, you need to add the line anselh = 0; at the begin of your program; this disables analog features and enables all the pins for digital I/O. Hope it helps.
  8. Dave Do latest target files still work in version 6.97 ? Regards Ettore
  9. So, I knew I was forgetting the last step ... You need to add the following lines in the file BoostCPic18.h #ifdef _PIC18F67K22 #include <PIC18F67K22.h> #endif // _PIC18F67K22 This will include the right header file when you add #include system.h at the beginning of your code.
  10. Let I give you some hints about the first part of your question. You essentially need to create the header file of the new device - PIC18F67K22.h in this case - by editing the header of the closest existing device in the subfolder /include. Then you have to create what SB guys call a 'Target description file'. Those text files have the extension .TDF and you find them into the subfolder \config. Again, you don't have to start from scratch: you will get the new TDF file by editing the existing one which is closest to new variant you need the support for. Note that if you don't use the
  11. Another fully Arduino's shields compatible board which is wortwhile to have a look at: http://www.myamicus.co.uk/
  12. The following aliases are not defined into the PIC16F1933.h include file. Just FYI. volatile char tmr4 @TMR4; volatile char pr4 @PR4; volatile char t4con @T4CON; volatile char tmr6 @TMR6; volatile char pr6 @PR6; volatile char t6con @T6CON;
  13. V6.97 Beta 2 Release. It looks as though the configuration words addresses for the PIC16F19xx targets are still @ 2007h and 2008h rather than 8007h and 8008h. Regards.
  14. graham, Yes indeed, the problem is related to read-modify-write mechanism and analogue features enabled by default as well. If you add 'ansel = 0b00001111;' prior the set_bit() instructions then you disable analogue features for those pins and no delay should be required anymore.
  15. Yes, the issue has started around 6.9. Look at the following code; the strings should be sent until end of string - NULL - is found. However the conditional statement if (tx_buf1[tx_index1]) is evaluated always as true. You need if (tx_buf1[tx_index1] != 0) in order for the statement to work as intended. The latest 6.93 has left the issue unfixed. // test for PIC18F6722 USARTs #include <system.h> #pragma DATA _CONFIG1H, _OSC_INTIO67_1H #pragma DATA _CONFIG2L, _PWRT_ON_2L #pragma DATA _CONFIG3H, _MCLRE_ON_3H #pragma DATA _CONFIG4L, _XINST_OFF_4L #pragma CLOCK_FREQ 20000000
  16. If we are still talking of pic16f88 then Fosc2 is not the bit2 but the bit4 of the config1 and the bit2 is WDTEN bit. So whether you set 100 as the last three bits you are enabling watchdog and not INTRC. From the datasheet the config1 bits are reported as the following progression: CP|CCPMX|RESV|WRT1|WRT0|CPD|LVP|BOREN|MCLRE|FOSC2|PWRTEN|WDTEN|FOSC1|FOSC0 That's good demonstration that 'text' approach in header file is much better than bit approach
  17. You've got the watchdog and LP oscillator enabled. Is that what you want ? #pragma DATA 0x2007, 0b11111101000100 ^ ^
  18. Yes you are right, but if then you look into that header file you won't find any definition for __CONFIG. Perhaps it was a predefined macro in the old compiler but it seems not to work with BoostC in all the cases. Just for the record and because you were asking, the generic syntax of #pragma data is: #pragma DATA addr, data then the lines: #pragma DATA _CONFIG1, _WDT_OFF & _INTRC_IO #pragma DATA _CONFIG1, 0b11111111111000 #pragma DATA 0x2007, 0b11111111111000 should all be equivalent.
  19. Hello Raghunathan, I don't think you should desist to help people if you just like it. In a world where we must pay for everythings we need for then you may likely expect of being misunderstood sometimes. At any rate, you say that your UTM (is that machine for fatigue analysis ?) utilises the good old ICL7135 which I know very well, though a little dated dual-slope ADC. Having me developed a simulation virtual model of this ADC for the company I work with, I'd like to test my model with module drivers that you've developed at your end. I may surely make them for myself but if your dri
  20. Raghunathan, The register OSCON defaults with all '0's and whether not programmed the bits SCS<1:0> are set both to '0's, thereby the oscillator mode is defined by Fosc bits in the configuration word. The problem is just the configuration pragmas, nothing else.
  21. I'm not sure where __CONFIG comes from but correct pragmas should be: #pragma DATA _CONFIG1, _CP_OFF & _CCP1_RB0 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_ON & _MCLR_OFF & _PWRTE_ON & _WDT_OFF & _INTRC_IO #pragma DATA _CONFIG2, _IESO_OFF & _FCMEN_OFF Your pic does not actually work just because your pragmas are not accepted, so the pic switches on external clock by default.
  22. You may have a look here : http://botzilla.free.fr/node10.html. Then if you google with "PIC I2C slave" you should find out many ideas, including a Microchip application note AN734. Regards
  23. René, You need to initialize cmcon = 0x07; this makes GP1 available as a digital input. Regards
  24. OrmatEli, A constant variable is a 'read only' object which is somewhat of different than an integral constant-expression label. For example, while the following will be perfectly accepted: #define SIZE = 10; int array[SIZE]; the next one will not: const in SIZE = 10; int array[SIZE]; The ANSI standards state that integral constant label must be used for case label value. For example with several ANSI C compilers, the code: const int a = 1; const int b = 2; const int c = 3; switch (a) { case b: do_something; break; case c: do_somethingelse;
  25. on the first case statement. Even when I add braces to that statement the error doesn't go away. <{POST_SNAPBACK}> You should use constant-expressions rather than constant variables within the switch instruction. So, if I were you then I'd replace the construct: const char ADcap0 = 0b00000001; const char ADcap1 = 0b00000101; const char ADcap2 = 0b00001001; with: #define ADcap0 0b00000001 #define ADcap1 0b00000101 #define ADcap2 0b00001001 Should you need variables, then a more elegant way is to use 'if' and 'else if' rather than the use
×
×
  • Create New...