Reynard

Not fixed in 7.12 rc1 Cheers Reynard

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

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

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

Hi Jorge, Been there done that. Doesn't work for decrement either. Cheers Reynard

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 gb

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

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

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

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

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

The .tdf files for devices 86K22 and 87K22 are incorrect for the AddressRange parameter. Well spotted.

Been there before Adam. You are not alone. Cheers Reynard

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

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

Thanks Pavel, We all look forward to the 7.11 release to play with over Christmas. Cheers Reynard

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

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 luc

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

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

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

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

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

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

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