Software architecture using C for mid-range PIC.
in [Embedded]
|
From: Neil on 10 Sep 2009 00:22 Vladimir Vassilevsky wrote: > > > Fevric J. Glandules wrote: > >> I've got quite a lot of experience in programming 8 bit microcontrollers >> with assembler; I've also done quite a lot of 32 bit embedded stuff >> using an RTOS with C. What's new to me is using a 16 bit mid-range >> PIC18 device in C. >> >> So I'm trying to make sure that I come up with a fairly sensible >> architecture. > > >> The application is probably fairly typical - inputs / commands come in >> via the UART, peripheral devices need to be turned on and off in >> response, other devices need to be queried via I2C >> for data, etc. >> >> My current thinking is to have a main() loop that is subdivided >> into separate sections that deal with each peripheral in turn. >> >> Each code block will be non-blocking, and will implement a state >> machine for each peripheral. > > It is so much easier to use a basic time-slicing round robin preemptive > multitasker rather then developing the complicated non-blocking state > machines. Then, the tasks can be done as the straightforward linear > code, and you don't have to worry about blocking. > > > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultant > http://www.abvolt.com In a PIC18 ?
From: Neil on 10 Sep 2009 00:25 Fevric J. Glandules wrote: > Hi all, > > I am new to this group but checking over recent postings seems > to indicate a fair amount of Clue kicking around [1]. > > A bit of background before y'all tell me to RTFM or JFGI. > > I've got quite a lot of experience in programming 8 bit microcontrollers > with assembler; I've also done quite a lot of 32 bit embedded stuff > using an RTOS with C. What's new to me is using a 16 bit mid-range > PIC18 device in C. > > So I'm trying to make sure that I come up with a fairly sensible > architecture. Googling isn't much help - most of the "tutorial" > stuff out there is aimed at a very low level, or else you find > discussion at the nuts and bolts level of a particular interrupt > handler. > > The application is probably fairly typical - inputs / commands > come in via the UART, peripheral devices need to be turned on > and off in response, other devices need to be queried via I2C > for data, etc. > > My current thinking is to have a main() loop that is subdivided > into separate sections that deal with each peripheral in turn. > > Each code block will be non-blocking, and will implement a > state machine for each peripheral. Incoming comms will run > off interrupts. In RTOS terms, a sort-of round-robin system. > > If, for example, incoming commands are ASCII sequences > like "L11" for "LED 1 on" followed by an end-of-message > checksum byte, in pseudo-code, something like this: > > uart_isr() { // push chars into circular buffer > push_char_to_uart_buf() > if (char == end_of_message) message_flag = 1; > } > > main_loop { > if (message_flag) { > move_chars_from_uart_buf_to_command_buf() > switch (command) { > case foo: foo_state = 1; > case bar: bar_state = 1; > } > } > // foo machine > if (foo_state) { > switch (foo_state) { > case 1: if (foo1()) foo_state = 2; > case 2: if (foo2()) foo_state = 0; > } > // bar machine > if (bar_state) { > switch (bar_state) { > case 1: if (bar1()) bar_state = 2; > case 2: if (bar2()) bar_state = 0; > } > } > > Does that make sense? Should the ISR do as little as possible or > is it a good idea to give it some "awareness"? > > The above pseudo-code is just meant to give an idea of where > I'm heading, so don't take it too seriously. I'm really looking > for general pointers on how to approach a mid-level architecture. > > Oh go on then, rip me to shreds. > > [1] I've also dug out the FAQ. > It is a reasonable way. The interrupt usually should do as little as possible there are only two so they have to share. Your application may vary.
From: Mark McDougall on 10 Sep 2009 01:28 Fevric J. Glandules wrote: (snip) > Does that make sense? Should the ISR do as little as possible or > is it a good idea to give it some "awareness"? It's a reasonable approach. I did a multi-serial port protocol converter much the same way. Incoming messages were buffered by a bunch of serial ISRs which triggered different semaphores when a full packet was ready. Conversion and pushing into the transmit buffer was done in the main loop. Again, serial ISRs handled the actual transmission IIRC. As for the 2nd question, the answer is (always) "depends". Depends on the requirements of your system. The rule is, do as little as you can get away with inside the ISR. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266
From: Bill Davy on 10 Sep 2009 04:50 "Fevric J. Glandules" <fjg(a)invalid.invalid> wrote in message news:h89e3b$moi$1(a)news.tornevall.net... > Hi all, > > I am new to this group but checking over recent postings seems > to indicate a fair amount of Clue kicking around [1]. > > A bit of background before y'all tell me to RTFM or JFGI. > > I've got quite a lot of experience in programming 8 bit microcontrollers > with assembler; I've also done quite a lot of 32 bit embedded stuff > using an RTOS with C. What's new to me is using a 16 bit mid-range > PIC18 device in C. > > So I'm trying to make sure that I come up with a fairly sensible > architecture. Googling isn't much help - most of the "tutorial" > stuff out there is aimed at a very low level, or else you find > discussion at the nuts and bolts level of a particular interrupt > handler. > > The application is probably fairly typical - inputs / commands > come in via the UART, peripheral devices need to be turned on > and off in response, other devices need to be queried via I2C > for data, etc. > > My current thinking is to have a main() loop that is subdivided > into separate sections that deal with each peripheral in turn. > > Each code block will be non-blocking, and will implement a > state machine for each peripheral. Incoming comms will run > off interrupts. In RTOS terms, a sort-of round-robin system. > > If, for example, incoming commands are ASCII sequences > like "L11" for "LED 1 on" followed by an end-of-message > checksum byte, in pseudo-code, something like this: > > uart_isr() { // push chars into circular buffer > push_char_to_uart_buf() > if (char == end_of_message) message_flag = 1; > } > > main_loop { > if (message_flag) { > move_chars_from_uart_buf_to_command_buf() > switch (command) { > case foo: foo_state = 1; > case bar: bar_state = 1; > } > } > // foo machine > if (foo_state) { > switch (foo_state) { > case 1: if (foo1()) foo_state = 2; > case 2: if (foo2()) foo_state = 0; > } > // bar machine > if (bar_state) { > switch (bar_state) { > case 1: if (bar1()) bar_state = 2; > case 2: if (bar2()) bar_state = 0; > } > } > > Does that make sense? Should the ISR do as little as possible or > is it a good idea to give it some "awareness"? > > The above pseudo-code is just meant to give an idea of where > I'm heading, so don't take it too seriously. I'm really looking > for general pointers on how to approach a mid-level architecture. > > Oh go on then, rip me to shreds. > > [1] I've also dug out the FAQ. > What I did on a PIC16 was: ..... in a header: // // Most state machines follow the same form. // They have a local static variable which is their next state. // The first time they are called, they perform their own // initialisation. fFirstCall is true only on their first call. // typedef INT16 FsmStateT; #define ReturnState(Label) {FsmState = label_address(Label);return;} INT1 fFirstCall; Somewhere in main() set fFirstCall, go round once, reset fFirstCall, then keep going round. Each finite state machine then looks something like this: #separate VOID FSM_UserIf(void) { static FsmStateT FsmState; PutState('v',FsmState); if ( ! fFirstCall ) { if ( MainStatus.MotorRunning ) return; goto_address(FsmState); } // // Initial state depends on the switches. Wait // for them to be known before deciding. // ++nInitialising; fArm = 0; fDisarm = 0; WAITING_TO_START: if ( ! Switches[0].Known || ! Switches[1].Known ) ReturnState(WAITING_TO_START); --nInitialising; DECIDE_NEW_STATE: ..... }
From: Vladimir Vassilevsky on 10 Sep 2009 11:14
Neil wrote: > Vladimir Vassilevsky wrote: > > >> It is so much easier to use a basic time-slicing round robin >> preemptive multitasker rather then developing the complicated >> non-blocking state machines. Then, the tasks can be done as the >> straightforward linear code, and you don't have to worry about blocking. >> > In a PIC18 ? What's the use of PICs or 8051x misery when AVRs, HC08s and other processors with the flat memory and the traditional stack are available? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com |