Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by davidb

  1. Hi, CPU: AMD FX-8350 8-core 4.00GHz Memory: 16GB OS: Win7 64-bit Pro IDE: MPLAB V8.92 Compiler: SourceBoost V7.21 Pro Target: PIC18F87K22 Not a show stopper but just found that: The BoostC Compiler -m option does not appear to work when using SourceBoost C under MPLAB. This shows success followed by BUILD FAIL on the first file compiled. Works when using SourceBoost IDE. Perhaps someone else can check this as it may be unique to me. Regards davidb
  2. Bade, Use the required library files from the 'SourceBoost\Lib\large' folder rather than those in the 'SourceBoost\Lib' folder. Unfortunately the documentation for the use of the various library files seems to be somewhat lacking. Regards davidb
  3. Bade, The error message tells you that the Linker needs the -idx2 option as well! Also, probably wise to upgrade to V7.21. Regards davidb
  4. Hi, Although not a problem that can't be overcome the bugs demonstrated in my above post are still extant in V7.21 Regards davidb
  5. Hi mityeltu, Sorry it didn't work but this is all pretty basic stuff. If your master is not transmitting how do you know that the slave is not working? It is difficult to comment without seeing your code but have you checked that your basic timing is working? Use a scope and a spare output port for debugging to check the timing and then check that the SPI clock and data outputs from your master are correct. Do this before worrying about the slave. Regards davidb
  6. mityeltu, I would suggest that you thoroughly read the data sheet for the part you are using as well as checking out application notes and sample code so that you properly understand how the interrupts work. It is only my opinion but I believe using delay loops is bad programming practice hence my suggestion of using an interrupt driven task timer. You can also use similar techniques to produce one shot timers, PWM etc. Delays are a quick fix for simple applications but become a pain when trying to expand the program to do something useful. While it is generally true that inte
  7. mityeltu, Here are a few basic problems, particularly with the slave: Do not globally disable or re-enable interrupts within the interrupt routine. Doing so is pointless and can cause problems. The global interrupt is disabled and re-enabled automatically. In addition why are you disabling pheripheral interrupts within the interrupt? You are you using the SPI interrupt to set a flag which you then monitor and clear in main (). This is totally pointless, you may as well not use an interrupt at all but just monitor the interrupt flag and clear it in main () when required. However
  8. Hi, SourceBoost 7.2 is still broken in regard to comparing signed data types with #defined constants with 18F parts. This is similar to the >= problem that occured in SourceBoost 7.1. which now seems to be fixed. Problem: The following test code was created to test for the problem. When compiled for 16F, specifically 16F887, it works fine with 'value' as any data type. When compiled for 18F parts, specifically 18F87K22, it works correctly for a signed char or signed long but fails using a signed short in test case 3. Expected Behaviour: To work correctly x should be 1
  9. Hi, Not sure if this is related but the following code was extracted from a project and greatly simplified to show the problem with pointers not incrementing using SourceBoost V7.20. The structures are normally much larger than these. The comments in the code should explain the problem. #include <system.h> typedef unsigned char uint8_t; /* A single receive buffer data structure */ typedef struct _usartRxBuf { uint8_t uData[8]; uint8_t *pByte; } usartRxBuf_t; /* USART module data including all buffers and varibles */ typedef struct _usartData { usartRxBuf_t sRxBuf[1]; uint8_
  10. Mmm, another clue - If you reverse the order of your values so that the highest occurs first then the example again works. Regards davidb
  11. Tom, I can also confirm that the problem exists. Replacing the defines directly with the values also fails as does various placements of parenthesis and casting to try and break up the problem. The code seems to break with your values as soon as you have more than 8 OR'ed above 256. Interestingly if you use enum {} for the values instead of your #defines your example works correctly and as a bonus the code generated is shorter too! Must be some clues there for Pavel and Dave. Regards davidb
  12. How about a union?: union { unsigned long ulong; unsigned char byte[4]; }mylong;   mylong.ulong = 0x12345678; unsigned char byte0 = mylong.byte[0]; unsigned char byte1 = mylong.byte[1]; unsigned char byte2 = mylong.byte[2]; unsigned char byte3 = mylong.byte[3]; Not tested! Regards davidb
  13. Hi Jorge, The reason for putting the tables into separate functions was only for test purposes to see the trade offs required between RAM and flash memory usage. The idea was to simulate the read from the RAM arrays originally used without altering the basic flow of the main code too much. Using conditionals I naively expected that I could select only the required table and the whole function including the table would be removed by the optimizer when the function was unused. I had already tried the single function with multiple conditionals as you suggest but, with at least four lar
  14. Dave, Basic project attached to demonstrate the problem. Note that in this example the rom definitions in each function are the same but would normally be different and much larger in size. The unused rom read function is apparently removed so I would expect the associated rom definition to be removed as well. However both are still in program memory. As I said it is not a major problem as I was just experimenting and happened to stumble upon this by accident. My full project now avoids these types of functions anyway SourceBoost Rom Test.zip. Regards davidb
  15. Hi, I am currently working on some code that is used in a number of similar equipments. These have different 16-bit lookup tables (arrays) in RAM and so I use conditional directives for the different equipments so that the unused arrays get removed. Because of the array size, no real need for speed and plenty of flash memory I decided to move them into flash using 'rom' lookup tables. For convenience I defined and initialised each 2 x 8-bit 'rom' table within separate functions together with the code to extract and return the 16-bit values. This made it easier to substitute the RAM ar
  16. Pavel, Can we have a list of fixes/updates for this release candidate? This will make it easier to check for any problems. BTW, there still isn't any Release Notes for V7.11! Thanks davidb
  17. Hi, Just had a quick read of your code and without going too deeply there seem to be a number of problems but to get you over your immediate one try using something like: ... unsigned int index = menuButtonScan (); switch(index){ case 0: ... instead of simply: ... switch(menuButtonScan){ case 0: ... as this will not work. You also seem to be calling mainMenu() recursively. Even if your code eventually does what you want you are using a large number of delays which will block your code from doing anything else useful. Sometimes small delays are inevitable b
  18. Hi Pavel, Nice to see new features but I feel basic compiler problems like the Signed Short problem on the PIC18Fxxxx should be fixed first! http://forum.sourceboost.com/index.php?showtopic=5021 Regards davidb
  19. Pavel, As a quick test I simply added the text "// FIXME:" as described by trossin to one of my project files. I can concur that this caused a save file error when trying to compile. This was with BoostC IDE v7.10 on Vista. Interestingly, I couldn't get it to fail when using BoostC IDE on WINXP or from within MPLAB V8.87 on Vista so I am guessing it is a platform related problem. It doesn't seem to be related to the number of files or their size in a project. Very strange but the obvious fix is to not use the text FIXME! Hope that helps davidb
  20. Dan, I haven't tried this myself but without your full code, the part you are using, clock frequency etc. it is difficult to debug. However, I can see some basic problems. You are not doing what Microchip AN1298 tells you to do. Read the note, particularly the Sensing Steps section, and try and understand the required sequence of events and what is meant to happen before you attempt to code it. Where are the port/ADC initialisation, variable definitions etc.? Where are you switching the ports between ADC input and Digital? Why do you have massive delays of 20mS? The proce
  21. Dave, Was this problem supposed to have been fixed in V7.1? Regards davidb
  22. Hi zzjoki, Check that you are using the linker -swcs option before compiling. See the Novo documentation. Set the clock to 20MHz and connect the LEDs to Port B. Just tried it and it works for me. davidb
  23. Mike, Try taking out the whole asm block immediately after your problem line (binl is used there too) and see what happens. Not offering a solution but maybe just a clue as to what is going on! BTW shouldn't if(negflag = binl.15) be if(negflag == binl.15)? Regards davidb
  24. Reynard, Looks like I missed the most obvious problem! But why comment the config out? The default values - RC Oscillator, LVP on etc. will not work so they must be changed elsewhere. My suggestion of using a heartbeat would be useful to sort these sort of obvious problems out in the early stages. davidb
  25. Hi Samith, You say you are trying to use the virtual power supply which suggests that you are using the SourceBoost IDE and plugins. I tend to use real hardware with MPLAB and ICD3 or PicKit2/PicKit3, depending on what I am doing, so I am not really the best person to help with simulation problems. There was a bug in the recent release of the simulator for V7.05 but I am not sure if the version for V6.95 worked O.K. If you can try it on the real hardware then I believe the modified code should work. It looks correct but I haven't tested it so I could have missed something. BTW, yo
  • Create New...