Jump to content

Picxie

Moderator
  • Content Count

    277
  • Joined

  • Last visited

Everything posted by Picxie

  1. Compiler will not allow a ROM array populated with enums In this example #include <system.h> enum tstEnum {ONE, TWO, THREE}; #define SEVEN 7 #define EIGHT 8 #define NINE 9 rom char * testTable = {1,2,3,4}; rom char * testTable1 = {SEVEN, EIGHT, NINE}; rom char * testTable2 = {ONE, TWO, THREE}; void main() { } Give this error enumr.c failure C:\xxx\enumr.c(10:26): error: error in rom object initialization C:\xxx\enumr.c(10:23): error: failed to initialize variable 'testTable2' "C:\Program Files\SourceBoost\boostc.pic18.exe" enumr.c -t PIC18F248 Exit code was 1.
  2. I can tell you briefly how to do this, but it wont help with your understanding. if(porta & 0x03 == 0x03) You need to read up on C language first before diving in even at this shallow end. The same applies to your first question. try putting beginners C into google and choose one of the many free tutorials available.
  3. This is possible with the C2C compiler but I do not think it is available with the boostC compiler.
  4. Thanks, it will make my (working)life a little easier !
  5. Sourceboost V6.4 BoostC16 and BoostC18 WindowsXP I have ticked the programmer option in the build options dialogue and set the programmer in the tools tab of the BoostC compiler options dialogue as "C:\PicProg\myPicProg.exe" however a build terminates after the link phase. The programmer is not called. I can call the programmer from the build menu but not after a build. I have checked the makefile generated and get this # Generated by SourceBoost IDE 6.40 TstPrg.obj: TstPrg.c TstPrg.h TstPrg.__c "C:\Program Files\SourceBoost\boostc.pic16.exe" TstPrg.c -t PIC16F648A TstPrg.h
  6. Check the dates! this thread was last used in October and Electro-Dan hasnt been around since January.
  7. Please see various previous comments about calling functions from seperate threads of execution. Please feel free to apply the same solution each time you come across this problem.
  8. The P16f676 header is for the C2C compiler, the Pic16f676 header is for the BoostC compiler.
  9. I assume you are using a PIC16 device. The best solution is to get rid of the multiply from the interrupt. IE set a flag in the interrupt to indicate that the data requires multiplying. The reason for this is that the multiply routine calls a hidden subroutine. The PIC16 devices have a limited call stack depth. By using a call in an interrupt you are reducing the call depth allowable in the main thread. If you absolutely must have a multiply in the interrupt then may I suggest that in the interrupt you use chars and in the main thread you use ints. That way the interrupt will cal
  10. Does this mean you have sorted out function pointers?
  11. I dont know what your intended application requires but altering the frequency of a PWM is not the standard practise for control, It is usual to change the duty cycle. With the 16F876 you have two independent CPRxH/L so it is possible to adjust the duty cycles independently
  12. For a simple waveform you could use a zero crossing detector to detect the start and end of a cycle. However in this case you should take sufficient sample to capture the required number of cycles based upon what the slowest cycle is. Depends what you want to do with the data and the size of a block of samples. You could easily save 64 (byte)samples in an array in internal ram, a larger block will require some external memory device, serial eeproms are probably the easiest to interface to. Though if the sample rate was particularly high you may have problems writing to a serial eepro
  13. In answer to the second question, it is very rarely a good idea to delay in an interrupt as you will be starving the main thread of any execution time.
  14. Asmallri Many thanks for taking the time to respond from halfway around the world! Ain't the web great!! You raise a couple of newbe questions I don't understand what you mean in your quote above. When the interrupt occurs, I assumed the handler would execute its routine, even if it includes the delay function? If I understand your sample code, you turn on the led in the handler but do further led control in the mainline. You have not used the custom delay function provided in the library. My question is, I asume the delay function is implemented somewhat along the lines of yo
  15. You dont say what device you are using. All the 8 bit PIC devices (PIC12, PIC16 and PIC18) have only one ADC. This can be routed through multiple channels depending on the PIC device. You will have to connect each of the pots to a separate ADC pin on the PIC and sample each one in turn, see the data sheet for your PIC for details on how to direct the ADC to a channel. As you are reading sequentially it is a simple matter to copy the AD result values between conversions to prevent them corrupting. If I was you I would very carefully read the specifications for the PWM channels for the P
  16. The C2C pragma is for the software UART provided by C2C, so wont work using the PICs hardware UART. There may be a polarity reverse control bit (doubtful ) the other alternative is to use one of the many RS232 buffer chips, these do the necessary level conversion, or maybe you could bypass the RS232 buffer in your LCD module.
  17. The only difference I can see is this line in the MPAsm generated file :020000040000FA This is an extended linear address record, ie it set the upper 16 bits of address in a 32 bit addressing system. As it sets it at 0h0000 (which is the default)I can see no reason why this would affect the code image generated by a device programmer. Maybe the picdem has different ideas of the default upper address!!! see http://www.interlog.com/~speff/usefulinfo/Hexfrmt.pdf for details on intel hex format
  18. Hey, just a thought but, what happens when you actually TRY doing it?
  19. Get the spec sheet for the 16F877 from microchip at http://www.microchip.com/stellent/idcplg?I...ocName=en010242 Whilst on that page get the document about the USART (better still download the midrange manual, its chapter 18)
  20. You can use the split package download, you still have to download it all but at least you can get it in manageable chunks.
  21. rom stuff is stored in program memory, not eeprom
  22. So dont do it then! BTW what happens if you try #ifdef OPT #pragma OPTIMIZE "a" #endif
×
×
  • Create New...