Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Posts posted by Dave


  1. JorgeF,

    In the process of building an application with NOVO, I started having a lot of errors related with header files inclusion..

    After some testing I tracked the problem down to the fact that "novo_pic..t..s..p.h" and "novo.h" are not protected against multiple inclusion.

     

    As all the other header files in the sourceboost system have this protection; I'm sure this must serve some purpose.

    I only would like to know what is this purpose.

    No special purpose here, this is simply a mistake not to prevent multiple inclusion..

     

    Regards

    Dave


  2. Well, the form of the declaration matches exactly that shown in the BoostC manual, as shown on page 45. Originally I had declared the array without the pointer (i.e.,

    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


  3. Colin,

    I cannot get the #pragma DATA _EEPROM, nn, nn, nn directive to work.

     

    EEPROM remains unchanged.

    Also, PICkit2 tells me the hex file is bigger that the device memory.

     

    I don't think I have data protection on anywhere.

    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


  4. JorgeF,

    Fisrst of all, thank you Pavel for your repply to my previous questions.

    Was it him that replied ??

     

    In an example in the NOVO manual, I found the following:

    ...

    InitTimer();

    SysInit();

    .....

     

    The InitTimer() function enables the overflow interrupt for TIMER0, and the interrupt handler calls SysTimerUpdate().

    Wouldn't it be safer to only enable the interrupts after calling SysInit() ?

    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


  5. 1) Can a task stop himself? Is it "legal" to call Sys_StopTask from within the task beeing stopped?

    Yes, is is a valid to do this.

     

    2) If I use priorities, what is the priority of the idle task?

    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.

     

    3) By the way is it correct to call "Idle Task" to the "while(1){Sys_Yield();}" loop in the "main()" function? Or there is some "Idle Task" hidden inside the NOVO kernel?

    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


  6. Gennon,

    I wrote an application in BoostC for the Matrix ECIO40P (PIC 18F4455). After downloading via the Matrix programmer, the application runs fine. But when I removed the USB power to the ECIO40P, and

    reapplied the power after about 5 secs, the program on the ECIO40P started to run, but the application does not work anymore ( I had a switch wired to porta.0). I had to reload the application from the matrix programmer again, and everything works fine.

     

    It appears the application program is not burnt into the flash memory, and when power is removed, the program is lost, and need to be reloaded. Anyone had this experience? Am I missing some code lines ? The hex file size is 2kb, my license covers it. My linker switch is -rb 0x0800

    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


  7. Kenn,

    Update:

     

    So, I wrote a minimalist "dimmer" app, where the ADC value is used to control a PWM LED dimmer, built it, and programmed it into a '877A... and it worked fine on the hardware - 10k pot across Vdd and Vss, wiper into PORTA.0... pot controls brightness.

     

    I went back to the IDE, tried to simulate it using the Function Generator as source of DC input, and LED plugin, and 'watched' adcvalue... and it stayed at zero, apparently no adc happening, or simulated voltage isn't being applied. If anyone tries this also, please post your results.

    ....

    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


  8. Reynard,

    Given the user cannot compile your product without error using the supplied .h and .tdf files, the problem lies with Souceboost.

    If this is the case, then its not good.

     

    The PIC18F44J50 is part of the PIC18F46J50 family but Sourceboost have decided to use differing names for OSC and FOSC also select names INTOSCO and INTIO67.

     

    The info for the 44J50 part is incorrect with the Microchip data book for CONFIG2L (p421).

    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

    post-469-0-21715200-1325626776_thumb.png


  9. 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


  10. Reynard,

    The problem lies in the PIC18F44J50.tdf file.

    ...

    Dave will correct this in the next release :(

    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


  11. hi,

    i am using pic16f689 and version 6.81. i have to use sqrt function,

    but it need 260 bytes ram. i have only 256bytes available.

    is it my program mistake or else?

     

    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


  12. 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


  13. TomF,

     

    The list appears to be a list of targets that can be selected to compile code, not a list that can be simulated.

    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


  14. RJS,

    I see that the Microchip documents do state 1E000h as the EEPROM address, however, when programming the device this does not work. I am not sure if MPLAB is not interperting it correctly or just an error in the document but if you set _EEPROM to F000h the data is written to the EEPROM in the correct location. I hate modifying header files as they will get over written next time I update so I just set the correct value in my code.

     

    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


  15. Trying to simulate the 16F636, however i cannot write to RA4, I can read RA4.

     

    I can read and write RA3, which is the MCLR pin, which is supposed to be read only.

     

    So, i think the simulator has RA3 and RA4 mixed up.

     

    Can this be fixed quite quickly? I really need to simulate the software this week.

     

    Sourceboost 'c' compiler, V7.04

     

    - Edit: The sleep appears to not cause the device to sleep, or the WDT is expiring immediately and wakening the device from sleep.

    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


  16. This is only a minor issue which is easily worked around.

     

    Using latest BoostC download Ver 7.04 on Windows XP SP2.

     

    Compiler gives invalid operand on:

     

    short sTest;

     

    sTest = -(20);

     

    sTest = -(20*10);

     

     

    In general, it looks the compiler does not like unary minus followed by a paren.

    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


  17. From some time I use boostC free edition (with mplab). I understand that some people work hard to maintain this program and this people must be supported but I have some questions regarding licenses :

    1. If I buy a "Lite" license is like a "donate" on other sites (it will be no difference between free version and lite version) ?

    Correct, all you get is a warm fuzzy feeling.

    2. If I buy a "standard" license that cost (let's say) X usd and after a while I want to upgrade to full "licence" yahy cost Y usd (with Y>X) I must pay Y-X usd or Y usd ?

    No, there are specific upgrade prices, which you can find here:

    http://www.sourceboo...C/Upgrades.html

    3. How long is valid a license and witch upgrades are included ?

    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...