In Autosar Application Can we have both kind of Interfaces Like Sender/receiver Interfaces and Client/Server Interfaces?
Or is there only S/R interface between 2 Application components at application level in autosar architecture?
You can arbitrarily mix PortPrototypes typed by different PortInterfaces (e.g. ClientServerInterface, SenderReceiverInterface) in any SwComponentType.
Related
What is the difference between broadcaster and beacons? From what I understand a broadcaster is a role in the GAP which sends out advertisements which contain data and are unable to make connections. They usually work in tandem with observers. Beacons do the same thing so what is the difference?
It's a bit like asking what is the difference between a HTTP server and a Web Server. A Web Server is a computer that stores web sites which it makes available over the internet, while a HTTP server is a piece of software that implements the server part of the HTTP protocol.
A Broadcaster is a role in the GAP specification which simply sends out advertisements, just as you say. It's defined in section 2.2.2.1 of the GAP chapter (in the Core v5.3 specification). Observer is the opposite role.
The word "beacon" is not present anywhere in the >3000 pages long Bluetooth Core specification. It's a term made up by industry, presumably because it works good in marketing or is generally a good name to describe this type of product. Beacons typically send out their positions using BLE advertisements for location tracking purposes but can also be connectable for various purposes.
Broadcaster is just a technical term and Broadcasters do not have a specific product purpose, which beacons on the other hand usually have. For example, iBeacon is a product which uses a specific data format containing identifiers. This product then uses the Broadcaster role and sends this data over BLE.
There is no difference. While broadcaster is a technical term used in the Bluetooth specification, beacon is simply the name of a class of products based on Bluetooth LE technology.
I don't get how Bluetooth profiles and protocols and are distinguished.
In the Core_Specification of Bluetooth is written:
Application interoperability in the Bluetooth system is accomplished by Bluetooth profiles. Bluetooth profiles define the required functions and features of each layer in the Bluetooth system from the PHY to L2CAP and any other protocols outside of this specification. The profile defines the vertical interactions between the layers as well as the peer-to-peer interactions of specific layers between devices. (p. 277)
and in the book 'Getting Started with Bluetooth Low Energy Tools and Techniques for Low-Power Networking' by Kevin Townsend I found the following definitions:
Protocols
Building blocks used by all devices conformant to the Bluetooth specification, protocols are the layers that implement the different packet formats, routing, multiplexing, encoding, and decoding that allow data to be sent effectively between peers.
Profiles
“Vertical slices” of functionality covering either basic modes of operation required by all devices (Generic Access Profile, Generic Attribute Profile) or specific use cases (Proximity Profile, Glucose Profile), profiles essentially define how protocols should be used to achieve a particular goal, whether generic or specific.
But this did not really made it understandable for myself.
Are the Baseband & Link Manager protocols? They do not have the term 'protocol' in their name, what is weird to me. If they are not protocols, what are they?
Also I noticed that above the host part of the stack, right above the Host Controller Interface, the terms protocol can be found the most (SMP, ATT, L2CAP). Are only these really protocols? In the Controller part the term does not arise.
So the question is, what are protocols in the Bluetooth stack, what are profiles and what's the main difference?
Link to the BLE specification: https://www.bluetooth.com/specifications/specs/core-specification/
The Bluetooth specification defines a number of
protocols acting as a middle layer between profiles and lower-level Bluetooth packets. A protocol is usually employed by a limited number of profiles.
A Bluetooth profile, roughly speaking, corresponds to a specific use case. Profiles define the standard way of using the different protocols and their features.
We are trying to utilize the Uart as per the new requirements, but lin driver supports only the master mode in the configuration, my doubt is how to use the autosar lin driver for uart purposes, is it possible?
The AUTOSAR MCAL does not support UARTs, except hidden behind LIN and so on.
Some MCU vendors offer Complex Device Drivers, which make the functionality available in AUTOSAR projects.
In worst case, you have to implement one yourself.
I been reading through the Bluetooth 4.0 core specification. However, I cannot find anywhere which states the true definition of 'dual-mode'.
From other google results, it looks like 'dual-mode' means that a BT device that has this capability can communicate with a LE device and a BR/EDR device simultaneously. However, I cannot find any official bluetooth docs that states this feature.
The closest one that I can get is:
The Brand book uses the term “dual mode” device to refer to a design
(host and/or controller) that is qualified in compliance with the
Basic Rate and Low Energy Combined Core Configuration as defined in
the Bluetooth specification. It is also referred to in the Bluetooth
specification as a BR/EDR/LE design.
from here
Could someone point out the location where 'dual-mode' is defined?
There is some different logic.
The two most prevalent implementations of the specification are
Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR), which was adopted as
version 2.0/2.1, and Bluetooth with low energy (LE), which was adopted
as version 4.0/4.1/4.2. Each implementation has different use cases
and each implementation uses a different chipset to meet essential
hardware requirements. Dual-mode chipsets are also available for
applications that include both use cases. https://www.bluetooth.com/specifications/bluetooth-core-specification
There is Bluetooth 2.x - BR/EDR spec and there is Bluetooth 4.x (now 5.0). They are individuals specification with different purposes and different tech implementation (different modulation, different DSP blocks, different modes of work, etc). Manufacturer like TI, STM and so on just implement both of theese specs on one chip (System on Chip) or in SiP (System in Package). And theese SoC and SiP named "dual-mode devices" and often BT 2.0 and BT 4.x work in theese SoCs (SiPs) simultaneously.
I was reading about the J2ME architecture where it was written that there are 3 layers
1) Configuration Layer: It has JVM and interacts with the OS
2) Profile layer: Minimum set of API's for small device
3) MIDP layer: Contains Java API's
The book is J2ME: The Complete Reference
QUESTIONS
1) Do every phone have an OS? If not what is the first layer doing in that case?
2) What is API's for small device?
3) MIDP is itself a profile which means it should be at second layer then how come it is at third layer?
Configurations and profiles are the main elements that comprise J2ME’s modular design. These two elements enable support for the plethora of devices that
J2ME supports.
A J2ME configuration defines a minimum Java platform for a family of devices.
Members of a given family all have similar requirements for memory and processing power.
A configuration is really a specification that identifies the systemlevel facilities available, such as a
set of Java language features,
the characteristics and features of the virtual machine present,
and the minimum Java libraries that are supported.
Software developers can expect a certain level of system support
to be available for a family of devices that uses a particular configuration.
A configuration also specifies a minimum set of features for a category of devices.
Device manufacturers implement profiles to provide a real platform for a family
of devices that have the capabilities that a given configuration specifies.
The other J2ME building block, the profile, specifies the application-level interface
for a particular class of devices. A profile implementation consists of a set of Java
class libraries that provide this application-level interface. Thus, a profile theoretically could specify all kinds of functionality and services.
This is not the intention of its creators, however. The creators of J2ME intend that
a profile should address the needs of a specific device category or vertical market
pertaining to that device category. The idea is not to place a plethora of unrelated
application level features in a profile. Rather, the main goal is to guarantee interoperability—which doesn’t necessarily imply compatibility between different manufacturers’ implementations—between all devices of the same category or vertical
market family to define a standard platform for Java application development.
For example, a profile might support a network communication facility for the
popular Short Message Service (SMS) standard widely used by mobile phones.
Because the SMS standard is a ubiquitous feature of mobile telephony, it makes
sense to define this service in a profile that targets mobile phones, rather than to
build it into a configuration.
A profile is implemented on top of a configuration, one step closer to the implementation of real-world applications.
Typically, a profile includes libraries that are
more specific to the characteristics of the category of devices they represent than
are the libraries that comprise configurations.
Applications are then built on top
of the configuration and profile; they can use only the class libraries provided by
these two lower-level specifications. Profiles can be built on top of one another. A
J2ME platform implementation, however, can contain only one configuration.
Figure 1.1 shows the conceptual layers that comprise the J2ME platform.
So far, these notions of configurations, profiles, and platform definitions is somewhat abstract. The next section gives you a more concrete description of the characteristics of actual environments.
Configurations and Profiles
A configuration specifies three basic elements:
• a set of Java programming language features
• a set of Java virtual machine features
• a set of supported Java libraries and application programming
interfaces (APIs)
Hope this will help you to understand J2ME Architecture.
Answers are as follows,
Yes, Every Phone has Operating System.
API's for small device(mobile phone) is depends on the oprating system loaded into the device.
MIDP is made up of Libraries, this is the reason it is on third layer as shown in the picture in above answer of Sajid.