This document discusses challenges with hardware-near programming and proposes solutions like object-oriented design, test-driven development, and mocking hardware for testing in C. It provides examples of encapsulating hardware registers in C and writing tests that check register values and function outputs without the physical hardware. The document concludes that while setting up the tools is an initial investment, TDD is possible and helps create safe, maintainable low-level software.
Those slides describe digital design using Verilog HDL,
starting with Design methodologies for any digital circuit then difference between s/w (C/C++) and H/w (Verilog) and the most important constructs that let us start hardware design using Verilog HDL.
Those slides describe digital design using Verilog HDL,
starting with Design methodologies for any digital circuit then difference between s/w (C/C++) and H/w (Verilog) and the most important constructs that let us start hardware design using Verilog HDL.
Keynote in KLEE workshop on Symbolic Execution 2018
Systematic greybox fuzzing inspired by ideas from symbolic execution, work at NUS
Covers new usage of symbolic execution in automated program repair, work at NUS
Verilog HDL is a hardware description language used to design and document electronic systems. Verilog HDL allows designers to design at various levels of abstraction. It is the most widely used HDL with a user community of more than 50,000 active designers.
A brief history
Verilog HDL originated at Automated Integrated Design Systems (later renamed as Gateway Design Automation) in 1985. The company was privately held at that time by Dr. Prabhu Goel, the inventor of the PODEM test generation algorithm. Verilog HDL was designed by Phil Moorby, who was later to become the Chief Designer for Verilog-XL and the first Corporate Fellow at Cadence Design Systems. Gateway Design Automation grew rapidly with the success of Verilog-XL and was finally acquired by Cadence Design Systems, San Jose, CA in 1989.
Verilog was invented as simulation language. Use of Verilog for synthesis was a complete afterthought. Rumors abound that there were merger discussions between Gateway and Synopsys in the early days, where neither gave the other much chance of success..
In the late 1980's it seemed evident that designers were going to be moving away from proprietary languages like n dot, HiLo and Verilog towards the US Depatment of Defense standard H.D.L., known as the VHSIC Hardware Description Language. VHSIC it self stands for "Very High Speen Intergrated Circuit" BTW).
Perhaps due to such market pressure, Cadence Design Systems decided to open the Verilog language to the public in 1990, and thus OVI (Open Verilog International) was born. Until that time, Verilog HDL was a proprietary language, being the property of Cadence Design Systems. When OVI was formed in 1991, a number of small companies began working on Verilog simulators, including Chronologic Simulation, Frontline Design Automation, and others. The first of these came to market in 1992, and now there are mature Verilog simulators available from many sources.
As a result, the Verilog market has grown substantially. The market for Verilog related tools in 1994 was well over $75,000,000, making it the most commercially significant hardware description language on the market.
An IEEE working group was established in 1993 under the Design Automation Sub-Committee to produce the IEEE Verilog standard 1364. Verilog became IEEE Standard 1364 in 1995.
As an international standard, the Verilog market continued to grow. In 1998 the market for Verilog simulators alone was well over $150,000,000; continuing its dominance.
The IEEE working group released a revised standard in March of 2002, known as IEEE 1364-2001. Significant publication errors marred this release, and a revised version was released in 2003, known as IEEE 1364-2001 Revision C.
I am currently seeking full time opportunities in Embedded/Firmware Software development . I graduated with my Masters in Science degree in Electrical and Electronics Engineering from The University of North Carolina at Charlotte in December 2015.
IMAGE CAPTURE, PROCESSING AND TRANSFER VIA ETHERNET UNDER CONTROL OF MATLAB G...Christopher Diamantopoulos
This implemented DSP system utilizes TCP socket communication. Upon message reception, it decides the appropriate process to be executed based on cases which can be categorized as follows:
1) image capture
2) image transfer
3) image processing
4) sensor calibration
A user-friendly MATLAB GUI, named DIPeth, facilitates the system's control.
Keynote in KLEE workshop on Symbolic Execution 2018
Systematic greybox fuzzing inspired by ideas from symbolic execution, work at NUS
Covers new usage of symbolic execution in automated program repair, work at NUS
Verilog HDL is a hardware description language used to design and document electronic systems. Verilog HDL allows designers to design at various levels of abstraction. It is the most widely used HDL with a user community of more than 50,000 active designers.
A brief history
Verilog HDL originated at Automated Integrated Design Systems (later renamed as Gateway Design Automation) in 1985. The company was privately held at that time by Dr. Prabhu Goel, the inventor of the PODEM test generation algorithm. Verilog HDL was designed by Phil Moorby, who was later to become the Chief Designer for Verilog-XL and the first Corporate Fellow at Cadence Design Systems. Gateway Design Automation grew rapidly with the success of Verilog-XL and was finally acquired by Cadence Design Systems, San Jose, CA in 1989.
Verilog was invented as simulation language. Use of Verilog for synthesis was a complete afterthought. Rumors abound that there were merger discussions between Gateway and Synopsys in the early days, where neither gave the other much chance of success..
In the late 1980's it seemed evident that designers were going to be moving away from proprietary languages like n dot, HiLo and Verilog towards the US Depatment of Defense standard H.D.L., known as the VHSIC Hardware Description Language. VHSIC it self stands for "Very High Speen Intergrated Circuit" BTW).
Perhaps due to such market pressure, Cadence Design Systems decided to open the Verilog language to the public in 1990, and thus OVI (Open Verilog International) was born. Until that time, Verilog HDL was a proprietary language, being the property of Cadence Design Systems. When OVI was formed in 1991, a number of small companies began working on Verilog simulators, including Chronologic Simulation, Frontline Design Automation, and others. The first of these came to market in 1992, and now there are mature Verilog simulators available from many sources.
As a result, the Verilog market has grown substantially. The market for Verilog related tools in 1994 was well over $75,000,000, making it the most commercially significant hardware description language on the market.
An IEEE working group was established in 1993 under the Design Automation Sub-Committee to produce the IEEE Verilog standard 1364. Verilog became IEEE Standard 1364 in 1995.
As an international standard, the Verilog market continued to grow. In 1998 the market for Verilog simulators alone was well over $150,000,000; continuing its dominance.
The IEEE working group released a revised standard in March of 2002, known as IEEE 1364-2001. Significant publication errors marred this release, and a revised version was released in 2003, known as IEEE 1364-2001 Revision C.
I am currently seeking full time opportunities in Embedded/Firmware Software development . I graduated with my Masters in Science degree in Electrical and Electronics Engineering from The University of North Carolina at Charlotte in December 2015.
IMAGE CAPTURE, PROCESSING AND TRANSFER VIA ETHERNET UNDER CONTROL OF MATLAB G...Christopher Diamantopoulos
This implemented DSP system utilizes TCP socket communication. Upon message reception, it decides the appropriate process to be executed based on cases which can be categorized as follows:
1) image capture
2) image transfer
3) image processing
4) sensor calibration
A user-friendly MATLAB GUI, named DIPeth, facilitates the system's control.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
2. VIA University College
ICT-Engineering
Whatistheproblems withhardwarenear
programming?
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 2
– The nearer the hardware the testing difficulties grows
– There are not much help from different tools
– Errors/bugs are difficult to find
– The software are target dependent
– Design for Test is the solution
– Debug Later Programming (DLP) vs Test Driven Development
3. VIA University College
ICT-Engineering
Whydoweforgeteverythingwehave
learnedwhenprogramminglow-levelC?
Typical excuses:
1. Hardware near programming is for Electronics Engineers
2. The hardware is not available yet
3. It is not possible to test due to limited target resources
– Test Driven Development (TDD) is not possible on the small target
4. Debugging facilities in the target toolchain is limited
– Debugging is difficult and is done with oscilloscopes, leds, simple printouts
etc.
5. UML is not useful for C-programming
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 3
4. VIA University College
ICT-Engineering
ObjectOrientedDesignandProgramming
inC
According to Robert C. Martin an OOP language has the following:
1. Encapsulation
2. Inheritance
3. Polymorphism
The first two are easy to obtain in C, the third is a little harder
1. Abstract Data Types (ADT)
2. Nested struct’s
3. Pointer tables
For a complete description how to do use three read
Axel Schreiner’s book: Object-oriented Programming in ANSI-C
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 4
8. VIA University College
ICT-Engineering
SOLIDDesignPrinciples
Robert C. Martin has assembled these five more or less well-known principles together
Single Responsibility Principle (SRP)
– A class should have one, and only one, reason to change
Open Close Principle (OCP)
– You should be able to extend a class’s behaviour, without modifying it
Liskov Substitution Principle (LSP)
– Derived classes must be substitutables for their base classes
Interface Segregation Principle (ISP)
– Make fine grained interfaces that are client specific
Dependency Inversion Principle (DIP)
– Depend on abstractions, not on concretions
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 8
11. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 11
Host
Compiler
Host Platform
Production
code
(.h,.c)
Hardware
API(.h)
Host
Linker
11101
00011
00110
00111
Host
Libs(.so)
ForcedIncludefiles
(.h)
Mock’sandTestCases
(.h,.c,.cpp)
Hardware
(registers etc.)
12. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
Forced include files:
– The pre-processor includes specified files before anything else is included
– We can add macros and definitions that
– Disable target hardware specific things
– Enable hardware fakes
Compiler/pre-processor options
– gcc option (gnu): –include <file to be included>
– cl option (Microsoft): /FI<file to be included>
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 12
13. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
All what’s needed to cheat the toolchain for the ATMEGA2560 MCU:
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 13
#include <stdint.h>
#define __AVR_LIBC_DEPRECATED_ENABLE__
#define __AVR_ATmega2560__
#define _AVR_SFR_DEFS_H_ 1
// 0x136 is highest address of registers in ATMEGA2560
#define _HIGHEST_REGISTER_ADD0x136
// These global variables (fake hardware registers) needs to be accessible from both C and C++
// Therefore they must be declared in C scope if it is the C++ compiler that access
#ifdef __cplusplus
extern "C" {
#endif
extern uint8_t __avr_reg[_HIGHEST_REGISTER_ADD];
#ifdef __cplusplus
}
#endif
14. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
All what’s needed to cheat the toolchain for an ATMEGA2560 MCU:
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 14
// Macros to access the fake hardware registers
#define _SFR_MEM8(mem_addr) (*(uint8_t *)(&__avr_reg[mem_addr]))
#define _SFR_IO8(io_addr) (*(uint8_t *)(&__avr_reg[io_addr]))
// Byte value from bit_no
#define _BV(bit) (1 << (bit))
// Interrupt
#define _AVR_INTERRUPT_H_
#define ISR(vector, ...) void ISR_##vector(void)
#define sei() SREG |= _BV(SREG_I)
#define cli() SREG &= ~_BV(SREG_I)
15. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
Test cases can now check contents of hardware registers
using a test macro: CHECK_EQUAL_C_BITS(expected, actual, mask)
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 15
TEST(TEST_HAL, ADPS2AndADPS1isSetAndADPS0isClearedInADCSRAAfterCreate)
{
CHECK_EQUAL_C_BITS(_BV(ADPS2)|_BV(ADPS1), ADCSRA, _BV(ADPS2) | _BV(ADPS1)|_BV(ADPS0));
}
TEST(TEST_HAL, get_voltageCalledWithCh15SetsMuxTo100111)
{
hal_get_voltage(15);
CHECK_EQUAL_C_BITS(_BV(MUX5), ADCSRB, _BV(MUX5));
CHECK_EQUAL_C_BITS(_BV(MUX2) | _BV(MUX1) | _BV(MUX0), ADMUX,
_BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1) | _BV(MUX0));
}
16. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
Test cases can check that bits in registers are set and read in right order
and return values can be controlled
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 16
TEST(TEST_HAL, get_voltageCalledSetsAndWaitsForADSCtoClear)
{
mock().expectOneCall("mock_set_bit").withPointerParameter("reg",
&ADCSRA).withIntParameter("bit_no", ADSC);
mock().expectNCalls(5,"mock_read_bit").withPointerParameter("reg",
&ADCSRA).withIntParameter("bit_no", ADSC).andReturnValue(_BV(ADSC));
mock().expectOneCall("mock_read_bit")
.withPointerParameter("reg"&ADCSRA).withIntParameter("bit_no", ADSC).andReturnValue(0);
hal_get_voltage(0);
}
17. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
The Mocks are injected via dependency injection:
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 17
// ---------------------------------------------------------------------------------------
uint8_t mock_read_bit(volatile uint8_t * reg, uint8_t bit_no)
{
mock().actualCall("mock_read_bit").withPointerParameter("reg", (void *)reg)
.withIntParameter("bit_no", bit_no);
return mock().returnIntValueOrDefault(0);
}
// --------------------------------------------------------------------------------------
void mock_set_bit(volatile uint8_t * reg, uint8_t bit_no)
{
// Production code function called
set_bit(reg, bit_no);
mock().actualCall("mock_set_bit").withPointerParameter("reg", (void *)reg)
.withIntParameter("bit_no", bit_no);
}
18. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
Test that calculations are correct in driver, faking hardware registers
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 18
TEST(TEST_HAL, get_voltageReturnsFullVRef)
{
// Given
ADCL = 0b11111111;
ADCH = 0b00000011;
// When
float result = hal_get_voltage(0);
// Then
float expected = ((ADCH << 8) + ADCL) * _V_REF / 1024;
CHECK_EQUAL_C_REAL(expected, result, 0.001);
}
19. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
Faking Interrupts
The Interrupt Service Routine (ISR ) in the production code:
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 19
ISR(INT0_vect)
{
PORTA = 0x55;
}
The macro that fakes it:
#define ISR(vector, ...) void ISR_##vector(void)
In the test cases the ISR is now turned into a normal function with the following
signature:
void ISR_INT0_vect(void)
20. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
Faking Interrupts
The Test that check that the ISR is doing what it is supposed to do
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 20
TEST(TEST_HAL, INT0ISRIsSettingPORTAto0x55)
{
ISR_INT0_vect(); // Fake INT0 Interrupt
CHECK_EQUAL_C_INT(0x55, PORTA);
}
21. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
What Test-cases to write:
Take a look at James W. Grenning’s ZOMBIES:
– Z – Zero
– O – One
– M – Many (or More complex)
– B – Boundary Behaviours
– I – Interface definition
– E – Exercise Exceptional behaviour
– S – Simple Scenarios, Simple Solutions
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 21
22. VIA University College
ICT-Engineering
TestDrivenDevelopmentinC
Pros:
– Production code can be developed at Host-computer
– Use all Host-computer tools and Debugger facilities
– Less errors and failures when moving to target computer
– Develop without the target hardware
Cons:
– It takes time to figure out how to get rid of the hardware dependencies in the
target tool-chain (One time only investment)
– Real-time aspects can’t be tested on the Host-computer
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 22
23. VIA University College
ICT-Engineering
Conclusion
– It is hard to develop low-level and hardware near software
– Invest time in setting up your tools and environment
(one time investment per platform)
– Use all the principles that we know from high-level development
(OOD/P)
– Document using UML and/or SysML
– TTD is possible and not very hard when tools are setup
– Software is easy and safe to maintain if it is well designed and the test
suite is up-to-date
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 23
24. VIA University College
ICT-Engineering
References
– CppUTest (open source): http://cpputest.github.io/index.html
– James W. Grenning, 2011: Test Driven Development for Embedded C, 1st Edition,
ISBN-13: 978-1934356623, ISBN-10: 9781934356623
– Axel Schreiner : Object-oriented Programming in ANSI-C
– Beck, K., 2002 Test Driven Development: By Example, ISBN-10: 9780321146533
ISBN-13: 978-0321146533
– Robert C. Martin, 2002: Agile Software Development, Principles, Patterns, and
Practices, ISBN10 0135974445 ISBN13 9780135974445
– James W. Grenning’s ZOMBIES: http://blog.wingman-sw.com/archives/677
2018-11-21Object Orientering, Test Driven Development og C - InfinIT - Ib Havn, iha@via.dk 24