Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Reynard

  1. Not fixed in 7.12 rc1 Cheers Reynard
  2. Hi Pavel, Still having problems with this version with variables within a structure. See my previous bug report. #define HOPPER_TIMEOUT 3000 static struct { uint16 timeout; } hop; if (++hop.timeout == HOPPER_TIMEOUT) 1A9E 4A5C INFSNZ gbl_26_hop+D'3', F 1AA0 2A5D INCF gbl_26_hop+D'4', F 1AA2 0EB8 MOVLW 0xB8 1AA4 625C CPFSEQ gbl_26_hop+D'3' 1AA6 D003 BRA label216 1AA8 0E0B MOVLW 0x0B 1AAA 625D CPFSEQ gbl_26_hop+D'4' 1AAC D000 BRA label216 1AAE label216 { } if ((hop.timeout += 1) == HOPPER_TIMEOUT) 1AAE 4A5C INFSNZ gbl_26_hop+D'3', F 1AB0 2A5D INCF gbl_26_hop+D'4', F 1AB2 0EB8 MOVLW 0xB8 1AB4 0101 MOVLB 0x01 1AB6 635D CPFSEQ CompTempVar834, 1 1AB8 D003 BRA label217 1ABA 0E0B MOVLW 0x0B 1ABC 635E CPFSEQ CompTempVar835, 1 1ABE D000 BRA label217 1AC0 label217 { } if ((hop.timeout = hop.timeout + 1) == HOPPER_TIMEOUT) 1AC0 525C MOVF gbl_26_hop+D'3', F 1AC2 525D MOVF gbl_26_hop+D'4', F 1AC4 2A5C INCF gbl_26_hop+D'3', F 1AC6 B4D8 BTFSC STATUS,Z 1AC8 2A5D INCF gbl_26_hop+D'4', F 1ACA 505C MOVF gbl_26_hop+D'3', W 1ACC 6F5F MOVWF CompTempVar836, 1 1ACE 505D MOVF gbl_26_hop+D'4', W 1AD0 6F60 MOVWF CompTempVar837, 1 1AD2 0EB8 MOVLW 0xB8 1AD4 635F CPFSEQ CompTempVar836, 1 1AD6 D016 BRA label219 1AD8 0E0B MOVLW 0x0B 1ADA 6360 CPFSEQ CompTempVar837, 1 1ADC D013 BRA label219 { } Here are three 'if' statements which are supposed to do the same thing, increment a variable and compare. The first version, if (++hop.timeout.... produces good code. The second version, if ((hop.timeout += 1)... compares with unassigned temp variables. The third version, if ((hop.timeout = hop.timeout + 1)... has a couple of extra instructions at the beginning. Cheers Reynard
  3. Hi Adam, You can use integer arithmetic by scaling the pulse width by say a factor of 100. e.g. Period 125, pulse width 25. Gives 2500/125 = 20, shifting 2 dec places gives 0.2 Cheers Reynard
  4. Hi Adam, The direct method would be: intcon.GIE = 0; /* disable interrupts */ ... intcon.GIE = 1; /* ensable interrupts */ You could also use the "clear_bit(intcon, GIE)" and "set_bit(intcon, GIE)" macros. Cheers Reynard
  5. Hi Jorge, Been there done that. Doesn't work for decrement either. Cheers Reynard
  6. I am running a simple circular stack with a head and tail pointer. typedef struct { uint8 type; union { uint8 bits8; uint16 bits16; } size; } EVENT_DATA; #define EVENT_QUEUE_LEN 20 struct { EVENT_DATA queue[EVENT_QUEUE_LEN]; EVENT_DATA *head; EVENT_DATA *tail; } evt; void Event_Init(void) { evt.head = evt.queue; 0D2A 0E00 MOVLW HIGH(gbl_evt+D'0') 0D2C 6E42 MOVWF gbl_evt+D'61' 0D2E 0E05 MOVLW LOW(gbl_evt+D'0') 0D30 6E41 MOVWF gbl_evt+D'60' ++evt.head; 0D32 0E03 MOVLW 0x03 0D34 2605 ADDWF gbl_evt, F evt.head += 1; 0D36 0E03 MOVLW 0x03 0D38 2641 ADDWF gbl_evt+D'60', F 0D3A B0D8 BTFSC STATUS,C 0D3C 2A42 INCF gbl_evt+D'61', F If I use the ++evt.head the head pointer does not get incremented by 1 element length (3 bytes in my case). Using evt.head += 1 all is OK. An element of 1 byte works but not with anything greater. Something to do with the pointer being inside the structure. Cheers Reynard Using 7.11, XP Pro, PIC18F45K22
  7. Interesting you should bring this one up Tom. I have had a problem with the toolbars for some versions now. A problem I have is if I collapes all open applications to the task bar, using the Show Desktop button (XP), then go off and do some web browsing, read a pdf document, then at a later time restore SourceBoost IDE, all the IDE toolbars are stacked vertically and have to be manually repositioned them horizontally. I doesn't alway do this on a restore, but I cannot find sequence of events that causes it. I am convinced time related to how long the IDE has been collapsed. Maybe a related effect. Cheers Reynard
  8. The bug is in the compiler. David earlier has pointed out the problem. The switch should be calling the function menuButtonScan(). The compiler should have picked this one up instead of confusing the linker. Cheers Reynard
  9. Hi Tom, None of the 28 pin devices has a TRISE register so not required for either devices you refer to. The only port E pin on these devices (RE3) is read only. Cheers Reynard
  10. The manual says you can do it these ways: clear_wdt(); 006C 0064 CLRWDT asm CLRWDT 006D 0064 CLRWDT asm { CLRWDT } 006E 0064 CLRWDT All product the same machine code instruction. The prescaler value is set in the config 2H byte and therefore fixed. The watchdog counter increments until it meets the prescaler value then resets the chip. It is the counter that is reset on watchdog clear and sleep not the prescaler. The prescaler is a multiplexor which taps off the counter outputs. Cheers Reynard
  11. Use the function "clear_wdt()" as on page 76 of the manual. The prescaler will retain its value after resetting the watchdog. The counter may get reset. Cheers Reynard
  12. The .tdf files for devices 86K22 and 87K22 are incorrect for the AddressRange parameter. Well spotted.
  13. Been there before Adam. You are not alone. Cheers Reynard
  14. Hi Badejo, Are you operating a secondary clock system to save power when asleep. If so sleep will not occur if certain timers are not enabled correctly. Cheers Reynard
  15. Hi Larry, If the registers are consecutive in memory address, and little endian, try using this to declare 16 bit registers. volatile unsigned int ccpr1_16@CCPR1; Cheers Reynard
  16. Thanks Pavel, We all look forward to the 7.11 release to play with over Christmas. Cheers Reynard
  17. Microchip do some nice serial eeprom chips with 1M erase cycles. They are paged at 16 bytes so you can dump out 16 bytes in the same time as 2 bytes on a PIC. Cheers Reynard
  18. The EEADRH is reset on POR but put it in your code for correctness. It can be difficult for compiler vendors to keep up with all Microchips new devices but they are getting there. This eeprom issue needs to be fixed once and for all to keep user confidence in the product. I have thought about moving eeprom data around the block myself before I hit the 100k mark. To write to eeprom at any power down could mean a long supply hold up time if there is a lot to write. Gone are the good old days of ferrite core memory. Ahhh! The days when computers were also room heaters. Good luck with your project. Cheers Reynard
  19. Hi Jorge, The eeprom libraries are supllied as part of the core system fully compiled. A seasoned programmer like yourself has no problems diving in and getting on with it but a newbie is left flapping in the breeze beating his head off a wall. Whether you buy the lite or pro version you should not need to recompile the libraries before you start. I use Novo in many build versions and as you say is very simple and works well. Cheers Reynard
  20. Hi Jorge, Yes there are several solutions to the problem, the best one is write your own. Not everyone has access to the souce files to do a rebuild. The eeprom functions are supplied in their own libraries. The product should work out of the box without having to rebuild libraries. Cheers Reynard
  21. Hi Pavel, I think you need to give us a working example of using a 16 bit eeprom address. I cannot get it to work using eeprom.pic18.lib The assembly code does not show eeadrh register. I am building for the 18F86K22 which does contain the EEADRH definition. Cheers Reynard
  22. Hi, The source code is only available if you have the full or Pro version of SB. There is a file called goodies.exe which you need to request a key from SB to extract the source code. Maybe SB requires two libraries, one for 8 bit addressing and one for 16 bit addressing devices (PIC18). You can't use function overloading and hope it picks the right one for you as you can pass an 8 bit address to a 16 bit device. At a dozen lines of code for each read and write function just do it yourself. Cheers Reynard
  23. Something odd going on here. The eeprom.c file has conditional compilation depending on whether EEARDH is defined. You can't do this and also create a single library for pic18. Can you ? Cheers Reynard
  24. Hi, Been searching around. I think it was the annoncement of 7.10 that gave me the latest source for eeprom.h in the goodies. I looks like the eeprom.lib may not have been recompiled with the new source. If I cut and paste the eeprom source into my main file I get the expected code using eeadrh. Another good reason to write your own code. You have full control of what is going on. Cheers Reynard
  25. Hi, There was some change for this problem but it may not have yet reached a release version. The source file for eeprom.c may have been given out as a file. Do a quick search of the forum for it. I seem to have it in my goodies directory. Better still write your own and do writes under interrupts. I do it for the 18F26K22 without any problems. Cheers Reynard
  • Create New...