Could you point me the opcodes for various mesh messaging? For example, I see that 0x8201 is the opcode for Generic OnOff get. I would like to see complete list (sensor model messaging etc).
Rgds,
Venkat.
The full list is available in the Bluetooth SIG website. Please have a look in the Mesh Model Specification v1.0.1, Chapter 7: Summary, Section 7.1: Table Summary (page 301 of 307).
Related
I am rather new to uC programming and have hit a wall trying to find the base register address of comparator peripherals for the stm32f303k8. I couldn't find the info in either the reference manual, datasheet, or programming manual, as well as many other hits on various searches.
I've seen that if a clock is enabled for the comparators it runs on the AHB clock, but a separate diagram shows the AHB feeding into both APB1 and APB2 and the comparators were specifically placed under the APB2. I am quite confused and would welcome any help (short of using libraries!), even a search string pointing me in the right direction.
You find the answer in the
reference manual
of your STM32F303k8 rather than in its
datasheet.
In section 3.2.2 of the reference manual, you find both the relation between the peripherals and the buses through which you can reach them, and the boundary/base addresses of the peripheral registers.
On Table 4 on pages 57/58 is for your controller subfamily.
Here, I find a line on SYSCFG + COMP + OPAMP, which may be what you are looking for. Base address for all is 0x4001 0000, connection is through APB2.
Edit:
If you want to check the documentation which buses/clocks are needed along the way to drive the peripheral, I recommend starting at Fig. 1 in Ch. 2 (p. 13) of the datasheet. Here, you find that APB2 is driven through AHB2, and that COMPs are configured through SYSCFG CTL. The clock tree depicted in Fig. 2 in Sec. 3.6 (p. 19) shows that APB2 clock is driven (with another prescaler) by the AHB clock (HCLK). The details are described in Ch. 2 of the reference manual.
I personally prefer to start with the clock tree editor tool embedded to STM32CubeMX because I feel too lazy to look up all the information at the beginning of development. This gives one the chance to start from a reasonable guess and verify if the clock settings are the needed ones afterwards.
I would like to implement Core-ML app to analyze Device Motion, I'm recording device motion values for some time and capturing the details into the JSON file. Now I want to analyze the data x, y, z values then I should give the result how the user using the device.
Use Turi Create. It has an Activity Classification module that makes this very easy: https://apple.github.io/turicreate/docs/userguide/activity_classifier/
To learn more about this in detail, check out the book Machine Learning by Tutorials (disclaimer: I'm a co-author but did not write the chapters on activity classification).
How can defined topology in Castalia-3.2 for WBAN ?
How can import topology in omnet++ to casalia ?
where the topology defined in default WBAN scenario in Castalia?
with regard
thanks
Topology of a network is an abstraction that shows the structure of the communication links in the network. It's an abstraction because the notion of a link is an abstraction itself. There are no "real" links in a wireless network. The communication is happening in a broadcast medium and there are many parameters that dictate if a packet is received or not, such as the power of transmission, the path loss between transmitter and receiver, noise and interference, and also just luck. Still, the notion of a link could be useful in some circumstances, and some simulators are using it to define simulation scenarios. You might be used to simulators that you can draw nodes and then simply draw lines between them to define their links. This is not how Castalia models a network.
Castalia does not model links between the nodes, it models the channel and radios to get a more realistic communication behaviour.
Topology is often confused with deployment (I confuse them myself sometimes). Deployment is just the placement of nodes on the field. There are multiple ways to define deployment in Castalia, if you wish, but it is not needed in all scenarios (more on this later). People can confuse deployment with topology, because under very simplistic assumptions certain deployments lead to certain topologies. Castalia does not make these assumptions. Study the manual (especially chapter 4) to get a better understanding of Castalia's modeling.
After you have understood the modeling in Castalia, and you still want a specific/custom topology for some reason then you could play with some parameters to achieve your topology at least in a statistical sense. Assuming all nodes use the same radios and the same transmission power, then the path loss between nodes becomes a defining factor of the "quality" of the link between the nodes. In Castalia, you can define the path losses for each and every pair of nodes, using a pathloss map file.
SN.wirelessChannel.pathLossMapFile = "../Parameters/WirelessChannel/BANmodels/pathLossMap.txt"
This tells Castalia to use the specific path losses found in the file instead of computing path losses based on a wireless channel model. The deployment does not matter in this case. At least it does not matter for communication purposes (it might matter for other aspects of the simulation, for example if we are sampling a physical process that depends on location).
In our own simulations with BAN, we have defined a pathloss map based on experimental data, because other available models are not very accurate for BAN. For example the, lognormal shadowing model, which is Castalia's default, is not a good fit for BAN simulations. We did not want to enforce a specific topology, we just wanted a realistic channel model, and defining a pathloss map based on experimental data was the best way.
I have the impression though that when you say topology, you are not only referring to which nodes could communicate with which nodes, but which nodes do communicate with which nodes. This is also a matter of the layers above the radio (MAC and routing). For example it's the MAC and Routing that allow for relay nodes or not.
Note that in Castalia's current implementations of 802.15.6MAC and 802.15.4MAC, relay nodes are not allowed. So you can not create a mesh topology with these default implementations. Only a star topology is supported. If you want something more you'll have to implemented yourself.
Do we have to go through the Device tree bindings documentation of a linux kernel when you start working on it.
Is there no standard set of fields in the device tree which are followed by all distros/kernel sources?
Secondly I need some guidance regarding adding nodes for devices on gpio bus using device tree. I have already consulted http://devicetree.org/Device_Tree_Usage.
stackoverflow-query here should point you to documentation on device tree. And yes it is a good idea to go through the documentation before you dive into using it.
As for your gpio devices (I assume you already have a gpio controller in place in your dts/dtsi file in place), there should be plenty under arch/arc/boot/dts . Pick one :)!
Eg: gpio1_8 for mmc dts and gpio1 controller dtsi
Device Tree Binding for peripherals in an SoC:
As an example for the v5.1 kernel, here are the device tree bindings listed for various peripherals available on an SoC.
Link:
https://elixir.bootlin.com/linux/v5.1/source/Documentation/devicetree/bindings
Device Tree Binding for a particular peripheral in an SoC:
To explain a bit about the device tree binding for a particular peripheral let's take an example of an SPI for a very popular TI OMAP family.
Link:
https://elixir.bootlin.com/linux/v5.1/source/Documentation/devicetree/bindings/spi/omap-spi.txt
The text in this particular link introduces basically the key-value pairs. The 'key' is the device tree property and the 'value' is the possible place holder values for the corresponding 'key'. As an example, in the above link the "compatible" property, which holds one of the value as "ti,omap2-mcspi".
Another example is the "dma-names" property which holds txN, rxN .
Now, in the below link you can clearly see how these device tree properties are used in the real device trees:
https://elixir.bootlin.com/linux/v5.1/source/arch/arm/boot/dts/omap3.dtsi#L365
mcspi1: spi#48098000 {
compatible = "ti,omap2-mcspi";
reg = <0x48098000 0x100>;
...
}
The value "ti,omap2-mcspi" for the key "compatible" is one of the available value in accordance with the device tree binding document for omap-spi.txt (as seen in the second listed link).
So now based on SoC and the peripheral used, the device tree property can be written consulting the device tree binding document.
In AMD 10h architecture like Opteron the prefetched instructions after being aligned are separated into 2 flows: DirectPath (or Fastpath) and VectorPath (Microcode engine). Later these flows are ready for integer or floating-point execution paths.
What is the method the fetched instructions are marked for either flow? Is there a flag bit or some sort?
The AMD documentation is very vague about the differentiation mechanizm. The only mentioned is:
When the target 32-byte instruction window is
obtained from the L1 instruction cache, the instruction bytes are examined to determine whether the
type of basic decode to take place is DirectPath or VectorPath.
There is no "flag" that one can query from software. The decode logic might have a table or logic that notifies later stages of the pipeline in the silicon, but it is invisble from software.
You could go to the SWOG (Software Optimization Guide) and see the latency tables in the appendices: http://developer.amd.com/documentation/guides/Pages/default.aspx
Or you could go to the compiler source (gcc) and glean it from the athlon/fam10h model: http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/athlon.md?revision=174172&content-type=text%2Fplain&view=co
or the bdver1 model: http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/bdver1.md?revision=165853&content-type=text%2Fplain&view=co
--
Quentin