Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Picxie

  1. Hi Carolyn, I have requested function pointers too. Looking at the listing file, the function names supplied to the assembler are made of the first ten characters of the name followed by an underscore and 5 hex digits. I am guessing the 5 hex digits are what the compiler uses to keep track of functions rather than their names. The RTOS sounds interesting, I have considered a similar project but time and work gets in the way. Is your RTOS for work, for school/ college or just for the hell of it? It will be interesting to see how you get on.
  2. Noooooooooo! populating the variable from the port is merely mimicing the action of the PIC, but using more instructions to do it, the PIC reads the port into a hidden register, modifies it and than writes it back. What you need to do is mirror the port, ie keep a record in a global var of what you have wriiten out, when you want to modify the output you modify the mirror only and write the mirror to the port, you never read the port into the mirror. Have a look in the spec sheet for your processor, do a search for read modify write, have a look at the output circuitry for a typical port. if you google for read modfy write pic, first hit I got was http://www.piclist.com/techref/readmodwrite.htm
  3. The eeprom is quoted at 1 000 000 program cycles whereas code space is a measly 100 000 cycles, thought microchip qualify each claim as "typical".
  4. But you wouldnt lie awake at night thinking what happens if... Actually it is possible to protect a block of code space using the configs so the danger is less than you think.
  5. You can get a 32Kbit SPI serial eeprom for about £0.60 Microchip (amongst others) make them. see http://www.microchip.com/stellent/idcplg?I..._PAGE&nodeId=80
  6. Just reread your post and another thing springs to mind clearing and setting bits using mathematical functions is not a good idea. Better off using bit logic such as | & and ~. If you want to flip a bit use XOR. eg setting bit 3 portaMirror |= 0x80; clearing portaMirror &= ~0x80; if you used portaMirror += 0x80; fine if bit 3 is clear but if bit 3 is set you will clear bit 3 and carry to the next bit.
  7. Off the top of my head. A function modifier word eg multithread void fun(char param) {} have two/(three pic18) entry and exit points points with seperate context which point to a common body. all local vars accessible by indirection
  8. Yes Its called the read modify write problem. The PIC ports are a little primitive, they have no read back on the outputs. When you change a bit the PIC reads all the pins for that port. modifies the bit and writes it back. What it does NOT do is read the current output state and modify and write back. This can cause unpredictable results eg if a pin was driving into a transistor its output latch may say 1 but because of the drop across the transistor its input pin reads as a 0. This effect occurs with all read modify write eg BCLR XOR AND etc but not MOVF. The cure is to have a mirror of the output port eg char portaMirror; // at init porta = portaMirror; // during run portaMirror |= 0x81; porta = portaMirror; The PIC18s have a latch register ie lata, latb as a cure for this problem.
  9. When optimisation is turned off bank switching is applied to each and every data reference, this breaks the required sequence for the EEPROM write. When optimisation is turned on, bank switch code is only added when there is a change or uncertainty of the bank at any point in the code. The required bank switching is added to all code, even inline assembler. I don't quite think this can be regarded as a bug, its more like a feature of operation. Regards Dave <{POST_SNAPBACK}> A note in the help file regarding what to expect from optimisation would be good.
  10. I've just recompiled with PIC18F2420 as target and still get the correct protected sequence, I cant check it actually runs though as I had to map portd elsewhere in order to get it to compile.
  11. I'm not gettting these movbs, see my post in the other thread http://sourceboost.ipbhost.com/index.php?s...st=0entry7157
  12. Most bizarre!! I have got just got my existing eeprom code working . I am using PIC18F4680 boostc18 version 6.31 This is my C + asm eeadrh = 0; eeadr = address; eedata = writeData; clear_bit(eecon1,EEPGD); // data space not program clear_bit(eecon1,CFGS); // eeprom // enable writing set_bit(eecon1,WREN); intconCopy = intcon; // special protected write sequence clear_bit(intcon,GIE); asm { MOVLW 0x55 MOVWF _eecon2 MOVLW AAh MOVWF _eecon2 BSF _eecon1, WR } intcon = intconCopy; // disable writing clear_bit(eecon1,WREN); NB clearing of WREN immediately and generated asm (for the protected sequence)copied from list file 02AC 9EF2 BCF gbl_intcon,7 02AE 0E55 MOVLW 0x55 02B0 6EA7 MOVWF gbl_eecon2 02B2 0EAA MOVLW 0xAA 02B4 6EA7 MOVWF gbl_eecon2 02B6 82A6 BSF gbl_eecon1,1
  13. This is not mentioned in the help file. And with declaring rom data pointer style rather than array style the assumption I made from the help file is from Pointers Pointers can be used in general way.
  14. mhh could be that your programmer only supports low voltage programming mode(better referred to as single supply programming in PIC18 speak) in which case if the LVP bit in config gets overwritten (cant remember offhand if set or clear) then you cant do much without a 12.5 volt programming. NB PIC18 only allow LVP to be overwriten in 12.5V mode. If you have a friend with a different programmer try to get them to bulk erase for you OR try and get 12.5V to the mclr/Vpp pin during programming
  15. I have not written to eeprom on PIC18 before only PIC16 but I would have said that you were doing it correctly. However after reading the PIC 18 data sheet I'm not sure, there's one of those badly phrased doubts where a simple sentence to clarify would have helped. eg In PIC16 it says... After a write sequence has been initiated, clearing the WREN bit will not affect this write cycle. On this subject PIC 18 says... nothing However looking at the code sample they give it refers to "user code execution" followed by clearing wren. There's also some talk about monitoring the interrupt flag. My guess is they have 'improved' the eeprom and that you cant clear the wren till the write has completed.
  16. Picxie

    Adding To A Pointer

    And because it has higher precedence it gets executed first.
  17. Picxie

    Adding To A Pointer

    * has precedence over +. The first statement gets what pText is pointing to and adds 1 to it.
  18. TMR0 has nothing to do with the watchdog. The watchdog has its own timer and RC oscillator. However as a throwback to the original PICs there is a prescaler which can be assigned to either TMR0 or watchdog timer. If the prescaler is assigned to the watchdog, then TMR0 is fed direct from its assigned source ie either TOCKI or Fosc/4
  19. And theres more Pointer arithmetic works (well compiles) this seems to work (compiles) // move the pointer past 99: while( pMenu[0] != 99 ) pMenu++; // pMenu should = 4 return pMenu[0];
  20. I am really not with it today! correct rom char * TAB = {1,2 ,3}; char get (rom char * ptr) { ... } char c; c = get (TAB); HOWEVER I have had a look at where I am using rom, I am accessing using a table as an array, I've just tried as a pointer and the compiler fails. so inside function get () return ptr[2]; // works return *ptr; // fails
  21. You have to include the system.h to use const. I spent hours trying to figure that one out. Also I think your function should take a pointer to const char. A pointer to char generates a load of asssembler to access a char via the INDF register. A pointer to const char generates a load of assembler to call a hidden function to fetch the char from program space. <{POST_SNAPBACK}> Oh yeah, one other tiny thing I forgot to mention, substitute rom for const!!!!! eg rom char *pMenu rom char MENU[] = {..
  22. You have to include the system.h to use const. I spent hours trying to figure that one out. Also I think your function should take a pointer to const char. A pointer to char generates a load of asssembler to access a char via the INDF register. A pointer to const char generates a load of assembler to call a hidden function to fetch the char from program space.
  23. Perhaps a way to turn this feature off for those occasions when you just have to do it. Another possibility... How about the ability to make a function synchronized OR a way to make a code block atomic.
  24. All of the PICs have a bulk erase or chip erase, you have to find out how your particullar programmer impliments this. Try a config erase first.
  • Create New...