Jump to content
43oh

n1ksn

Members
  • Content Count

    38
  • Joined

  • Last visited

  • Days Won

    2

n1ksn last won the day on September 3 2011

n1ksn had the most liked content!

About n1ksn

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I realized after posting this tutorial that the functions associated with the LED state machine can (and should) be declared as static. This will allow an optimizing complier to do a better job compressing the code. I've revised the zip file accordingly, including static declaration for the pushbutton state machine. I have not changed the code snippets. Sorry for any inconvenience. Cheers, Andy n1ksn
  2. Thank you for the post, Christian. When I opened the TI spreadsheet it hung my system. However, I was able to look at the generated code. Looks interesting. When I've recovered from writing my tutorial I'll give it another look. Andy n1ksn
  3. Here is the code for the main module in the complete state machine demo program. I'm including it here because the comments contain general descriptions of the the program modules and the main function is rather short. //------------------------------------------------------------------------------ // main.c in project StateMachineBlink6 // // The overall structure of this program follows the approach of Tom Baugh // found in "MSP430 State Machine Programming." // // The modules in this program: // // Main: General shell program for initialization and execution of the // syste
  4. We are headed down the home stretch. We finish this module with two more sets of functions, those which send signals to the state machine. Here are the functions in the client interface (with prototypes in Led.h): //------------------------------------------------------------------------------ // Functions to allow client module to control LEDs // Put LED in steady off state void Led_TurnOff(Led_Index index) { This_Led = Led_Current[index]; This_Signal = LED_OFF_SIG; (This_Led->Current_State)(); } // Put LED in steady on state void Led_TurnOn(Led_Index index) { This_Led =
  5. We are now ready to look at the state entry and state handler functions. Here is the set associated with the steady superstate: //------------------------------------------------------------------------------ // Led state machine state entry and state handler functions void Led_Enter_Steady(void) { switch(This_Signal) { // Signal determines substate to enter case LED_STEADY_SIG: { if(This_Led->Last_Steady_State == &Led_State_Steady_On) { Led_Enter_Steady_On(); } else { Led_Enter_Steady_Off(); }
  6. Now let's look at how we will initialize our LED state machines on program startup. Here is our next code segment: //------------------------------------------------------------------------------ // The "constructor" and initializer for LED state machines void Led_Ctor(Led *This, uint16_t on_ticks, uint16_t off_ticks, uint8_t bitmask, volatile uint8_t *port); void Led_Initial(void); // Led state machine state entry and state handler functions void Led_Enter_Steady(void); void Led_Enter_Steady_Off(void); void Led_State_Steady_Off(void); void Led_Enter_Steady_On
  7. Now that we have done some of the preliminaries, it's timer to finally get down to some of the C code to implement our LED state machine. //------------------------------------------------------------------------------ // Led.c in project StateMachineBlink6 // // This module contains LED drivers for setting LEDs off, on, or blinking. // It illustrates the implementation of a simple hierarchical state machine. // // Andrew Palm // 2011.10.25 //------------------------------------------------------------------------------ #include #include #include "System.h" #include "Led.h" //---------
  8. In this part we'll look at a couple of header files that are included in our Led.c module. The first is the file System.h which contains some global defines for our program: #ifndef SYSTEM_H #define SYSTEM_H #define FALSE 0 #define TRUE 1 #define NULL 0 // Each tick approximately 15.6 ms with ACLK at 32768 Hz (1 sec = 64 ticks) #define ACLK_FREQ 32768 #define TICK_DIVISOR 512 // In this version, set to match WDT interval #define TICKS_PER_SEC (ACLK_FREQ / TICK_DIVISOR) // Port and I/O pin bitmask definitions #define LEDOUT P1OUT #define LED1_BITMASK BIT0 #define LED2_BITM
  9. In this thread I would like to go though the pieces of code that implement a state machine to control one or more LEDs (3 in this case). It is written to be a device driver with an interface to a client module. You could argue that it is overkill for controlling LEDs, but this is intended to be an example on translating a two-level hierarchical UML statechart into C code. The complete program includes other modules, but for now I just want to concentrate on the LED state machine. First, though, why use a state machine? There are different choices for the structure of embedded software,
  10. Well, I thought I was done with this thread for a while, but after posting the last demo program some improvements came to mind. First, I added an alternate function capability to the pushbuttons. This means that any pushbutton can be set up to be: NORMAL: One function, activated on push and release. ALT_FN: Two functions, one activated on a short push and release, the second activated on a long (1 sec) push and release. ACCEL: One function, activated once on a short push and release, activated repeatedly during a long push. OFF: Does nothing. I also cleaned up the state handl
  11. Attached is a revision of my recently posted project. I added an alternate function capability to the pushbutton code and cleaned up the state handler functions and pushbutton timer handling. Sorry for any inconvenience. I thought I was done with this, but I felt compelled to clean up the code. Andy cStateMachineBlink3.zip
  12. *** Note: An updated version of this port is posted below on this thread. *** I've been posting a series of demo programs on state machines in the state machine thread started by zeke in the General forum. Yesterday I ported the latest version StateMachineBlink2 to an Atmel ATmega168 on a small custom demo board (or the STK500). I posted it as a project in AVR Freaks, but the zip file of the code is below for your convenience. The port was fairly straightforward from the MSP430G2452. There were the usual modifications going from CCS to WinAVR GCC, plus I had to complement the LED o
  13. The MOSFET connections on the new layout in the post now look correct to me. To quote Mr. Burns--"Excellent." As of this moment, the zip file is still incorrect, but get some sleep! Andy
  14. Ooooh, gordon. Very nice. Very nice. I got a private message drawing my attention to this. It's a great motivation to learn how to do the PCB thing. I took a quick look at the schematic vs the pcb layout, and I think there is a problem with the connections to the 2N7000 keying MOSFET. As drawn, the source goes to the TX jack, the gate is grounded, and the drain goes to the MSP. At least that is what it looks like. It should have the gate (center pin) go to the MSP, the source to ground, and the drain to the TX jack. Let me know what you think. The drawing is the only file I
  15. *** Note: There is an upgraded version of this code in a post below in this thread. *** This is the final installment in this series of demo programs for using a state machine approach. This version continues to blink three LEDs, but I've added three pushbuttons to the setup. Each LED and each pushbutton is managed by a separate state machine. Both types of state machine use the same base functions and structures found in StateMachine.h and StateMachine.c that were used in the last version. I've set things up so that each LED blinks with a period of one second, but the duty cycle
×
×
  • Create New...