Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. Samith There is a bug in the current release simulator. Updated simulator can be found here: http://www.sourceboost.com/CommonDownload/Binaries/SBV7.05.1_SimUpdate/sim ADC fix.zip Regards Dave
  2. JorgeF, No special purpose here, this is simply a mistake not to prevent multiple inclusion.. Regards Dave
  3. davidb, This is definitely a problem.Thanks for reporting it. Regards Dave
  4. Your code is not quite as the example of page 45.. The following will do what you want: #include <system.h> rom char* LCD_segment_config = // LCD segments setting table // if 1, then pixel is enabled { // GFEDCBA 0b00111111, // for displaying '0' 0b00000110, // for displaying '1' 0b01011011, // for displaying '2' 0b01001111, // for displaying '3' 0b01100110, // for displaying '4' 0b01101101, // for displaying '5' 0b01111101, // for displaying '6' 0b00000111, // for displaying '7' 0b01111111, // for displaying '8' 0b01101111, // for displaying '9' 0b01111001, // for displaying 'E' 0b00000000 // for displaying ' ' }; void main() { char zero; char one; zero = LCD_segment_config[ 0 ]; one = LCD_segment_config[ 1 ]; while( 1 ); } Regards Dave
  5. Colin, Sounds like the _EEPROM does not have the correct address for the device you are programming.You can check it in the devices header file. You find the address required in the Microchip programming data sheet for the device. Let us know how you get on. Regards Dave
  6. JorgeF, Was it him that replied ?? You are indeed correct, the example SysInit() should really be called first. The example only manages to work reliably by the fact that by the time SysTimerUpdate() is called enough time has passed to do the initialisation. The example needs to be corrected. Regards Dave
  7. Yes, is is a valid to do this. The idle task is returned to every time the scheduler head is reached. The highest priority tasks are executed one at a time until they have all yielded, then there is one execution of the idle task before returning to the task queue. The idle task really sits at the head of the queue, so has the same priority as the highest priority task in the queue. Yes this is the idle task, called every time the scheduler task queue head is return to. I hope that helps. Best way to implement you code is probably the simplest. No point in using tasks unless you want to do more than one thing at a time. Regards Dave
  8. Gennon, When you download to the device it is writing to the flash memory, so the program won't be lost when you remove the power,The only thing that could be happening is that the boot loader, the program that allowed you to download, is then not allowing the application to start. Regards Dave
  9. Kenn, Turns out the simulator is broken. What's gone wrong is that RA0 and AN0 are being treated as different pins, so a connection to RA0 does not go to the ADC. This item is now on our bugs list. Regards Dave
  10. Reynard, If this is the case, then its not good. I'm not seeing exactly where we are getting it wrong. Our config naming is meant to be following the Microchip format. Attached is a screen shot of the config help, showing the PIC18F46J50, I can't find FOSC for this device? Regards Dave
  11. Mike, The issue is probably in the device configuration data. When using BoostC you got: 3FF0 FFFF FFFF FFFF FFFF F72E F010 F801 F180 When using MPASM you got: 3FF0 FFFF FFFF FFFF FFFF F78E F010 F801 F180 When using C18 you got: 3FF0 FFFF FFFF FFFF FFFF F7AE F010 F801 F180 You need to check what the differences in the configurations words mean. It could be that Microchip uses some defaults when an option is not specified, and hence when identical settings are used the Microchip versions work. Regards Dave
  12. Reynard, We just follow the names for the configuration control as used by MPASM, rather than start creating our own names. For the PIC18F46J50 MPASM uses OSC for oscillator configuration. Take a look in MPLAB PIC18 config help.So we won't be correcting this as we want to be consistent with MPASM. Regards Dave
  13. mkwahler, All the device configuration options can be found in the devices target descriptor file (.tdf file). This file can be found in the installation folder, inside the config folder. Please take a look in there. Regards Dave
  14. Dave

    Hi

    The current floating point math library square root routine is somewhat on the heavy side when it comes to RAM and ROM. My best suggestion if convert the value to an integer (multiply by 100 for one decimal place) and then use the integer square root function. Regards Dave
  15. In state 5 the code blocks, ie execution of the state machine is suspended as you have sent the processor off just to do nothing for 10s. The thing to do is make the delay timing code non-blocking. To give you the idea imagine that you use a variable to count the time in seconds, this is updated every time a second passes (either in the main loop or by an interrupt service routine). Now you state 5 code just checks for when the time reaches 10s or the stop button is pressed. I hope you get the general idea, Regards Dave
  16. TomF, All targets support instruction core simulation, that is instruction opcodes can be decoded and the resulting registers modified. Hardware simulation is not as complete, the simulation consists of a library of virtual peripheral components. There components where based on some devices and proved to be accurate, but they are not necessarily accurate for other devices where the hardware has been changed from the original devices on which the virtual peripheral components were modeled. There is a "SourceBoost IDE Simulator features and limitations" section in the SourceBoost IDE User's guide manual. Please take a look there. Regards Dave
  17. Trossin, Another Cool little project. I don't know how you keep thinking them up. Regards Dave
  18. This issue is now resolved in the SourceBoost V7.05.1 Package available from the regular download page:
  19. RJS, Looks like we corrected something that was already correct and made it wrong :-( The confusion in this area stems from byte addressing and word addressing. Updated header files which will be included in the next release can be found here:http://www.sourceboost.com/CommonDownload/Binaries/PIC16F1XXX_HEADERS.zip Apologies to those who have suffered from this problem. Regards Dave
  20. Tom, This compiles with BoostC V7.05. Which version do you use? Remember to add: #include <system.h> to your code. Regards Dave
  21. The main problem is that the simulation uses a model for this port that is not quite correct:RA4 operates as open drain like it exist on 16F876A and many other devices, ie it can only operate a current sink not source. Sorry but this won't be fixed quickly. Regards Dave
  22. Yes you are right.The problem only occurs when the expression in the parenthesis does not contain a variable. Work around, preceed '-' with a zero, ie: sTest = 0-(20*10); Btw: I've added this to our bugs list. Regards Dave
  23. Lukapp, No, the SourceBoost IDE/debugger can't debug on PicKit2, you will need to use MPLAB. Regards Dave
  24. Mike, If these devices are 14bit instruction cores then it should not be a major job for the BoostC compiler to support them. Regards Dave
  25. Correct, all you get is a warm fuzzy feeling. No, there are specific upgrade prices, which you can find here:http://www.sourceboo...C/Upgrades.html All upgrades are included until a new major revision is released, a major version lifetime was historically around 2-4 years, but there is no guarantees on this time for future major releases. Regards Dave
×
×
  • Create New...