I am simulating a network with 2 wireless hosts and 1 Access point. During runtime a node sets the Access Point's transmit power to zero (to turn it off) by accessing the module and using setDoubleValue(0). But the new values never takes effect. AP's msgs continue to reach the nodes. What am I doing wrong here? I want to turn access point off while the simulation is running. Please help.
cSimulation *currentSimulation = getSimulation();
cModule *tx = nullptr;
tx=currentSimulation->getModuleByPath("agranet.ap.wlan[0].radio.transmitter");
tx->par("power").setDoubleValue(0);
//cPar& po = tx->par("power");
//po.setDoubleValue(0);
I want to turn the access point off while simulation is running.
You cannot change the power parameter after initialization because it is a non-volatile parameter, so its value is read at initialization and cached afterwards. You can manipulate only volatile NED parameters where the C++ code is already prepared for this.
On the other hand, what you are trying to achieve is to disable a node at a certain time, which is what ScenaioManager is for:
https://inet.omnetpp.org/docs/users-guide/ch-scenario-scripting.html
Related
somehow when i am running my code, it seems like one GPIO Port isn't being initialized, meanwhile if i am debugging, it is.
I am initializing two sensors:
struct MAX31856_t max31856_temperature_sensor_heater_1 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_0_CS_GPIO_Port, TEMP_SENSOR_0_CS_Pin), &spi1));
struct MAX31856_t max31856_temperature_sensor_heater_2 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_1_CS_GPIO_Port, TEMP_SENSOR_1_CS_Pin), &spi1));
Sensor Heater 1 is not getting any Information, Sensor Heater 2 is getting Informations. Now if i swap the Name of the Heaters:
struct MAX31856_t max31856_temperature_sensor_heater_2 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_0_CS_GPIO_Port, TEMP_SENSOR_0_CS_Pin), &spi1));
struct MAX31856_t max31856_temperature_sensor_heater_1 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(TEMP_SENSOR_1_CS_GPIO_Port, TEMP_SENSOR_1_CS_Pin), &spi1));
and run the code in the debugger, Sensor Heater 1 and 2 are getting Informations.
How can this happen? I was thinking about a timing problem, but since it is working in the debugger, i don't really know what to do.
Provided that you are debugging and/or running the same binary. Debugging is mostly the same as running except if you halt the processor (es breakpoints).
In that case...
some peripherals could continue to run or be halted togheder with the cpu, the behaviour is some cases can be configured. (timers, watchdog...)
some interrupts can be lost.
some hardware buffers can overflow and data can be lost (if you don't use any flow control in your IO)
How do you run the code in debug mode? Do you have breakpoints somewhere?
You (OP) are right about it being most likely a timing problem, and probably related to physical SPI transmission. Because your line of code to send/receive something over SPI has already executed in the MCU, but physically the bits and bytes are still being transmitted on the line, while MCU is already calling the next SPI function, so one of the transmissions will fail. Try adding some delay after SPI transmission code. If things work after that, then it's the timing of SPI peripheral, and you need to add a check that there is no SPI transmission already in place before you call a functions to send/receive something.
You can do while(transmission) (pseudocode, replace with actual check if SPI transmission is going on) to wait until the previous transmission ends to call the next one.
I am developing a simple device driver for study. With a lot of testing, I am creating so many errors which finally leads my computer to blue screen. I am sure that the reason for this is memory crash. So now I want to check if my code can access to Kernel memory before going further.
My question is what function can check whether it is accessible or not in kernel memory. For instance, there is a pointer structure with two fields and I want to access the first field which is also a pointer but do now know whether it really has an accessible value or just trash value.
In this given context, I need to check it out to make sure that I am not getting blue screen.
Thanks in advance!
this is impossible for kernel memory. you must know exactly are kernel address is valid and will be valid during access. if you get address from user mode - you can and must use ProbeForRead or ProbeForWrite. but this is only for user-mode buffer. for any kernel memory (even valid and resident) this function just raise exception. from invalid access to kernel memory address no any protection. try - except handler not help here - you just got PAGE_FAULT_IN_NONPAGED_AREA bug check
For instance, there is a pointer structure with two fields and I want
to access the first field which is also a pointer but do now know
whether it really has an accessible value or just trash value.
from where you got this pointer ? who fill this structure ? you must not check. you must know at begin that this pointer is valid and context of structure will be valid during time you use it. otherwise your code already wrong and buggy
I am a newbie to Linux. Can some one Please explain me about the differences between this functions. and the sequence of execution.
I had a look # this query.
Probe method device drivers
and got some idea about probe.
I have understanding the resume function is called after suspend. Please guide me in understanding the functionality.
Both are different in perspect:
Probe:
Will get called when you are registering your device to for the first time.(Gets called (a). during device boot or (b). calling insmod/modprob).
Resume:
It is a handler function routine part of the driver, you may supply function for the handler or leav(depends on your driver implementation).
So in simple words - Probe gets called only once (During registration of driver)
- Resume gets called depending on
(a) whether you have supplied function routine for handler
(b) If so then on suspend it gets called. (so n times it will get called for n times it gets suspended)
I guess there is enough information in a thread that you're mentioned. But I'll try to explain in other words.
Probe function is a part of initialization sequence of linux device driver. Usually, an Init function contains some sort of driver registration calls, and one of linux layers would call probe() later. But only driver's author can decide what part of code should be executed in init() or probe() : it depends on your device hardware specifications and corresponding linux layer (PCI, SPI, etc) features. By the way, in your driver you're not obliged to use any existing layer, so it is not mandatory to have probe().
Conserning suspend-resume: this pair of functions should take a place only when you're want to implement any energy-saving features of your device. Suspend() tells that you can switch off something (if have any) to preserve energy. Resume() tells that you should switch in on again. Have no such options? Do not implement suspend-resume.
I have a question regarding the persistence (storage) of data values in a PIC24F, even after the PIC has been turned off.
I have read through the datasheet(s), but am confused regarding the difference of the EEPROM and Flash memory.
For example, say I have a variable "x", is there a way for the value of "x" to persist even after the PIC has been shut off? I know programs can persist in the flash memory so long as the code is compiled in Stand Alone Operation (COE_OFF). However, I am specifically wondering about data values.
If I make the program memory and the memory for the data value non-volatile, will it persist even when the power is off?
Do I need to declare the value as "static", example: static int x; ?
Or am I wrong and there isn't any way for a data value to persist even after the power has been turned off?
Thanks for the help and clarifications!
You must write to flash in pages, using the TBLWTL and TBLWTH instructions, as you have read in the datasheet for your device. This is typically for updating your software through a bootloader, and it does not sound like this is what you are after.
To access the EEPROM you can do it in smaller units, and there are compiler convenience macros for declaring where in the memory map a variable should live. You can specify that the variable lives in EEPROM and the compiler will generate instructions for accessing and updating that for you. You can also use the compiler intrinsics or the TBL instructions for reading it directly.
The declaration will probably look something like:
unsigned __attribute__((space(eedata), aligned(2)) my_eeprom_variable;
Look at the generated assembler to see what the compiler does when you access the variable.
Declaring a variable static only has traditional C semantics; it controls the scope of the variable and the initialisation rules.
Contents of registers and RAM variables are lost when power is turned off. Flash and EEPROM are both persistent. Flash can only be erased in large blocks - 128K and up depending on the type that you have. EEPROM words can be individually read or written. If you have EEPROM, that's your best bet for saving a small amount of data. Usually you have to read and write EEPROM serially.
thanks for the responses!
After some other suggestions I read through the MPLAB C30 Compiler datasheet again, and found the "persistent" attribute.
Per the datasheet:
"The persistent attribute specifies that the variable should not be initialized or cleared at startup. A variable with the persistent attribute could be used to store state information that will remain valid after a device reset."
I'm going to try using this to see if it will work.
This is my code:
UNICODE_STRING symbol;
WCHAR ntNameBuffer[128];
swprintf(ntNameBuffer, L"\\Device\\Harddisk1\\Partition1");
RtlInitUnicodeString(&symbol, ntNameBuffer);
KdPrint(("OSNVss:symbol is %ws\n",symbol.Buffer));
status = IoGetDeviceObjectPointer(&symbol,
FILE_READ_DATA,
&pDiskFileObject,
&pDiskDeviceObject);
My driver is next-lower-level of \\Device\\Harddisk1\\Partition1.
When I call IoGetDeviceObjectPointer it will fail and no status returns and it not continue do remaining code.
When I use windbg debug this, it will break with a intelpm.sys;
If I change the objectname to "\\Device\\Harddisk1\\Partition2" (the partition2 is really existing), it will success call
If I change objectname to "\\Device\\Harddisk1\\Partition3", (the partition3 is not existing), it failed and return status = 0xc0000034, mean objectname is not existing.
Does anybody know why when I use object "\\Device\\Harddisk1\\Partition1" it fails and no return status? thanks very much!
First and foremost: what are you trying to achieve and what driver model are you using? What bitness, what OS versions are targeted and on which OS version does it fail? Furthermore: you are at the correct IRQL for the call and is running inside a system thread, right? From which of your driver's entry points (IRP_MJ_*, DriverEntry ...) are you calling this code?
Anyway, was re-reading the docs on this function. Noting in particular the part:
The IoGetDeviceObjectPointer routine returns a pointer to the top object in the named device object's stack and a pointer to the
corresponding file object, if the requested access to the objects can
be granted.
and:
IoGetDeviceObjectPointer establishes a "connection" between the caller
and the next-lower-level driver. A successful caller can use the
returned device object pointer to initialize its own device objects.
It can also be used as as an argument to IoAttachDeviceToDeviceStack,
IoCallDriver, and any routine that creates IRPs for lower drivers. The
returned pointer is a required argument to IoCallDriver.
You don't say, but if you are doing this on a 32bit system, it may be worthwhile tracking down what's going on with IrpTracker. However, my guess is that said "connection" or rather the request for it gets somehow swallowed by the next-lower-level driver or so.
It is also hard to say what kind of driver you are writing here (and yes, this can be important).
Try not just breaking at a particular point before or after the fact but rather follow the stack that the IRP would travel downwards in the target device object's stack.
But thinking about it, you probably aren't attached to the stack at all (for whatever reason). Could it be that you actually should be using IoGetDiskDeviceObject instead, in order to get the actual underlying device object (at the bottom of the stack) and not a reference to the top-level object attached?
Last but not least: don't forget you can also ask this question over on the OSR mailing lists. There are plenty of seasoned professionals there who may have run into the exact same problem (assuming you are doing all of the things correct that I asked about).
thanks everyone , I solve this problem; what cause this problem is it becoming synchronous; when I
call IoGetDeviceObjectPointer , it will generate an new Irp IRP_MJ_WRITER which pass though from high level, when this irp reach my driver, my thread which handle IRP is the same thread whilch call IoGetDeviceObjectPointer ,so it become drop-dead halt;