Reynard

Hi Marius, I think the problem lies in the OO library. When reading a bit from the device the code waits 20us after releasing the bus which is outside the spec maximum of 15us. Also the time between reading bits is alot shorter than the minimum 60us per bit. I think you would be better off writing your own code to handle this device. I experimented with an older DS1820 and PIC16F687 and after some tweaking of the OO library source code got a good temperature reading. Cheers Reynard

Hi Marius, Have you tried following the exact sequence shown on page 19 of the DS18S20 manual. It seems you have to send another reset sequence before reading the scratchpad data. Cheers Reynard

Hi Dave, Pavel, Has there been any thought on this redundant code generation when using shifts on longs. 3 years down the line and it is still present in 7.04. void main (void) { unsigned long id; id = id << 8; 0008 6A05 CLRF CompTempVar574 000A 5001 MOVF main_1_id, W 000C 6E06 MOVWF CompTempVar575 000E 5002 MOVF main_1_id+D'1', W 0010 6E07 MOVWF CompTempVar576 0012 5003 MOVF main_1_id+D'2', W 0014 6E04 MOVWF main_1_id+D'3' 0016 5005 MOVF CompTempVar574, W 0018 6E01 MOVWF main_1_id 001A 5006 MOVF CompTempVar575, W 001C 6E02 MOVWF

Hi Tom, I tried all the strnxxx functions and they all came up unresolved. I think Dave and Pavel will have to give us a clue here. Cheers Reynard

Looking further, I am not convinced that any of the strnxxx() functions exist in the large library ! Cheers Reynard

Hi Tom, A silly question but did you include the <string.h> header ? Cheers Reynard

Hi Ted, The last paragraph of this section of the data sheet I suppose says the the correct oscillator mode has to be selected otherwise the PLLEN is forced to 0 and cannot be selected. It's alway how you read the small print that get you. Cheers Reynard

Hi Ted, Just my luck in choosing the intuitive method. Hopefully we will all remember this one and write it down on the data sheet for future reference. Good luck with your project. Cheers Reynard

Just a wee note: I am using a 18F2520 at 32MHz with this configuration: #pragma config OSC = INTIO67 // Internal oscillator block, port function on RA6 and RA7 #pragma config IESO = OFF // Oscillator Switchover mode disabled #pragma config FCMEN = OFF // Fail-Safe Clock Monitor disabled void main() { osccon = 0b01110000; // select 8MHz internal osc. osctune.PLLEN = 1; // enable 4xPLL (Fosc = 32MHz). adcon1 = 0b00001111; // AN0 is adc. which is more or less what you have and I am using Novo as well. Cheers Reynard

Hi Ted, Have you tried changing the SCS bits in the OSCON register to select the internal oscillator block (i.e. set bit 1) I am short of any other ideas. Cheers Reynard

Hi Ted, One small question: Did you set the #pragma to tell the compiler of the new 32Mhz clock so it can recalculate any software timer values ? Cheers Reynard

Hi Ted, It seems like you have not included the Novo library into the workspace. Do a right click on the project in the workspace window and select "Add file(s) to project 'xyz'". Browse to the required directory containing the Novo lib you want to use then select the Open button. This should add the library to your project among the .c source files. The linker should then find the library to resolve the external symbols/funtions. The Wizard would have done this and added the novolib_xxxxx.lib to the project. Cheers Reynard

The PIC18 devices allow access to the stack pointer (stkptr) for read and write. You can also read/write the contents of the stack using the top-of-stack locations. So setjmp is probably possible with this series of devices. PIC16 a little bit harder using software stack system. MicroC impliment setjmp etc. Cheers Reynard

This code will not compile without error therefore cannot be debugged. Registers names should be in lower case e.g. osccon=0x71; The delay_ms(X) must take a unsigned char value (0 - 255) otherwise it will be truncated to 8 bits. Cheers Reynard

Hi Guys, Could it be the internal address space of the PIC is only 16 bits (0000-ffff). Therefore 1e000 cannot exist in the device but only in the hex file. I think the 1e000 is shifted to f000 internally when programming. If you are debugging using MPLAB then you only see the 64k address space therefore the EEPROM must be at f000. Does this sound logical ? Cheers Reynard

Hi Chris, You may want to add some decoupling capacitors to your circuit. A 100nF ceramic at least across the PIC. Linear regulators sometime like some C on the input and output pins to prevent them from singing if on long supply wires. Cheers Reynard

Hi Ian, I don't use Boostbasic but have you tried not capitalizing the interrupt function name ? It may want all lower case and not what the manual indicates. Cheers Reynard

Hi Pavel, As Paul says, the file count is not being updated when files are added to the project (.__c) If I manually edit the file count then all is OK when I reopen the project. On a similar note, the Active Config is not being updated when I switch between Debug/Release. Works on manual edit. In the workspace file (.__w) the Active flag is not being changed when I select Set 'xxx' as active project. With only a single project in the workspace it should be by default the active project. I find that the project and workfiles have their date stamp change but no change of cont

You are not alone here. I too have problems with 7.03. Workspaces not opening up, missing source files. I think I will be dropping back to 7.02. Cheers Reynard

Hi Tom, There will be some propagation delay through the output driver logic. The load capacitance will also affect the rise and fall times of the output signals. Even though the port bits are set to outputs, if you perform bit operations using the port, the PIC will read what it sees on the port pins and not necessarily what you think you have put there previously due the delays above. If your PIC supports the reading of the LAT register then use it, as this will illiminate the reading of the acutual port pins and is unaffected by strange effects that take place beyond the chip p

Hi Tom, This is the standard "Read-Before-Write" Gotcha! You cannot change a single bit on an 8 bit port. What happens is, all 8 bits are read, the bit you want is altered, then all 8 bits are written back to the port. The problem is that you may read a zero from a port that has a one written to by some other means. When the port is written back, the zero you read now resets the one that was there bafore. If the PIC has a latch register then use it instead of the port. When you read the latch you do not get any strange inputs as the latch is output only. If the PIC does not

Are you linking in the large pic18 library from the lib-large directory. Cheers Reynard

Hi Tom, inline functions are a bit like macro's in that they are expanded during compilation therefore they do not exist as a function that the linker can resolve. Declare you inline functions in the source module in which they are used in and do not prototype them in a header file. Cheers Reynard

Hi Mark, Are you using the SB IDE ? If you are, try selecting the large memory model from the Setting/Options menu. This will automatically select idx 2 for the compiler and linker. It will also load the large memory libraries from the lib directory when linking. Cheers Reynard

Hi Tom, Your RAM is fragmented over several pages mixed in with SFRs. Your max will be 96 bytes. Watch out for the last 16 bytes of common RAM which could reduce you to 80 bytes. Large buffers require contiguous memory. Cheers Reynard