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 9 years ago.
Improve this question
A heads up, i am very new to audio so please bear with me =)
I am trying to interpret audio signals into an AVR (its a classical myAVR MK2 board). Now normally, the interupt signal is always some kind of switch. So if i press this swich, go into that interupt.
My goal is to interpret audio signals via microphone into the board, and have the board react to it. My first question is, when sending the microphone signal, do i have to put it through the A/D Converter, since technically it is an anolag signal ??
My second and more complicated question is, how would i actually interpret the audio signal coming in?
For example, if i scream "GREEN" then what ever the programm was doing should be stopped, the interupt should be called and the green LED should come on. Now the mic is preatty much always on ... how do i control so that only if GREEN is said, the interupt signal is sent. I dont want him constantly going in and out of the interupts just because someone made some noise ...
Would i have to save "GREEN" as a bit-combination somewhere and compare the incoming signal with the saved bits ... or ??
Some answers:
...do i have to put it through the A/D Converter, since technically it is an anolag signal ?
Yes, digital chips may fry when exposed to analog signals.
Be aware that you may have delay some time after starting the ADC before the signals are accurate.
how would i actually interpret the audio signal coming in?
Basically you have digital values coming in at a frequency. You will need to store those values and then analyze them. You must trade memory capacity/usage for accuracy. The more samples you take, the better your data and results; but this occupies more memory.
You will also need to filter out noise from the signal and from layered sounds.
You may get some benefits from researching on FFTs.
You should compare using "fuzzy logic" because in the real world, nothing is exact; for example your voice signal could be +/- 30 counts and still be "correct".
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 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.
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 5 years ago.
Improve this question
I want to develope an application with Qt and opencv , in order to process all the frames comming from a camera.
I have 2 Qthread, one for capturing image and the other for processing.
the processing thread is a little slow , so in order to process all the frames , I need to have a frame buffer.
I really have no idea how to simply impelement a frame buffer.
any help would be apprecieted.
You'll want to create your threads to run asynchronously. When you capture the image, add it to a std::queue using the capture thread, and then let your processing thread pull from queue. Try to use pointers as much as you can for the images to cut down on memory use and processing time. Make sure you're thread safe and use std::Mutex when appropriate.
Since you are using QT, you could use QQueue for the queue and QMutex for the mutex.
if your processing thread is slower then the frame capturing period, meaning that your code will go out of memory eventually. You should consider decreasing capturing frame rate, dropping frames or maybe decreasing the frame resolution.
As for the buffer, go for a thread safe circular queue for frames, where, the capturing thread will be producer and processing thread will be the consumer. If the queue is full (it will be obviously) you have two options: (1) remove the oldest (but not being processed) one and add the new one. (2) Just drop the newest frame, which is pretty easy to implement.
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.
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 9 years ago.
Improve this question
I have a motor connected to my computer, which is connected through CAN to the motor. Basically, I have a USB-to-CAN adapter, to which I connect a USB cable from my computer. Then, from the adapter, the motor is connected through CAN.
Now, I wish to send data to the motor- I already know what sequence of bytes I need to send, but I'm not sure what commands to use to "talk" to my motor that is connected through CAN. I have been able to send data by direct USB connection from my computer to motor (using the WriteFile command in C++), but this method does not work for CAN.
Are there any libraries/functions that I can use to talk to my motor via CAN in C++?
Since you cannot connect a motor directly to a CAN bus, there must be some sort of motor controller, drive or I/O controller between the bus. Details of this device are required in order to advise on a more than fundamental level.
CAN itself does not define an application layer protocol, and several application protocols exist for CAN, such as CANopen, DeviceNet and SDS. Your device may use such a protocol or possibly something entirely proprietary. Your starting point should be the documentation for your I/O device.
For testing, most PC CAN adapter manufacturers will provide some sort of debug or development tool that allows you to construct and send individual messages and message sequences at a low-level; such a tool will allow you to verify the operation of the bus and I/O device.