Jump to content

Reynard

EstablishedMember
  • Content Count

    687
  • Joined

  • Last visited

Everything posted by Reynard

  1. Welcome back gentlemen it's been a long time. Thank you for the new version. I hope you haven't lost too many followers. Best regards Reynard
  2. Hi John, Are you handling the BCL1F interrupt and giving the START another poke. If the START is aborted you will not get an SSPIF interrupt I would have thought. Waiting for interrupts to occur is not a good idea. Causes blocking. Interrupts are there to tell you when something has happened and not you having to ask. Cheers Reynard
  3. Hi John, The I2C on the PIC is probably not the best in the world. Knowing what state it is in can be difficult. Resets may not always do the same thing. A POR (cold reset) may reset more registers than a WDT or BOR (warm reset). After a WDT reset you could try toggling the SPEN to get the I2C state machine to reset properly after looking at the RCON reg to see why you were reset. You don't say what PIC you are using, but if you look at the errata sheet for the PIC18F4550 section 17 there is more info about the I2C which may be of help. Cheers Reynard
  4. Hi John, This one got me as well when I moved from XP to 8.1(x64). Although preg said it was successful it was telling porkies. I had to run preg.exe as administrator to resolve it. I used the command prompt (admin) then navigate in DOS mode to preg.exe I probably could have just used the file explorer, right clicked and used Run as administrator. Give it a try if you are on Win 7 or 8. Cheers Reynard
  5. Hi Chuck, I moved from XP to 8.1 without any problems. Just need to point to the correct directory for the compiler and linker using the Options panel. There has not been much support from the writers in a long time so maybe a dead product now. Cheers Reynard
  6. Hi John, These are merely software loops. Best to use a hardware timer if you don't like blocking functions or even Novo. Cheers Reynard
  7. Check also the compiler and linker path in the settings are pointing to the (x86) directory. This one got me when I moved to Windows 8.1 from XP and re-installed. You have to be super administrator to run the preg.exe I think you are right about Dave and Pavel doing a runner. I reported a problem to the support email address (24th November) about an FSR0 corruption when doing a compare. So far not a cheap out of them. Found a workaround to solve it for now. Cheers Reynard
  8. Hi Rob, An array or structure will keep them together otherwise the linker may put them individually anywhere it can find space. Cheers Reynard
  9. Hi John, It is in your installation directory called FloatMath.pdf Cheers Reynard
  10. Hi Richard, Working under the SB IDE having "Program Files" as a directory name is not a problem. I mentioned a while ago that having spaces in source and header file names does cause a problem. The solution was to insert underscores as word separators. Others would have said something if spaces in directory name were causing problems under MPLAB. Your example shows double quotes around the SB directory name. Cheers Reynard
  11. Hi Richard, It looks like the linker could not find the "libc.pic18.lib" to resolve the linkage. I am not an MPLAB user so cannot give you much advice. I assume you did the integrate thing when you installed SB. Check the integration section in the manual. Check you have some setting pointing you towards the SB library directory. Cheers Reynard
  12. Hi, All delay_xx functions take an unsigned char as an argument (8 bits) so your value of 2000 is being truncated to the last 8 bits. If you want 2 seconds, then call delay_s(2) or delay_ms(250) eight times. See manual page 76. Cheers Reynard
  13. Here is something interesting if you are working with signed integers. The boostc.h header file has (for PIC16): extern unsigned long __mul_32s_32s( unsigned long a, unsigned long b ); A signed multiplication that takes and returns unsigned values. Also, there appears to be no signed multiplication functions for the PIC18. Cheers Reynard
  14. Hi , Ah! you didn't say they were in different files. I now have the interrupt function in its own source file as part of the project and I still get the same warning message when building the CASM file. Cheers Reynard
  15. HI, This is what I get for your processor: Building CASM file Serious Warning: Possible sw stack corruption, function '__mul_32s_32s' called by more than one asynchronous thread (main/Task, interrupt, interrupt low) Cheers Reynard ps. Using 7.22
  16. Hi, You should have been given a warning about this. Have you tried turning on all warnings. Putting a time consuming calculation like this into the interrupt is probably not a good idea. Collect the data you want quickly, set a flag, semaphore or create an event which can then be processed by the main program. Cheers Reynard
  17. Hi All, Just to clarify, using an assignment as a condition test is valid ("Assignment used as truth value") but not obvious that a test for zero is performed. The compiler maybe should have squeaked out a warning of "possible unintended assignment" or something. Who hasn't typed in a single = when they meant a double == ?...... Oooooook, just me then gcc issues such a warning recommending parenthesis around the assignment, just to confirm that was your intention. Cheers Reynard
  18. Hi Ted, It may well be that condition testing is not required for simple data types but should you rely on it for all compilers. The condition part should be evaluated and not assumed the compilers has done some behind the scenes testing for a zero value. If the assignment had been a float or an object, what result would you get then ? Be explicit of your intentions for the compiler, lint testing and the reader of your code. Cheers Reynard
  19. Hi Rob, Is your problem really sorted ? You have no expression to test for the terminating null and are assuming the compiler will test the assigned value for zero or non-zero. For a simple char or integer the compiler may (or may not) throw in a test and set the Z flag accordingly. It is better you tell the compiler exactly what you want to do such as: for (char i = 0; (cc = array[i]) != '\0'; ++i) Here you are telling the compiler (and reader) to perform the for loop statements if cc is not equal to end of string null. Cheers Reynard
  20. Hi Drax, When debugging you do not need to calibrate the oscillator as the debugger does not work in real time. Use a conditional compile like this: #ifndef _DEBUG // Calibrate the internal oscillator. asm { call 0x3ff movwf _osccal } #endif Use the Debug build option when debugging otherwise use Release for the real thing. The _DEBUG flag is set/reset by the compiler depending on the build. Cheers Reynard
  21. Hi Drax, Put your "while(1)" at the beginning of the loop body unless you are performing a "do...while();" loop. Cheers Reynard
  22. You cannot have a any timer argument greater than 255. The timer functions take a char value (8 bits). Turn on "All Warnings" and the compiler will say something about it. Enjoy SourceBoost. Cheers Reynard
  23. Hi Martin, Use the software watchdog enable bit. wdtcon.SWDTEN It's the software version of the config bit. See page 258 of the data sheet. Cheers Reynard
  24. Hi Pavel, After a bit more digging around it was my firewall/antivirus software that was sandboxing sbmake.exe. I think I have managed to get it to trust all sourceboost files. I am using Comodo version 6. Comodo has never liked your software, even Comodo version 5. It complains that your software is not digitally signed therefore untrusted. If I still have problems I will disable the sandbox feature. Regards Reynard
  25. Error reporting in V7.22 seems to be at an all time low. An undeclared variable only says: failure, error:failed, done. All warnings are turned on but not a clue to where the error may be. A badly declared enum give the same result. Cheers Reynard
×
×
  • Create New...