Jump to content

Reynard

EstablishedMember
  • Content Count

    688
  • Joined

  • Last visited

Everything posted by Reynard

  1. 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
  2. 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
  3. 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
  4. 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
  5. Looking further, I am not convinced that any of the strnxxx() functions exist in the large library ! Cheers Reynard
  6. Hi Tom, A silly question but did you include the <string.h> header ? Cheers Reynard
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. Are you linking in the large pic18 library from the lib-large directory. Cheers Reynard
  23. 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
  24. 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
  25. 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
×
×
  • Create New...