How to can change channel check rate of a node in during runtime on Contiki OS? I use the ContikiMAC RDC protocol.
This functionality is not supported by the OS.
If you want, you can implement this yourself by changing NETSTACK_RDC_CHANNEL_CHECK_RATE from a preprocessor definition to a variable and doing the same with CYCLE_TIME (in contikimac.c).
However, the current limitation is there for a reason. If different nodes in a network have different radio duty cycles, ContikiMAC will fail to work as intended. It's not a good idea to change the RDC unless you do it for all nodes at the same time.
Related
I have a system with multiple subsystems communicating with CANOpen. There is a main unit with a screen (for men-machine interface and stuff) and sub-units for minor operations(like sample button status, manage power, take measurements...).
We defined a CANOpen based communication protocol for this system. Subsystems share their conditions periodically with TPDO messages and do stuff according to main unit's commands sent with RPDO messages. And also some NMTs are in use too.
So I've been asked to add a new command to this protocol, zeroize. This command shall be sent broadcast and it shall cause everybody to delete softwares. What is the right way to do this?
Maybe I can use a RPDO? Are we allowed to define new NMT commands in CANopen? Maybe I can do it with NMT but by using a new commandt hat is not in use already?
Thanks in advance
Ip.
It is a bit confusing what you mean with TPDO and RPDO since the main unit's TPDO is going to be the peripheral units' RPDO and vice versa. But yes, the correct way to send out some custom broadcast message would be with a PDO.
Although, depending on what you mean with "delete software", CANopen might provide a mean for it. There are the save (OD 1010h) and load (OD 1011h) registers in the object dictionary. Save is to be used for the purpose of storing all CANopen communication (PDO configuration, mapping etc) in non-volatile memory. And load is used to restore CANopen parameters to factory defaults. These should however not be used to save/load application-specific settings.
You are not allowed to define new NMT commands.
Objects 1010h and 1011h can be used to reset the values in the object dictionary. If you really want to delete the software, the firmware upgrade protocol from CiA 302-3 might help. Writing 00h (Stop program) followed by 03h (Clear program) to object 1F51h sub-index 1 on the slave will delete the application. Whether it's actually "zeroed out" depends on the implementation. You'll need two SDO requests per slave for this though. The standard specifies that object 1F51h cannot be PDO mapped. Although that requirement may not be enforced for your devices, in which case you could achieve broadcast "zeroing" with two PDOs.
Got a general question regarding the GPIOs on P9 of the beaglebone black. For instance, I would like to use the UART1 (RX and TX) for a R232 communication and use the I2C2 (SDA and SCL) for a sensor, using a C language application running on Linux. The problem is that the UART1 (RTS and CTS) signals are on those pins, can these features be deactivated (software)? and therefore use the UART1 and I2C2 at the same time?
PIN 19 : UART1_rtsn - I2C2_SCL
PIN 20 : UART1_Ctsn - I2C2_SDA
Next question, the same applies for SPI1 (CS0 and CS1), these pins are also on I2C2 (SDA and SCL).
PIN 19 : I2C2_SCL - spi1_cs1
PIN 20 : I2C2_SDA - spi1_cs0
So the general question : Can all 3 units, UART1-SPI1-I2C2 all run at the same time with no conflict on pins using the P9 header of the bbb?
Thank you very much for your answers
JH
It is technically feasable although when you start foraging into custom pin assignements you have to deal with alot of complexities to get everything up and working. There are many tables around the internet with the references as to which pins can do what. My favorite so far are these two : http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP8Header.pdf, http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP9Header.pdf
If you read these, you can see that each pin can take multiple different functions depending on configuration. These are set to the defaults by the linux kernel at boot time but you can modify the defaults using device tree overlays. The whole process is a little envolved for a single answer here but in short, to do what you want, you would need to modify and recompile the device tree overlay that the kernel loads for the device you want to change the pin assignements off.
Although there are some limits, for example, the beaglebone images are all configured to use I2C2 for identifying capes. So you can theoretically change it's pin assignments but then you shouldn't expect capes to be identified and configured properly when you do. In your example above, the UART1 and I2C2 work without conflict using their default configuration (UART1 only has Rx & TX by default). The SPI1 is a little more work. It's default configuration shares pins with the sound card (HDMI) that must be disabled to get it to work athough it does not conflict with ether UART1 or I2C2 by default.
Notice that each of these pins can have multiple functions but can only by one at any one time. Therefore, if a pin is set to use a given module (say UART1) it will not be affected by another module that can theoretically output on that pin with a different function mode. The kernel will complain if you try to use a pin for 2 functions simultaneously so you can try to load the overlays and see if it conflicts by default. Basically, if the kernel accepts to load the tree overlay, you can generally assume that it does not conflict with any other that is already loaded.
I think the other answer misinterpreted the question, and addresses configuration of the pins to perform a function of the possible mappings available to that pin. Yes, this is easily possible and is largely the point of the design.
With regards to the actual question, the answer is that it's possible but it's going to be very difficult and is most likely not feasible. And only one communication protocol will be able to be used at a time. Additionally, the spi pins are chip select pins, which require either an asserted or de-asserted state, so any kind of i2c clock or data signal will render the chip select non functional.
For i2c/uart, it would require reconfiguration of the pins and software mappings on the fly, and it will only be able to perform one of the possible functions at a time. It will also require software on all sides of the busses to be able to understand what mode the pins are in ie i2c or uart, with mutually separate and smart protocols so that none of the devices on the bus react undesirably to the garbage that will be on the bus when the bus is being used for another operation mode.
I have an application which has sound. I have a global property to mute the sound. The problem is, there's so many different things which can make sound, I would hate to iterate through different class types and mute/unmute their sound. Instead, I'm looking for a way to mute the sound on a global application level. I don't mean muting the entire system volume either.
One scenario: In Windows 7, you can open the Volume Mixer and adjust the volume of individual applications. While I don't intend to change this actual particular value (as I know it's Windows 7 specific), I would like to change the volume of everything in my application all at once. I would also need the ability to completely mute the sound of everything in my application. I need this ability to be compatible with Windows XP and above. I am assuming it will involve Windows API calls, but I have no idea what calls to make.
XP does not support per-application volume control. That capability was added in Vista. So what you are attempting to do cannot be done in XP by fair means.
There is software called IndieVolume that retro fits per-app volume control to XP. I can only imagine it does so by means of low-level hacking, DLL injection and so on. I doubt that's really an option for you.
What you're asking for isn't possible on XP; the OS simply does not support per-application volume levels.
You can accomplish what you want by creating a settings class that keeps things like SoundActive: Boolean or PlaySounds: Boolean or something similar. Place it in it's own unit, and have an initialization section that creates an instance of it and a finalization section that frees it (making it effectively a collection of global values).
Each unit that needs access to these settings simply uses the unit containing them, and adjusts behavior accordingly. So each of your child classes or forms or whatever would just need a check added:
if CurrentSettings.PlaySounds then
// Code that makes sounds, plays music, whatever.
The settings class can also contain methods that keep track of the current volume level (on XP, the system-wide level), and methods to increase or decrease volume using the MMSystem volume functions (there are tons of examples here and through Google of doing so). Your app can then use the OnActivate and OnDeactivate events to set the volume level when your app gains focus, and restore it to the proper volume when your app loses focus.
In Vista and higher, you can use the IAudioEndPointVolume interface I mentioned earlier and either the GetMasterVolumeLevel or SetMasterVolumeLevel methods to control system wide volume (I have an example of doing this, along with the appropriate MMDevAPI interface definitions) or device level volume (using IMMDevioce.Activate to select the proper device first and then the above IAudioEndPointVolume methods on the device interface received from IMMDevice.Activate in the ppInterface parameter).
For individual applications, you use the ISimpleAudioVolume interface, which has four methods: GetMasterVolume and SetMasterVolume, which control the volume level for your application's audio session, and GetMute and SetMute to allow you to retrieve the current mute flag value or set it respectively. (Larry Osterman of MS, who was one of the developers who worked on the new audio support in Vista and Win7, has a great starting point article on his blog about the types of audio in the new API and when to use each of them.)
It's conceptually possible to determine at runtime which operating system you're using, and to programmatically switch between using the MMSystem functionality on XP and earlier, and the MMDevAPI functionality on Vista and higher. Expecting someone here to provide the code for doing so is a little unreasonable, however. The links I've provided should get you started on the right track, and when you run into snags along the way specific help in working through those snags would be great questions.
This is a little off the beaten path. I've got a DLink DWL-G520 card I'm using under OpenBSD and it works fine. What I want to do is be able to access the radio part of it. Why? I want to use it in a radio telescope. It's a 2.4 GHz receiver with an external antenna connector. I want to connect some coax, some amplifiers, and an old TV dish and point the dish at the sky. It has an RSSI signal and variable RF gain (which it adjusts, from what I can find) so all I'd need to do is record those over time while pointed at a certain spot in the sky. I don't need to control the frequency really since most natural events are broadband.
I'm poking through the OpenBSD ath driver following nested structs but I don't want any of the normal network stuff, which is most of what the driver does. dmesg identifies it as an AR5212 which according to the Atheros PDF is always paired with an AR2112 radio. Is there any easier way than wading through PCI stuff to see what my options are? I need to turn the transmitter off so it doesn't fry my amps too. Trying to find low level documentation is about impossible from what I've seen. Ultimately I'd like to have this work with other WiFi cards too, but I'll start with this one. I've got a Cistron with an external antenna connector also.
Alan, ab1jx
I have an application which has sound. I have a global property to mute the sound. The problem is, there's so many different things which can make sound, I would hate to iterate through different class types and mute/unmute their sound. Instead, I'm looking for a way to mute the sound on a global application level. I don't mean muting the entire system volume either.
One scenario: In Windows 7, you can open the Volume Mixer and adjust the volume of individual applications. While I don't intend to change this actual particular value (as I know it's Windows 7 specific), I would like to change the volume of everything in my application all at once. I would also need the ability to completely mute the sound of everything in my application. I need this ability to be compatible with Windows XP and above. I am assuming it will involve Windows API calls, but I have no idea what calls to make.
XP does not support per-application volume control. That capability was added in Vista. So what you are attempting to do cannot be done in XP by fair means.
There is software called IndieVolume that retro fits per-app volume control to XP. I can only imagine it does so by means of low-level hacking, DLL injection and so on. I doubt that's really an option for you.
What you're asking for isn't possible on XP; the OS simply does not support per-application volume levels.
You can accomplish what you want by creating a settings class that keeps things like SoundActive: Boolean or PlaySounds: Boolean or something similar. Place it in it's own unit, and have an initialization section that creates an instance of it and a finalization section that frees it (making it effectively a collection of global values).
Each unit that needs access to these settings simply uses the unit containing them, and adjusts behavior accordingly. So each of your child classes or forms or whatever would just need a check added:
if CurrentSettings.PlaySounds then
// Code that makes sounds, plays music, whatever.
The settings class can also contain methods that keep track of the current volume level (on XP, the system-wide level), and methods to increase or decrease volume using the MMSystem volume functions (there are tons of examples here and through Google of doing so). Your app can then use the OnActivate and OnDeactivate events to set the volume level when your app gains focus, and restore it to the proper volume when your app loses focus.
In Vista and higher, you can use the IAudioEndPointVolume interface I mentioned earlier and either the GetMasterVolumeLevel or SetMasterVolumeLevel methods to control system wide volume (I have an example of doing this, along with the appropriate MMDevAPI interface definitions) or device level volume (using IMMDevioce.Activate to select the proper device first and then the above IAudioEndPointVolume methods on the device interface received from IMMDevice.Activate in the ppInterface parameter).
For individual applications, you use the ISimpleAudioVolume interface, which has four methods: GetMasterVolume and SetMasterVolume, which control the volume level for your application's audio session, and GetMute and SetMute to allow you to retrieve the current mute flag value or set it respectively. (Larry Osterman of MS, who was one of the developers who worked on the new audio support in Vista and Win7, has a great starting point article on his blog about the types of audio in the new API and when to use each of them.)
It's conceptually possible to determine at runtime which operating system you're using, and to programmatically switch between using the MMSystem functionality on XP and earlier, and the MMDevAPI functionality on Vista and higher. Expecting someone here to provide the code for doing so is a little unreasonable, however. The links I've provided should get you started on the right track, and when you run into snags along the way specific help in working through those snags would be great questions.