Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Ettore

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