Jump to content

raskolnikov

EstablishedMember
  • Content count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About raskolnikov

  • Rank
    Newbrie
  1. I need to change the critical section macros to use GIEL and GIEH instead of GIE. When I do this is it enough to simply change the file novo.c then follow the instructions in the NOVO RTOS users guide under "Building Custom Novo Libraries"? Would I need to include all the following files in a project to build a library with the critical section macro changes? 1) novo.c 2) novo.h 3) novom.h 4) novolib_picwhatever.c 5) novocfg_picwhatever.h If I want to use the ISR callable macros in either the high or low priority interrupts I'm thinking of something along these lines in novo.h #ifdef _PIC18 #ifndef GIEL volatile char intcon@ 0xFF2; #define GIEL 0x0006 #endif #ifndef GIEH #define GIEH 0x0007 #endif #endif Then, depending on which ISR I want to use (interrupt or interrupt_low) I would define the SysCriticalSectionBegin/End() with intcon.GIEL or intcon.GIEH Will this give me the results I want? Thanks, raskolnikov
  2. I have a situation where I am using the C++ compiler and NOVO RTOS together. I have two tasks that I have declared in the same file as my interrupts and Main. From inside these tasks I access member functions that in turn call NOVO macros. When I go about it this way the code fails, versus writing it in C style with all functions declared in the same file. Here is an example: class CUart *uart; // forward declaration void interrupt()... Task0() { uart->send(); // this call fails when calling SysBeginCriticalSection() } void Main(void) { SysCreateTask(... SysStartTask(... while(1)... } The code in the send member function uses the NOVO macros SysBeginCriticalSection() and SysEndCriticalSection(). When called from the C style program all is well but when called from the class member function it fails. I hope this is just something that I am doing wrong and not a limitation of the C++ compiler. Thanks, Matt
  3. Novo And C++ Compiler

    Tasks can't be members of a class... Thanks for the response. So I know that Tasks can't be members of a class. Inside a task can I have class objects calling their own member functions? For example, I am using some of your Serial Interface code and I have created a class called CUart with send and receive member functions CUart::send, CUart::receive. In my main function I create and start a task, Task0 that contains your Serial code. Task0() resides in the same file as main and I have forward declared the uart class. I also have Tx and Rx functions declared in the same file as main and Task0() for troubleshooting: class CUart *uart; void Task0() { //Send out hello string (string should fit into the tx buffer) Tx("Ready..."); //uart->send("Ready..."); //This task will receive data, transform it and send back while(1) { //Wait for serial data to come. This is a blocking //call that will yield if no data is available unsigned char data = Rx(); //unsigned char data = uart->receive(); //If this is lower case character convert it to upper if(data >= 'a' && data <= 'z') data -= 'a' - 'A'; //Send data back Tx(data); //uart->send(data); } } void Main() { SysInit(); SysCreateTask... SysStartTask... while(1) { Sys_Yield(); } } With the uart->send() and uart->receive() uncommented and Tx() and Rx() commented out the code compiles and links fine but will not run on the microcontroller (PIC18F4685). When I comment out uart->send() and uart->receive() and uncomment Tx() and Rx() the code will run on the microcontroller and I can interface with Hyperterminal. I hope there is something simple I am doing wrong, like a linker command line argument or something of that nature. Thanks for your help. Matt Fisher
  4. Novo And C++ Compiler

    Tasks can't be members of a class. The reason is in memory allocation for variables. Because there is no stack on PIC all memory allocation has to be done at compile time. Each task is handled as a start of a completely independent call tree. This was compiler and linker can overlay memory regions between different call trees and between different nodes on the same tree. Again this analysis is done at compile time. If class members are used as tasks that it's not known at compile time how many instances of a particular class will be created at run time (remember that is task was a class member that each instance of a class would create a new task). This means that code can't be linked because it's not possible to allocate memory for variables. Technically it would be possible to use static class members for tasks but the compiler currently does not support this. Regards, Pavel Pavel, Thanks for the response. Will the compiler support static class members as it relates to Novo RTOS in the future? Will there eventually be support for private and protected data? Best, Matt
  5. Novo And C++ Compiler

    I'm using the c++ compiler coupled with Novo RTOS. I have a class that has two Novo tasks as member functions as well as an interrupt that is a member function, along these lines: Assume a class called foo, the following member function and task handle: #define hTask1 0 foo::Task1() { // Do some excellent stuff... } After some initialization I have a run function like this: foo::Run() { SysInit(); SysCreateTask(hTask1, 2, this->Task1); SysStartTask(hTask1); } I will get the following error: [error: can't convert 'void (*)(class foo*)' to 'void (*)()']. When I write the code in c and use the c compiler I don't run into these problems. There is obviously something that I don't know about the system. Perhaps Tasks cannot be member functions? Any help is appreciated. Thanks, Matt
  6. Crystal Oscillator Setup

    Forum, I can't seem to get a 20MHz crystal oscillator to work with my PIC18F4685. I have to believe that it is a configuration issue. This is the current configuration: #pragma DATA _CONFIG1H, _OSC_HS_1H #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG3H, _MCLRE_OFF_3H #pragma DATA _CONFIG2L, _BOREN_OFF_2L & _PWRT_OFF_2L #pragma CLOCK_FREQ 20000000 When I program the u-controller and power it up it will work with or without the crystal hooked to it which tells me that it is defaulting to some internal oscillator. Perhaps there is some setting I am missing. Best, Matt
×