Jump to content

Reynard

EstablishedMember
  • Content Count

    688
  • Joined

  • Last visited

Everything posted by Reynard

  1. Hi Guys, It looks like the compiler is turning off optimizing during a "plain" asm block but is not restoring it at the end of the block. Something for the todo list. Cheers Reynard
  2. Hi Guys, Have you tried putting an underscore before the asm ( _asm {...} ). Cheers Reynard
  3. Using a push button means you will get a double interrupt. Push in and release unless you have some code to ignore one of the states. You may also need to add some debouncing for the button. Global interrupt is something that really should never be disabled unless there is a real need to such as powering down. Disabling global interrupt flag does not stop interrupts being latched and you could miss something important by doing so. Could you not just poll the push button. Do you have to go to sleep ? The timer functions are software loops and don't rely on interrupts or timers.
  4. Try reading the port to clear the mismatch condition before clearing the interrupt flag. void interrupt(void) { rotary = porta; // Clear port mismatch intcon.RAIF = 0; //clear interrupt flag start_timer = 1; } Cheers Reynard
  5. Try removing the semi-colon from the #pragma and see if that makes any difference. #pragma CLOCK_FREQ 4000000 The IDE may be using a default if the pragma is not understood. Cheers Reynard
  6. Hi Samith, You have commented out the config data which is not a good idea if you are using a 10MHz crystal. The pragma says you are using 4MHz ? Have you set the ocillator speed in the "Settings/Clock Rate" menu. The compiler needs a clock rate to compute correct delay_us() etc. Putting "val" out to the portb instead of "adcvalue" as David shows is better programming. You code works using a PIC16F873A and 8MHz crystal on my EasyPIC5 board. Cheers Reynard ps. I left the ADC turned ON for my testing.
  7. Hi Samith, Have you tried leaving the ADC turned on all the time. Turning it off before reading the result registers may turn off the latch drivers even though they retain their values. Worth a try. Cheers Reynard
  8. The problem lies in the eeprom.c source file. void eeprom_write(unsigned char address, unsigned char data) ... // eeadrh = address >> 8; Comment out this line. ... Comment out the offending line and remake the library if you have the Goodies stuff. The problem didn't show in my test because I only used eeprom_read() which is OK. To be fixed in the next release no doubt. Cheers Reynard
  9. You don't need it if the PIC doesn't support it.
  10. Hmmmmm. Not so good Alex. You could just define this register and see what part the linker brings in from the eeprom library by looking at the assembly code. I still find the workspace and project file a little flakey at times. Sometime it is best to delete them and rebuild them. My test program project file (.__c) says I have a count=2 but there are 3 files listed (2 of them the eeprom.pic18.lib). Why should that be I ask myself. I wish you luck. Reynard
  11. Hi Alex, There was a problem with something like this a couple of years ago but it was resolved with some additions to the eeprom.h file. Check your eeprom.h file that it does include the conditional test and you have the latest lib files which you should have with V7.05. #ifdef EEADRH I have done a quick test (V7.05.1) using your PIC and eeprom_read(x) and have no problems. Cheers Reynard
  12. Hi Dr. John, SourceBoost is a bit weak with data stored in ROM. I am not sure it should be called an array since you cannot declare it as an array but merely a string if chars. I would like to see it expanded in to retrieving all data types including structures particularly for the PIC18 devices which have large ROM space. Why SourceBoost stores the "string" index in RAM ? I can't see a reason for it at the moment since it seems to be a fixed value starting at 0 and incrementing by 1 each string declaration. Couldn't it just be a constant and save RAM and extra instructions.
  13. Hi Dr John, If you use the method which Dave describes you should only have a single byte allocated in RAM for each array created in ROM. This byte contains an index for the function that retrieves the data from ROM. The map file should only show 8 bits (why bits I won't ask). This map is for 2 different LCD lookup tables: 00000020:00000008 gbl_LCD_segment_config1 LCD_segment_config1 00000021:00000008 gbl_LCD_segment_config2 LCD_segment_config2 Cheers Reynard
  14. Hi drumanart, You need to use the ampersand between the config option. #pragma DATA _CONFIG2H, _WDT_ON_2H & _WDTPS_4_2H // WDTON, prescaler 1/4. Cheers Reynard
  15. ADCON1 = ADCON1 | 0x04; unsigned short int hundreds, tens, units, b, c, e, sel; Register names are lower case. See header file. A short is an int so don't declare it twice. Cheers Reynard David you beat me to it
  16. Hi Dave, The .h file for the 18F44J50 has both OSC and FOSC progmas declared. Mike unfortunately chose the wrong one. There is also no pragma for DEBUG so can't turn it off without playing tricks as Mike had to do. Cheers Reynard
  17. In the SourceBoost config words you may have the DEBUG bit turned on. In the header file 18F44J50.h, the oscillator bits are defined twice, Once as OSC and once as FOSC. Ignore FOSC definitions at the bottom of the file, better still delete them and use only the OSC definitions. CHeers Reynard
  18. Hi Dave, Given the user cannot compile your product without error using the supplied .h and .tdf files, the problem lies with Souceboost. The PIC18F44J50 is part of the PIC18F46J50 family but Sourceboost have decided to use differing names for OSC and FOSC also select names INTOSCO and INTIO67. The info for the 44J50 part is incorrect with the Microchip data book for CONFIG2L (p421). Cheers Reynard
  19. Hi Mike, The problem lies in the PIC18F44J50.tdf file. Find the line TargetConfig OSC and change it to TargetConfig FOSC You may have to use: #pragma config FOSC = INTOSC // Oscillator Selection bits as the .h and .tdf don't match up. Dave will correct this in the next release Cheers Reynard
  20. Hi Randy, Documentation is rather spars. In the IDE I saw the small and large model buttons in the Settings/Options window and got curious to what they did. Good you got things going. Cheers Reynard
  21. Hi Randy, You will be using the large model then. Have you tried getting the library from the Lib\Large directory. Cheers Reynard
  22. Hi Randy, I have no problems using using the rand() function with pic18. Don't include the libc library as the linker will pick it up by itself if you use SourceBoost IDE. Maybe needed for MPLAB. Do you have the full path in the project file to the rand.pic18.lib library. Looks like the linker can't find it. Cheers Reynard
  23. Hi Randy, I think MPLAB requires a word address rather than a byte address. The byte address is twice the word address hence the 1 bit shift to the left. :0200000400F00A :080000000102030405060708D4 The hex line before the EEPROM data specified the offset address for the debugger or programmer. In my case the offset is 0x00F0 for a 18F4580. I am using the MicroElektronika which understands the SourceBoost hex file format and shows the correct data in the EEPROM window. The programmer starts at address 0x0000 for the EEPROM data and the shift to 0x1E000 (in you case) is do
  24. Hi RJS, Does this link help you, it looks similar. http://forum.sourceboost.com/index.php?showtopic=4938&st=0&p=18301&hl=1e000&fromsearch=1&&do=findComment&comment=18301 Cheers Reynard
×
×
  • Create New...