what exactly is the process of device initialization? In programming we initialize variables by assigning them some initial value. but what is the need to initialize a device in the first place and what values to initialize it with?
Device initialization is doing whatever steps are required to bring a device into a working state. It has got little to do with variable initialization. The process is specific for every device, there are no magic values that would initialize any device that you come across.
Device initialisation is exactly what it sounds like, preparing a device for use.
For example, when booting a PC, you may need to initialise the keyboard device to make it ready to accept keystrokes from the user.
Operating systems will tend to perform this activity on all devices they detect, hard drives, CD-ROMS, keyboard, video devices and so on, to bring them to a useful state for later use.
Related
I'm working on an ESP32 based project that will involve OTA flashes of the ESP.
I know that you can set up different partitions on an ESP32. I'm wondering if it's possible for my code on one partition to then execute code on another partition? (For my usage, I don't need data passed back and forth - just execution handed off from one partition to the other and than given back after execution)
Yes, assuming you don't have Flash encryption with different keys or other tricky copy protection mechanisms enabled. Partitions on Flash are a completely abstract concept for the developers' peace of mind. The CPU doesn't know and doesn't care - it will execute code from anywhere in Flash if told to jump to it.
The challenge here is that you need to convince the linker to find and call a method from an external, hard-coded address. And you need to make sure said method is actually there :) Since this is not a standard solution, you likely won't find a tutorial but have to know your linker really well :)
There's some useful stuff in the ESP IDF linker documentation and probably the GNU linker documentation, if I could find it :)
You will need some freeRTOS information.
I will not write any code here but I can give you some ideas on what you are trying to achieve.
Assume you have two tasks and a digital pin, which is pulled high by the setup() function. You define the task handler for each task. Now you want to change the current running program to some other program, you will check if the digital pin has been LOW for 5 seconds if that's the case , you can use the vTaskSuspend() function in the primary task by providing it the handler of your current task and suspend your current task. Be sure to resume your OTA task by vTaskResume() function before calling vTaskSuspend() . When you have completed the update, restart the esp32 by calling ESP.restart().
If you want to abort the OTA task just pull the same digital pin LOW and using the above method in your OTA task also, you can switch back to your primary task.
I've been working on a device that includes an ESP32. I set up a secure GATT server similar to the Secure Gatt Server Example with a custom service with Man in the Middle (MITM) based encryption. Currently pairing setup is Just Works, and when a client connects to the device they are prompted to pair and thus are bonded with key exchange (although it looks like Justworks disables MITM when I did more investigation for this question).
We do not have any real IO except for one button on the device, but I would like to limit pairing to a certain window of time after the Pairing button is pressed, or to have a "pairing mode" that the device enters (I have worked on another device that may have more of a classic pairing mode that was easier to work with). I know that's not explicitly part of the IDF API, but I'm looking for some guidance on how to approach something like a "pairing mode."
Would setting the IO capability to ESP_IO_CAP_IO work for using a button for the Yes/No? I don't see anything relevant in the documentation about how to configure this. In fact the enum does not appear elsewhere in the IDF sourcecode, nor does the mentioned relevant file stack/btm_api.h help.
Is there a way to disable / enable pairing on command? Would it be some type of change to advertising?
I would like to copy data from host to device and run some kernels in parallel. There seems to be conflicting information on whether running a cublasSetMatrixAsync function call will be blocking on the default stream?
I am seeing it block execution and am wondering what the correct way to use it is. Should cublasSetMatrixAsync be on the non-default stream? If so, is there an easy way for default stream to block if it needs the matrix on device for some kernel in the future?
Yes, it has blocking behavior.
From the programming guide:
Two commands from different streams cannot run concurrently if any one of the following operations is issued in-between them by the host thread:
...
• any CUDA command to the default stream,
cublasSetMatrixAsync is not exempt from this.
A general rule for CUDA concurrency is, if you want it, don't use the default stream.
is there an easy way for default stream to block if it needs the matrix on device for some kernel in the future?
issue a cudaDeviceSynchronize()
That will force all cuda device activity, in any stream associated with that device, to finish before any subsequent commands, issued to any stream associated with that device, can begin.
I need to implement asynchronous read/write support in my linux device driver.
The user space program should get a asynchronous signal from device driver, indicating that the driver has data and the user space program can read it.
Below are the options i found by googling and from LDD book.
[1] Implement poll-read. The driver returns status of read/write queue. The user space program can then decide whether to perform read/write on the device.
[2] Implement async notifications. The device driver is able to send a signal to user space when data is ready on driver side. The user space program can then read the data.
However i have seen developers using select_read call with tty driver. Not sure what support should be added to my existing device driver for using select_read from user space.
Need your advice on the most efficient methods from the above.
Asynchronouse notifications (signals) are harder to use, so it is usually recommended to use poll() instead.
You do not need to separately implement select(), both poll() and select() are user-space interfaces that map to your driver's .poll callback in the kernel.
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
Has anyone experienced this before? If so what did you do to fix/workaround the problem?
Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
Flow control is not used.
Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.