Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm new to embedded programming and I apologise in advance for any confusion.
I need to handle multiple events from different devices connected to a gpio. These events need to be monitored continually. This means that after one event is generated and handled, the code needs to keep monitoring the device for other events.
I understand the concept of interruptions and polling in Linux (the kernel gets an interruption and dispatch it to the handler which goes on up to the callee of an epoll which is inside an infinite loop while(1)-like).
This is fine for one-time, single-event toy models. In a embedded system with limited resources such as the AT91SAM9x5 that runs at 400mhz and has 128mb of ram what can I do ? I believe that the while(1)-like pattern isn't the best choice. I've heard good things about thread pool solution but at the heart of each thread don't we find a while(1) ?
What are my options to attack this problem ?
Thank you in advance !
For an embedded system, the AT91SAM is actually quite "resource rich" rather than resource limited. The idea is the same as if you writing it using Linux: you set up a pin interrupt, and in your interrupt handler, you do some minimal processing and maybe set up some global data so that your main loop "while (1)" can detect the situation and then process the information in the non-interrupt context. Basically you want the interrupt handler to finish as quickly as possible so that it can handle the next interrupt.
In most systems, interrupts can be pended or nested. With systems that allow nested interrupts, you have to make sure that it does not trash the context of the previous interrupt that is still being executed.
The actual communication scheme between the interrupt handler and the main code depends on your requirement. You can even use an RTOS with support for such requirements.
It depends a lot on what is your application and what are your constrains but here are some of the common methods to monitor gpio pins for event
In many of the newer controllers, all GPIO pins are capable of generating a combined interrupt. You can use this to trigger an ISR call on any change on any of the pins and then inside the ISR detect which specific pin triggered it.
If there is nothing else your controller should be doing, then there is nothing wrong is a while(1) loop continuously monitoring all port pins and triggering relevant actions
If none of the above solutions are acceptable, you can perhaps try to load a small OS like FreeRTOS on your controller and then use different tasks to monitor port pins
A lighter version of the above method is to have a configure a timer interrupt and poll for all the port pins inside it. You can then save the state of pins in global variable and use that in the main loop to take relevant actions.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've read a lot of information about X11 graphic system and found a lot of questions about this issue without answer. So let me ask onу more time.
I need classic implementation of hook mechanism (like SetWindowsHookEx) or any other approach in UNIX-like operation systems with ONLY ONE CONDITION : ability to listen events without blocking original event (like XGrabButton and XUngrabButton do).
P.S. Ben, this is Danila. I need help! ®
I've ended up by grabbing source code from Xnee - it allows record all input events, including keyboard and mouse with non-blocking logic. The only restriction is that I have to ask if there any events in loop with 100ms interval, but it's ok for me - there is no processor loading at all.
Not possible do globally (all events/all windows) unless you read low level communication (using pcap or replacing real xserver with proxy that gives you all the data)
To get notification for particular window you change event mask of that window. Server keeps separate copy of event mask for a window per client, and notifies each client interested in events matching mask. For example, if you add PointerMotion bit to root window event mask from your connection you'll get pointer events when mouse moves over root window (given it's visible)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
i try to learn internals of Windows OS.
is SSDT defined as "all system calls address list" ?
is SSDT also interrupt handling mechanism that allows to catch hardware events?
Thanks for answers now.
No, SSDT is not how the OS catches hardware events. If we start at the hardware, say a PCI card for a network adapter, it will have a signal of type interrupt, which via the PCI interface goes to an interrupt controller. In a PC, that would be an "APIC" (Advanced Programmable Interrupt Controller), which in turn is connected to the processor core(s) themselves. Other hardware works in a similar way, so I will use APIC as the example below.
When the OS initializes the APIC, it will give each hardware interrupt a "vector", which goes into the interrupt vector table - each interrupt vector entry will contain an address to which the processor jumps when that interrupt is active. In x86, the interrupt vector table is called "Interrupt Descriptor Table", because the vector is more than a simple address to jump to - it also contains a little bit of extra information about HOW to deal with the interrupt and so on.
So when our network adapter receives a packet of data, it will "pull" the interrupt signal active. The processor will then detect the interrupt, and when it does, the interrupt controller gives the vector to use. The processor looks up the vector, saves the current state, and jumps to the address in the vector.
Inside the vector, the OS will do some "admin" work, and then look up which device driver has asked to be informed about this interrupt, so the OS finds our network adapter driver, and calls it's interrupt handling routine. The interrupt handling code checks the state of the network adapter, sees that it was a "new packet arrived" type of interrupt, reads out the data from the buffer and probably updates some semaphore or similar so that some driver function can start to execute the "we've recieved a new packet" code. Once that is done the interrupt handler returns back to the OS.
On return from the interrupt handling code, the OS will check if any "new process got wakened up", so the process waiting for packets will now be "runnable", and it may switch process at this point, or just mark it as "run this in the future".
The SSDT is used for when an application calls, say, CreateFile, ReadFile, WriteFile and CloseHandle, and any other system calls (there are quite a lot of them). Basically, there is an entry in the SSDT for NtCreateFile, another for NtReadFile and so on - note that NtCreateFile is not exactly the same as CreateFile - it is the part that happens inside the OS Kernel.
Hi guys I need some help. I am making a c++ embedded application in an ARM. I need to get a push button event, I was looking for in internet and I find that the best way to do it is with interruptions. I know that I can set one pin through terminal like this "echo raise > /sys/.../gpio/gpio81/edge". But I need to know how can I get the interrupt from my C++ application when it happend, I just need some example, because I do not know if I have to use some special library.
Thank you guys I hope someone can help me.
Manual 'mechanical' pushbuttons require debouncing. That, and the fact that pushing buttons does not require high I/O performance, means that a GPIO interrupt is an awkward overkill. It can' of course, be done, but it's easier and safer to poll the GPIO port with a timer interrupt, storing the state of the inputs and comparing with the previous state/s. If a GPIO line has changed state for a sufficient number of samples, you have your button event and can act on it.
If you are using a tasking OS, you could hook the existing timer interrupt - it's only a few instructions to handle the GPIO poll so you should not see any noticeable performace hit. If is is decided that the button/s have been pressed/released, you can signal a semaphore so that a waiting thread can quickly process the event.
Hi guys I find the solution what I just wanted is here:
https://developer.ridgerun.com/wiki/index.php/Gpio-int-test.c
Thank you anyways
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Improve this question
I need to perform continous serial write on the serial port till the application is running . Can anyone suggest what is the appropriate step to continously write data in regular time interval in serial communication using win32 .
I have done port open, write, read and close on button click . It means that if i click open button then it opens the port, write button to write, read button to read and close button to close the port. I have used file operation technique on serial port on win32 platform. The steps can be summarised as
open port (createfile)
check port exist or not
set serial parameters
set timeouts
write data (writefile)
read data (readfile)
close port
I have done this to learn about serial communication . but actually i have to write the data continuously until the application is running and at the same time read the data as it becomes available in the serial port. I have not implemented threading concept in my program . Threading is a new topic for me and if i have to use it to obtain my objective, please suggest an appropriate step. My objectives are
write the data continuously till the application is running.
The continuous data should be written at certain time interval . (is there any timer concept in c++).
Read the data from serial port whenever data is available at the port.
Your help will be really appreciated.
stopSignal=CreateEvent(stuff); //signal this with SetEvent() to stop the serial thread.
..
CreateThread(blah,SerialThreadProc,blah);
..
void* SerialThreadProc(){
open port (createfile);
check port exist or not;
set serial parameters;
set timeouts;
do{
write data (writefile);
read data (readfile);
}while(WAIT_TIMEOUT==WaitForSingleObject(stopSignal,commsInterval));//expect yoda flame
close port
};
If you want to do Windows API serial reads and writes concurrently it is necessary to have a read thread and a write thread. And if you are doing this in a GUI program then these threads should be separate from the main GUI thread.
This MSDN article describes the details and mentions a sample code named MTTTY that combines read, write and GUI. Unfortunately, MTTTY does not seem to be available any more on MSDN. Maybe you can find it if you have access to old MSDN library disks.
http://msdn.microsoft.com/en-us/library/ff802693.aspx
I'm using Qt framework which has by default non-blocking I/O to develop an application navigating through several web pages (online stores) and carrying out different actions on these pages. I'm "mapping" specific web page to a state machine which I use to navigate through this page.
This state machine has these transitions;
Connect, LogIn, Query, LogOut, Disconnect
and these states;
Start, Connecting, Connected, LoggingIn, LoggedIn, Querying, QueryDone, LoggingOut, LoggedOut, Disconnecting, Disconnected
Transitions from *ing to *ed states (Connecting->Connected), are due to LoadFinished asynchronous network events received from network object when currently requested url is loaded. Transitions from *ed to *ing states (Connected->LoggingIn) are due to events send by me.
I want to be able to send several events (commands) to this machine (like Connect, LogIn, Query("productA"), Query("productB"), LogOut, LogIn, Query("productC"), LogOut, Disconnect) at once and have it process them. I don't want to block waiting for the machine to finish processing all events I sent to it. The problem is they have to be interleaved with the above mentioned network events informing machine about the url being downloaded. Without interleaving machine can't advance its state (and process my events) because advancing from *ing to *ed occurs only after receiving network type of event.
How can I achieve my design goal?
EDIT
The state machine I'm using has its own event loop and events are not queued in it so could be missed by machine if they come when the machine is busy.
Network I/O events are not posted directly to neither the state machine nor the event queue I'm using. They are posted to my code (handler) and I have to handle them. I can forward them as I wish but please have in mind remark no. 1.
Take a look at my answer to this question where I described my current design in details. The question is if and how can I improve this design by making it
More robust
Simpler
Sounds like you want the state machine to have an event queue. Queue up the events, start processing the first one, and when that completes pull the next event off the queue and start on that. So instead of the state machine being driven by the client code directly, it's driven by the queue.
This means that any logic which involves using the result of one transition in the next one has to be in the machine. For example, if the "login complete" page tells you where to go next. If that's not possible, then the event could perhaps include a callback which the machine can call, to return whatever it needs to know.
Asking this question I already had a working design which I didn't want to write about not to skew answers in any direction :) I'm going to describe in this pseudo answer what the design I have is.
In addition to the state machine I have a queue of events. Instead of posting events directly to the machine I'm placing them in the queue. There is however problem with network events which are asynchronous and come in any moment. If the queue is not empty and a network event comes I can't place it in the queue because the machine will be stuck waiting for it before processing events already in the queue. And the machine will wait forever because this network event is waiting behind all events placed in the queue earlier.
To overcome this problem I have two types of messages; normal and priority ones. Normal ones are those send by me and priority ones are all network ones. When I get network event I don't place it in the queue but instead I send it directly to the machine. This way it can finish its current task and progress to the next state before pulling the next event from the queue of events.
It works designed this way only because there is exactly 1:1 interleave of my events and network events. Because of this when the machine is waiting for a network event it's not busy doing anything (so it's ready to accept it and does not miss it) and vice versa - when the machine waits for my task it's only waiting for my task and not another network one.
I asked this question in hope for some more simple design than what I have now.
Strictly speaking, you can't. Because you only have state "Connecting", you don't know whether you need top login afterwards. You'd have to introduce a state "ConnectingWithIntentToLogin" to represent the result of a "Connect, then Login" event from the Start state.
Naturally there will be a lot of overlap between the "Connecting" and the "ConnectingWithIntentToLogin" states. This is most easily achieved by a state machine architecture that supports state hierarchies.
--- edit ---
Reading your later reactions, it's now clear what your actual problem is.
You do need extra state, obviously, whether that's ingrained in the FSM or outside it in a separate queue. Let's follow the model you prefer, with extra events in a queue. The rick here is that you're wondering how to "interleave" those queued events vis-a-vis the realtime events. You don't - events from the queue are actively extracted when entering specific states. In your case, those would be the "*ed" states like "Connected". Only when the queue is empty would you stay in the "Connected" state.
If you don't want to block, that means you don't care about the network replies. If on the other hand the replies interest you, you have to block waiting for them. Trying to design your FSM otherwise will quickly lead to your automaton's size reaching infinity.
How about moving the state machine to a different thread, i. e. QThread. I would implent a input queue in the state machine so I could send queries non blocking and a output queue to read the results of the queries. You could even call back a slotted function in your main thread via connect(...) if a result of a query arrives, Qt is thread safe in this regard.
This way your state machine could block as long as it needs without blocking your main program.
Sounds like you just want to do a list of blocking I/O in the background.
So have a thread execute:
while( !commands.empty() )
{
command = command.pop_back();
switch( command )
{
Connect:
DoBlockingConnect();
break;
...
}
}
NotifySenderDone();