Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. Use of volatile is not required in this case except for the shared flag. Regards Dave
  2. Not true. Variables declare in an interrupt routine just as you normally would. Volatile indicates that the variable can be changed by something external (like it is a register that maps to an input port), the compiler then knows it cannot cache this value and must always read from and write to that actual register when it is referenced in the code. Not true. Possible, it is correct to mark any variable used in both the main routine and and ISR as volatile. If you don't do this, the main code may take a copy of the variable, so when it is changed in the ISR the change is not seen. Using the volatile keyword causes the compiler to always read the original source of the data every time it is referenced. Regards Dave
  3. If you don't refer to the variables in the code, then they will be optimised away. Then there is nothing to watch. Try assigning values to them so they are used, and then try to watch them. Regards Dave
  4. JBr, No they need to be disabled Hardware multiply is available in all PIC18's, it's not part of the extended instruction set. Regards Dave
  5. bongo, Interesting. It maybe that the files are linked in a different order, take a look at the linker command line when building under SB IDE and MPLAB. Regards Dave
  6. kdoney, you need to scroll down the page to "The complete project is available here." Regards Dave
  7. Keni, A common "gotcha" is read modify write issues. What this means is that changing even just a single bit on a port cause the port to be read, the data is then modified and written back. When the reading process is perform it reads the actual logic levels on the port not the last value written to the port, so if you have a large external load (or a capacitive external load) the reading of the port may not give you what was last written. So an output that was turned on may end up turned off. Microchip improved the situation on PIC18 devices by adding LAT registers that hold the actual value written to the port, so you are then not at the mercy of the external loading affects. I hope that makes sense. Regards Dave
  8. Peter_pvk. When the compiler finds an error in the code and it has no further breakdown of what the error might be. As time goes in the development of the compiler the more errors, where possible, get improved error messages. Remove the space between else and if, ie "else if" becomes "elseif". See below: #pragma CLOCK_FREQ 4000000 sub main() dim i as byte dim v(70) as byte if v(2) = 80 and v(3) = 82 then for i = 5 to 58 v(i) = (call usart_rx()) next elseif v(2) = 80 and v(4) = 71 then for i = 59 to 68 v(i) = (call usart_rx()) next end if loop1: goto loop1 end sub function usart_rx() as byte if ( (rcsta.OERR = 1) ) then rcsta.CREN = 0 rcsta.CREN = 1 usart_rx = 0x00 else do while (pir1.RCIF = 0) _asm nop loop usart_rx = rcreg end if end function Regards Dave
  9. You add it as a linker command line option: Menu Settings->Options->Compile Options->Extra Linker Options Regards Dave
  10. Dave, I mentioned earlier - missing CVRCON definition for some devices. I found that it was an error in Microchip header files and it is now in the errata (found it for 18f25j11). Is it possible for such additions to get it to your definitions? And still missing configuration defs, as they are no more at locations near 0x300000, but at end of program flash... Maybe they are missing in Microchip header files too. Microchip supplied data is the primary source of data for our header and TDF files, so if the error is in there we will reproduce the same error unless we notice that its wrong or missing which considering the amount of data is less likely. On the configuration front we are adopting a new style (as per Microchips new configuration style): #pragma CONFIG WDT = ON This work is nearly complete, so should be included in the next release. Regards Dave
  11. Looks like you aren't using the BoostBasic Compiler. What tool suite do you have selected? Regards Dave
  12. New hot off the press tdf and header files can be found here: http://www.sourceboost.com/CommonDownload/..._04-12-2009.zip. It now includes the following devices: PIC18F13K22, PIC18F14K22, PIC18F2458, PIC18F24J11, PIC18F24J50, PIC18F2553, PIC18F25J11, PIC18F25J50, PIC18F2682, PIC18F26J11, PIC18F26J50, PIC18F4458, PIC18F44J11, PIC18F44J50, PIC18F4553, PIC18F45J11, PIC18F45J50, PIC18F4682, PIC18F46J11, PIC18F46J50, PIC18F6393, PIC18F63J11, PIC18F6493, PIC18F64J11, PIC18F65J11, PIC18F6628, PIC18F66J55, PIC18F66J90, PIC18F66J93, PIC18F6723, PIC18F67J90, PIC18F67J93, PIC18F8393, PIC18F83J11, PIC18F83J90, PIC18F8493, PIC18F8628, PIC18F86J90, PIC18F86J93, PIC18F8723, PIC18F87J90, PIC18F87J93, PIC18L14K50, PIC18LF13K22, PIC18LF13K50, PIC18LF14K22, PIC18LF14K50, PIC18LF24J11, PIC18LF24J50, PIC18LF25J11, PIC18LF25J50, PIC18LF26J11, PIC18LF26J50, PIC18LF44J11, PIC18LF44J50, PIC18LF45J11, PIC18LF45J50, PIC18LF46J11, PIC18LF46J50 Regards Dave
  13. We need more information, please post what appears in the Output->Build window (you can select the text and copy and paste it into a forum post). Regards Dave
  14. Did not realise that was a limation. Now set to 30 seconds. Regards Dave
  15. even on windows and with iexplorer, no go from my location. I don't have any proxies or filters in the path... Can you please send it to my profile e-mail? I'll be very thankful! I want to try the 25j11 support... Send me you email address and I'll send it onto you. I would post it on the forum but it's too big. Regards Dave
  16. Works ok for me, even on different PCs in different locations. Regards Dave
  17. Here is a link to some new header files and TDF files: http://www.sourceboost.com/CommonDown..._21-11-2009.zip PIC18F24J11, PIC18F24J50, PIC18F25J11, PIC18F25J50, PIC18F26J11, PIC18F26J50, PIC18F44J11, PIC18F44J50, PIC18F45J11, PIC18F45J50, PIC18F46J11, PIC18F46J50, PIC18LF24J11, PIC18LF24J50, PIC18LF25J11, PIC18LF25J50, PIC18LF26J11, PIC18LF26J50, PIC18LF44J11, PIC18LF44J50, PIC18LF45J11, PIC18LF45J50, PIC18LF46J11, PIC18LF46J50 These are really hot off the press, so currently lack any target configuration options. Regards Dave
  18. jaero, We are in the process of adding a lot of new devices, the 18F25J11 happens to already be first on the list. Will make this available as soon as its done. Regards Dave
  19. Neil, This problem was indeed introduced in BoostC V6.96 and affects PIC18 targets, allowing bad code to be compiled and linked without an error or warning (nasty). It has been fixed in latest release of SourceBoost Package V6.97 Beta2 you can get from http://www.sourceboost.com/CommonDownload.html. Regards Dave
  20. Post your code inside a code block tags: [ code ] [ /code ] to retain the formatting. Regards Dave
  21. You are indeed correct, this problem was introduced in V6.96 and needs fixing very soon. Regards Dave
  22. Jan, See if the attached document helps. Regards Dave
  23. rajeev, This is a limitation, the simulator doesnt' support the ports called GPIO.The best option is to find a similar PIC16 target, and test the code on that then change the target device once that code is working under the debugger/simulator. Regards Dave
  24. sdujolo, The BoostC compiler for the PIC18 does not support the PIC18 extended instruction set, so to use code produced by it you must ensure that the extended instruction set is turned off. I don't know of a work around :-( Regards Dave
×
×
  • Create New...