Il cuore di Arduino: Un sistema di sviluppo basato su microcontrollore Atmel ...Sardegna Ricerche
L'intervento di Paolo Paolucci durante l'Arduino Day, che si è tenuto il 29 marzo 2014 presso il FabLab Sardegna Ricerche, nella sede di Pula del Parco scientifico e tecnologico della Sardegna.
This document discusses software services and cloud computing architectures. It begins by providing context on the growing service economy and how businesses are increasingly offering services rather than products. It then defines software-as-a-service (SaaS) and describes how SaaS delivers software applications over the internet, with updates and management occurring remotely. Finally, the document discusses service-oriented architectures and how they support the development and delivery of software services.
Il cuore di Arduino: Un sistema di sviluppo basato su microcontrollore Atmel ...Sardegna Ricerche
L'intervento di Paolo Paolucci durante l'Arduino Day, che si è tenuto il 29 marzo 2014 presso il FabLab Sardegna Ricerche, nella sede di Pula del Parco scientifico e tecnologico della Sardegna.
This document discusses software services and cloud computing architectures. It begins by providing context on the growing service economy and how businesses are increasingly offering services rather than products. It then defines software-as-a-service (SaaS) and describes how SaaS delivers software applications over the internet, with updates and management occurring remotely. Finally, the document discusses service-oriented architectures and how they support the development and delivery of software services.
The document discusses architecture-centric software development processes. It describes traditional waterfall and iterative development models, and notes that iterative models allow for more flexibility to changing requirements. Agile development methods like eXtreme Programming (XP) are discussed, which emphasize iterative development, collaboration, and rapid delivery of working software. Key practices of XP are outlined, including user stories, testing, pair programming, refactoring, and continuous integration. The role of architecture in agile processes is also addressed.
This document discusses software product lines and product line architectures. It defines a software product line as a set of software systems that share a common set of features addressing a particular market segment. Product lines are developed from a common set of core assets in a prescribed way to reduce costs and increase reuse. A product line architecture is a common framework that standardizes components and maximizes reuse potential. It specifies common functionality and identifies variation points across related products. Variability management is important for providing flexibility without compromising commonality.
6 - Architetture Software - Model transformationMajong DevJfu
This document discusses model transformations in Model-Driven Architecture (MDA). It defines computation independent models (CIMs), platform independent models (PIMs), and platform specific models (PSMs). It explains that model transformations are used to map between these different abstraction levels and ensure consistency. It also discusses model mappings, approaches to transformations, and tools like EMF and ATL that support transformations in Eclipse.
5 - Architetture Software - Metamodelling and the Model Driven ArchitectureMajong DevJfu
The document discusses metamodeling and the Model Driven Architecture (MDA). It covers topics such as model driven engineering, metamodeling, metamodeling in UML, and the OMG technologies that support MDA. Metamodeling involves modeling modeling elements and their relationships. Metamodels define the structure of models, while models are instances that conform to metamodels. The MDA uses metamodels and models to develop and transform systems.
This document provides an overview of software architectures by presenting examples of architectures from various software systems. It begins with an introduction to software architecture and what it entails. It then shows numerous diagrams and visualizations of architectures for different types of systems, such as editors, compilers, operating systems, middleware, and web applications. These examples are intended to demonstrate common architectural patterns and styles. The document discusses analyzing and comparing the architectures visually and recognizing patterns within them.
The document discusses architectural styles and decomposition techniques for software systems. It describes layering and tiering as basic decomposition approaches, with layers representing different levels of abstraction and tiers representing peer modules within the same layer. Several common architectural styles are then introduced, including pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Closed and open layered architectures are contrasted, and examples of layered systems like virtual machines and the OSI model are provided. Finally, the document notes that complete decompositions often involve both layering and partitioning techniques.
The document discusses key concepts in software architecture, including:
1) Software architecture establishes the overall structure and organization of a system, including its components and relationships.
2) Architectural design involves decomposing a system into subsystems or modules to improve modifiability, reusability, and portability.
3) Key principles for architectural design include simplicity, modularity, low coupling, separation of concerns, abstraction, and postponing decisions.
1 - Architetture Software - Software as a productMajong DevJfu
This document discusses software as a product and industry. It covers how software is a key component in modern technologies and industries. The software industry has grown significantly in recent decades. The document discusses different types of software such as embedded software, middleware, and software as a service. It also covers topics like software architecture, engineering, components, ecosystems, and the challenges in developing software. Overall, the document provides an overview of software as an industrial product and the software development industry.
10 - Architetture Software - More architectural stylesMajong DevJfu
The Microkernel pattern partitions an operating system into isolated, minimal components that communicate through a small, fixed message-passing interface, allowing components to be developed and upgraded independently while maintaining overall system stability and security.
The document discusses architectural UML and provides information on:
1) The elements of a software architecture including views, models, and diagrams.
2) How UML can be used to represent different architectural views including design, process, development, and physical views.
3) An example of using UML models and diagrams to represent different views of a chess game architecture.
UML allows for extending diagrams and modeling elements through three main techniques:
1. Stereotypes allow applying tags to existing modeling elements like classes, associations, etc. to add domain-specific meaning.
2. Profiles extend UML with new modeling elements tailored for specific domains or platforms.
3. Extension mechanisms allow precisely defining new constructs that integrate with the UML metamodel. Together these techniques make UML extensible for multiple domains.
The document discusses metamodeling and the Model Driven Architecture (MDA). It provides an overview of model driven engineering and metamodeling. Specifically, it discusses how metamodels define the structure of models through concepts like classes and relationships. The Model Driven Architecture uses metamodels and modeling to develop software systems from models.
Here are the key differences between objects and classes in UML:
- Classes define the general characteristics (attributes and operations) that objects of that class will have. Objects are specific instances of a class.
- Classes are static definitions, while objects are dynamic instances of classes that exist at run time.
- In class diagrams, classes are represented as boxes containing the attributes and operations. Objects are represented as boxes with the class name followed by a colon and the object name (e.g. Person:John).
- Classes define the common properties for a set of objects, while each object is a unique instance of a class with its own identity and particular values for attributes.
- Classes are abstractions,
The document discusses architectural styles and decomposition techniques. It describes layers as hierarchical sets of subsystems that provide related services by utilizing underlying layers. Tiers partition a system into peer subsystems responsible for classes of services. Common architectural styles include pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Layers and tiers are often combined for complete decomposition, with subsystems divided into tiers and each tier organized into layers. The pipe and filter style focuses on dynamic interaction by processing data streams through filters connected by pipes.
- Reference architectures that provide templates for common system types
- Design patterns that capture successful solutions to recurring problems
- Architectural patterns that describe best practices for system organization
- Legacy applications that can be analyzed for reusable architectural elements
This document discusses software as a product and the software industry. It covers topics such as why software is important, emerging technologies according to Gartner's hype cycle from 2005-2010, software being an industrial product, the size of the worldwide software industry, different types of software including embedded software and software as a service. It also discusses software components, software architecture and engineering issues, producing software is difficult due to complexity, low productivity in the industry, the software development process, different process models, lifecycle differences around the world, development activities, process models, and software standards.
This short document contains 5 headings but provides no other details or context. It lists the headings "My Heading Here First Second Third Fourth Fifth" but does not elaborate on or explain these headings.
This document provides an overview of various types of architectural standards including conceptual standards like IEEE 1471 and DoDAF that define viewpoints and views, notational standards like UML and SysML, and process standards like TOGAF and RUP. It discusses the benefits of standards in promoting interoperability and network effects while also noting drawbacks like limiting flexibility. The document advises deciding when to adopt a standard based on whether in the early or late phase of a project.
The document discusses architectural adaptation and software evolution. It characterizes different types of changes that can occur, including corrective changes, new features, and changes to the operating environment. It also describes different levels at which changes can be made, from the component interior to the overall system configuration. Effective adaptation requires techniques like explicit architectural models, adaptable connectors, and message-based communication. The roles of change agents, strategic and tactical planning, and quiescence are also outlined.
The document discusses architecture-centric software development processes. It describes traditional waterfall and iterative development models, and notes that iterative models allow for more flexibility to changing requirements. Agile development methods like eXtreme Programming (XP) are discussed, which emphasize iterative development, collaboration, and rapid delivery of working software. Key practices of XP are outlined, including user stories, testing, pair programming, refactoring, and continuous integration. The role of architecture in agile processes is also addressed.
This document discusses software product lines and product line architectures. It defines a software product line as a set of software systems that share a common set of features addressing a particular market segment. Product lines are developed from a common set of core assets in a prescribed way to reduce costs and increase reuse. A product line architecture is a common framework that standardizes components and maximizes reuse potential. It specifies common functionality and identifies variation points across related products. Variability management is important for providing flexibility without compromising commonality.
6 - Architetture Software - Model transformationMajong DevJfu
This document discusses model transformations in Model-Driven Architecture (MDA). It defines computation independent models (CIMs), platform independent models (PIMs), and platform specific models (PSMs). It explains that model transformations are used to map between these different abstraction levels and ensure consistency. It also discusses model mappings, approaches to transformations, and tools like EMF and ATL that support transformations in Eclipse.
5 - Architetture Software - Metamodelling and the Model Driven ArchitectureMajong DevJfu
The document discusses metamodeling and the Model Driven Architecture (MDA). It covers topics such as model driven engineering, metamodeling, metamodeling in UML, and the OMG technologies that support MDA. Metamodeling involves modeling modeling elements and their relationships. Metamodels define the structure of models, while models are instances that conform to metamodels. The MDA uses metamodels and models to develop and transform systems.
This document provides an overview of software architectures by presenting examples of architectures from various software systems. It begins with an introduction to software architecture and what it entails. It then shows numerous diagrams and visualizations of architectures for different types of systems, such as editors, compilers, operating systems, middleware, and web applications. These examples are intended to demonstrate common architectural patterns and styles. The document discusses analyzing and comparing the architectures visually and recognizing patterns within them.
The document discusses architectural styles and decomposition techniques for software systems. It describes layering and tiering as basic decomposition approaches, with layers representing different levels of abstraction and tiers representing peer modules within the same layer. Several common architectural styles are then introduced, including pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Closed and open layered architectures are contrasted, and examples of layered systems like virtual machines and the OSI model are provided. Finally, the document notes that complete decompositions often involve both layering and partitioning techniques.
The document discusses key concepts in software architecture, including:
1) Software architecture establishes the overall structure and organization of a system, including its components and relationships.
2) Architectural design involves decomposing a system into subsystems or modules to improve modifiability, reusability, and portability.
3) Key principles for architectural design include simplicity, modularity, low coupling, separation of concerns, abstraction, and postponing decisions.
1 - Architetture Software - Software as a productMajong DevJfu
This document discusses software as a product and industry. It covers how software is a key component in modern technologies and industries. The software industry has grown significantly in recent decades. The document discusses different types of software such as embedded software, middleware, and software as a service. It also covers topics like software architecture, engineering, components, ecosystems, and the challenges in developing software. Overall, the document provides an overview of software as an industrial product and the software development industry.
10 - Architetture Software - More architectural stylesMajong DevJfu
The Microkernel pattern partitions an operating system into isolated, minimal components that communicate through a small, fixed message-passing interface, allowing components to be developed and upgraded independently while maintaining overall system stability and security.
The document discusses architectural UML and provides information on:
1) The elements of a software architecture including views, models, and diagrams.
2) How UML can be used to represent different architectural views including design, process, development, and physical views.
3) An example of using UML models and diagrams to represent different views of a chess game architecture.
UML allows for extending diagrams and modeling elements through three main techniques:
1. Stereotypes allow applying tags to existing modeling elements like classes, associations, etc. to add domain-specific meaning.
2. Profiles extend UML with new modeling elements tailored for specific domains or platforms.
3. Extension mechanisms allow precisely defining new constructs that integrate with the UML metamodel. Together these techniques make UML extensible for multiple domains.
The document discusses metamodeling and the Model Driven Architecture (MDA). It provides an overview of model driven engineering and metamodeling. Specifically, it discusses how metamodels define the structure of models through concepts like classes and relationships. The Model Driven Architecture uses metamodels and modeling to develop software systems from models.
Here are the key differences between objects and classes in UML:
- Classes define the general characteristics (attributes and operations) that objects of that class will have. Objects are specific instances of a class.
- Classes are static definitions, while objects are dynamic instances of classes that exist at run time.
- In class diagrams, classes are represented as boxes containing the attributes and operations. Objects are represented as boxes with the class name followed by a colon and the object name (e.g. Person:John).
- Classes define the common properties for a set of objects, while each object is a unique instance of a class with its own identity and particular values for attributes.
- Classes are abstractions,
The document discusses architectural styles and decomposition techniques. It describes layers as hierarchical sets of subsystems that provide related services by utilizing underlying layers. Tiers partition a system into peer subsystems responsible for classes of services. Common architectural styles include pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Layers and tiers are often combined for complete decomposition, with subsystems divided into tiers and each tier organized into layers. The pipe and filter style focuses on dynamic interaction by processing data streams through filters connected by pipes.
- Reference architectures that provide templates for common system types
- Design patterns that capture successful solutions to recurring problems
- Architectural patterns that describe best practices for system organization
- Legacy applications that can be analyzed for reusable architectural elements
This document discusses software as a product and the software industry. It covers topics such as why software is important, emerging technologies according to Gartner's hype cycle from 2005-2010, software being an industrial product, the size of the worldwide software industry, different types of software including embedded software and software as a service. It also discusses software components, software architecture and engineering issues, producing software is difficult due to complexity, low productivity in the industry, the software development process, different process models, lifecycle differences around the world, development activities, process models, and software standards.
This short document contains 5 headings but provides no other details or context. It lists the headings "My Heading Here First Second Third Fourth Fifth" but does not elaborate on or explain these headings.
This document provides an overview of various types of architectural standards including conceptual standards like IEEE 1471 and DoDAF that define viewpoints and views, notational standards like UML and SysML, and process standards like TOGAF and RUP. It discusses the benefits of standards in promoting interoperability and network effects while also noting drawbacks like limiting flexibility. The document advises deciding when to adopt a standard based on whether in the early or late phase of a project.
The document discusses architectural adaptation and software evolution. It characterizes different types of changes that can occur, including corrective changes, new features, and changes to the operating environment. It also describes different levels at which changes can be made, from the component interior to the overall system configuration. Effective adaptation requires techniques like explicit architectural models, adaptable connectors, and message-based communication. The roles of change agents, strategic and tactical planning, and quiescence are also outlined.
2. a.a. 2007/2008
Architettura dei calcolatori
Porta parallela
• Esempio di periferica: la porta parallela Intel 8255
• Gestione differenziata e programmabile di tre porte parallele bidirezionali (input ed output);
tre porte ABC ed un registro di controllo; Il dispositivo occupa 4 locazioni di indirizzo
8
PA0-PA7
CS*
CS* 8
WR**
IOWR* PB0-PB7
RD*
IORD* 8
A0
PC0-PC7
A1
RESET RESET
D0 - D7
8
Interfaccia con la CPU interfaccia con l’esterno
8255
Parte 3
5. a.a. 2007/2008
Architettura dei calcolatori
8255 Programmazione
• Per dettagli si veda il manuale su Web
• Programmazione:
• Lettura / scrittura da ogni porta; (ReadA,B,C, Write A,B,C)
• Programmazione della parola di controllo: modo e direzione per ogni porta; (Write Control)
• Scrittura di un singolo bit (porta C) con Write Control
A1 A0 RD* WR* CS*
x x x x 1 TRI-STATE
x x 1 1 0 TRI-STATE
0 0 0 1 0 Read A
0 0 1 0 0 Write A
0 1 0 1 0 Read B
0 1 1 0 0 Write B
1 0 0 1 0 Read C
1 0 1 0 0 Write C
1 1 1 0 0 Write Control
Parte 3
6. a.a. 2007/2008
Architettura dei calcolatori
PPI 8255
GROUP A
• Struttura interna A
CNTR
D0-D7
DATA
C HIGH
BUF
RD*
WR* READ
C LOW
CS
CS* WRITE
A1 CNTR
A0
GROUP
RESET
B B
CNTR
Modalita’ di trasferimento
1) basic i/o
LA CPU MASTER DECIDE SENZA SINCRONIZZAZIONE I TEMPI DI LETTURA E
SCRITTURA SULLA PORTA
2) strobed i/o
L'INTERFACCIA CON L'ESTERNO E' SINCRONIZZATA DA UN PROTOCOLLO AD
HANDSHAKE
3) strobed I/O bidirezionale
con doppio handshake in trasmissione e ricezione
Parte 3
7. a.a. 2007/2008
Architettura dei calcolatori
Parola di controllo
ESEMPIO:
ESEMPIO
MODE SET FLAG Control Word PORTA C LOW = INPUT
1=ACTIVE
GRUPPO B PORTA C HIGH = OUTPUT
GRUPPO A
PORTA B = OUT MODO 1
PORTA A = IN MODO O
CONTROL WORD
C LOW
= 10010101=95H
MODE SELECTION
1=INPUT
00=MODE 0
0 OUTPUT
0=OUTPUT
A
01=MODE
01 MODE 1
1=INPUT B 1=INPUT
1X=MODE 2
0=OUTPUT 0=OUTPUT
C HIGH
1=INPUT MODE SELECTION
0=OUTPUT 0=MODE 0
1=MODE 1
PORTA C SET/RESET
7 6 5 4 3 2 1 0
NON
1=SET
UTILIZZATI
0=RESET
0 0 0 Bit 0
0 0 1 Bit 1
SET/RESET FLAG
0 1 0 Bit 2
0 ACTIVE
0=ACTIVE 0 1 1 Bit 3
...................... Bit n
1 1 1 Bit 7
Parte 3
10. a.a. 2007/2008
Architettura dei calcolatori
Handshake di scrittura (modo 1)
INTEA= FF 6 del registro
C
INTEB= FF 2 del registro
C
Alcuni pin della porta C
sono usati come segnali di
controllo: in questo caso il
pin esterno corrispondente
è disconnesso dal
flip flop interno della porta C
Out DX,AL
Parte 3
11. a.a. 2007/2008
Architettura dei calcolatori
Handshake di lettura (modo 1)
INTEA= FF 4 del registro C
INTEB= FF 2 del registro C
Parte 3
12. a.a. 2007/2008
Architettura dei calcolatori
Driver della PPI
• Viene considerato rispetto allo spazio di indirizzamento dell’ 8086 ( indirizzi pari cosi’ con il
bus dei dati a 16 bit la parola di controllo e’ sempre collegata dai bit 0..7)
;------------------8255---------------------
;indirizzi e parola di controllo 8255
pio_addr equ ____h ;indirizzo 8255
pio_a_addr equ pio_addr+0;indirizzo porta a
pio_b_addr
i b dd equ pio_addr+2;indirizzo porta b
i dd +2 i di i t
pio_c_addr equ pio_addr+4;indirizzo porta c
pio_contr_addr equ pio_addr+6;indirizzo controllo
pio_contr_word
pio contr word equ 1 1_______b ; b
pio_c_word equ 0000____b ;ind.set/reset porta c
INIZ_55 proc near
mov DX,PIO_CONTR_ADDR
mov AL,PIO_CONTR_WORD
out DX,AL
mov AL PIO C WORD
AL,PIO_C_WORD
out DX,AL
ret
INIZ_55 endp
p
Parte 3
13. a.a. 2007/2008
Architettura dei calcolatori
Driver
assume CS:codice, DS:DATI
CODICE segment
; procedure
INIZ_55 proc
INIZ_55 endp
START:
mov ax DATI
ax,DATI
; strobe su porta c
mov ds,ax
mov dx,pio_contr_addr
mov ax,STACK_S
mov al, C2_ON
mov ss,ax
,
out dx,al
td l
mov sp,offset S_TOP
mov al, C2_OFF
out dx,al
;inizializzazione 8255
jp
jmp START
call INIZ_55 CODICE ends
;carico i valori che voglio vedere sui END START
mov al, PORTAA_WORD
mov dx pio a addr
dx,pio_a_addr
out dx,al
Parte 3