• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
TheComet

MCU - Threads changing global state

4 posts in this topic

I'm programming a micro controller using C. There is a case when the voltage levels of the circuit become unstable and sink below a predefined threshold (for example when the device is unplugged). When this happens, an external interrupt is triggered to inform the micro controller about it, upon which all I/O modules need to immediately shut down.

 

I'd also like to have a function for polling if a power failure occurred.

 

What is the best way of doing this? Up until now I've always used a global variable to keep track of states, like in the following code:

// NOTE: bools are not supported
static volatile char power_failure = 1;

/*-------------------------------------------------------*/
void enable_sub_circuits( void )
{    /* configures modules and other things like that */
    if( successful )
        power_failure = 0;
}

/*-------------------------------------------------------*/
void disable_sub_circuits( void )
{
    power_failure = 1;
    /* shuts down all modules */
}

/*-------------------------------------------------------*/
char is_power_failure( void )
{
    return power_failure;
}

/*-------------------------------------------------------*/
void _ISR _INT0Interrupt( void )
{
    disable_sub_circuits();
}

_INT0Interrupt is triggered when the power failure occurs, and can be considered to be on a separate "thread", for those who aren't sure what an interrupt is.

 

Is this an acceptable way of doing this? The reason why I ask is, I've never really worked with threads before in my life, and since I've been learning about them recently, I've started to question my methods when handling interrupts on micro controllers.

0

Share this post


Link to post
Share on other sites

Interrupts and threading have a ... complex relationship, even on the most widely popular CPUs. On a microcontroller all bets are off, because the way the interrupt mechanism is implemented in silicon might have different semantics than you expect from, say, a thread running on an x86-compatible CPU. You also have to keep in mind that you have no OS between you to manage scheduling and transitions between execution contexts cleanly.

 

Your idea might work, depending on how the chip is built; but you have one critical flaw: if you're low on voltage, you can't guarantee that the MCU is even going to be able to tick over, let alone power anything beyond the watchdog interrupt. So you can write all kinds of code to poll on that variable and it has no promise that it will ever even get to run.

2

Share this post


Link to post
Share on other sites
Like Apoch said rather well you do have a major issue. In the mcu world you are interfacing with the transistors directly not a OS. If you hit power failure your code will not trigger. One of to things happens on power failure. If at really low power as in partial failure the chip is going to brownout. At total failure the chip is going to turn completely off so there is no longer a clock at all. In the case of brownout you need to trigger a interrupt to wake it up but if you are still in partial failure it will just brownout again. In the case of total failure once power is restored the chip is reset. In either case you will not be able to execute any instructions because you have no clock or a clock which only has enough omph to recognize the wake me up interrupt. There really is no way to oh shit save state unless it happen before the clock goes away.

You also have to note a interrupt is not a thread in any way shape or form. It is a full diversion. A micro can not multitask as it is a single core that processes liniarly. When a interrupt happens everything stops on the chip till it is processed. Minus the clock. So if in a interrupt and another interrupt happens you will miss the second one entirely it is not qeued up to happen next just skipped. Edited by blewisjr
0

Share this post


Link to post
Share on other sites

The voltage source being monitored is a 12V source, and triggers the power failure when it goes below 11.2V. The micro controller is powered by 3.3V from a step-down converter, which gets its power from the 12V source.

 

I have a guaranteed ~50ms before the 12V source is low enough for the 3.3V source to begin failing, which is more than enough time to perform the necessary shutdowns. This has been measured and proven. There's really not much to do in the shutdown routine other than disable all ports and write a few bytes to an internal flash.

 

You also have to note a interrupt is not a thread in any way shape or form. It is a full diversion. A micro can not multitask as it is a single core that processes liniarly. When a interrupt happens everything stops on the chip till it is processed. Minus the clock. So if in a interrupt and another interrupt happens you will miss the second one entirely it is not qeued up to happen next just skipped. 

 

Correct, yes.

 

@all

I can confirm that the code does what it is intended to do, thanks for the input. I take it the code is acceptable?

0

Share this post


Link to post
Share on other sites
On a single core cpu, you know that there is nothing happening during execution, so you don't have all the pitfalls of multi-threading on a multi-core CPU. You can rely on sequential consistency. Interrupts are not in the language standard, so you're not in violation when you rely on their hardware specific properties like that. You do need volatile, because from the point of view of the rest of the program, your interrupt handler is an external event, but you don't need threading primitives.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0