Mocking assembler instruction

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

 

I am doing some unit-test with cmocka.

When I try to compile some files of my code with a Mingw32 distribution the following error occurs:

Error: no such instruction: `wdr'

I aggree with the compiler that this instruction isn't known in an windows environment.

When I comment the line

#define wdt_reset() __asm__ __volatile__ ("wdr") 

in wdt.h everything is fine.

But I don't want to modify include-files when I test code.

 

Does anyone know how I can mock out wdr or even tell the compiler to ignor this?

I've already defined a function

__wrap_wdt_reset()

with the correspoding compiler instruction but that doesn't help.

 

Same behaviour with

# define sei()  __asm__ __volatile__ ("sei" ::: "memory")

from interrupt.h

 

 

Thank all for replying.

This topic has a solution.
Last Edited: Fri. Mar 9, 2018 - 08:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Use conditional compiles on AVR specific features.

Have an abstraction layer for the target and PC based compiles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Use conditional compiles on AVR specific features. Have an abstraction layer for the target and PC based compiles.

 

How do I achieve this?

Do I have to modify the vendor specific include files or is it better to perfom the changes in my source files.

At the moment I use preprocessor directives very sparingly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

have different build options - either build for AVR or build for PC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

MKFein wrote:
Do I have to modify the vendor specific include files

No!

 

is it better to perfom the changes in my source files.

Yes!

 

For example

 

#if defined BUILD_FOR_AVR
#include <avr/io.h>
#elif defined BUILD_FOR_PC
#include "avr_io_stub.h"
#else
#error "Must define either BUILD_FOR_AVR or BUILD_FOR_PC"
#endif

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got it!

 

In the makefile used for building the test-code executable I definded

-D_AVR_WDT_H_

and 

-D_AVR_INTERRUPT_H_

Through includegards the associated include-files aren't compiled.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

And pass the label via -DBUILD_FOR_PC on the compiler cmd line.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some time ago I wrote a pretty simple but very handy debug library.

It enables you to spit out serial data @ 50% of F_CPU on an arbitrary pin.

You can easily chatch that data to follow execution paths & timing on a Logic analyser.

 

But I also want to be able to turn those debug macro's off in the final version, or to check any timing influence etc.

First part of the text is to define the macro's to spit out the data.

After the #else the macro name's are defined, but with an empty body, so the macro is effectively removed from the code.

#ifdef		DEBUG_PORT
	// Just to make sure the user knows the debug code is inserted.
	// Higher optimisation levels disrupts the timing for debugging.
	#warning Debug code inserted. Use optimisation level: -O1.

	// Use this macro to enable the debug output pin.
	#define DEBUG_OUTPUT_ENABLE		_SET, (DEBUG_DDR |= DEBUG_BIT)

	// 3 little Macro's for internal use only.
	#define _SET					(DEBUG_PORT |= DEBUG_BIT)
	#define _CLEAR					(DEBUG_PORT &= ~DEBUG_BIT)
	#define _BIT(X,Y)				((X) &(0x01 << (Y)) ? (_SET) : (_CLEAR))

	// Startbit, a bunch of data bits and a stop bit.
	#define DEBUG(X)	(_CLEAR,\
			_BIT(X,0), _BIT(X,1), _BIT(X,2),_BIT(X,3),\
			_BIT(X,4), _BIT(X,5), _BIT(X,6), \
			_SET)

#else
	// Preprocessor removes debug statements.
	#define		DEBUG_OUTPUT_ENABLE
	#define		DEBUG(x)

#endif

If anyone is interested in giving this code a try.

Here is the complete header file with more comments on how to use it:

 

Attachment(s): 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can someone define "mock" in this context? 

 

In the English language, it has the sense of "make fun of", or "disparage". Oh, yes, it can also be used as in a "mock-up", meaning something temporary that sort of looks like the "real thing".

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Mock apple pie" - apple pie, made without apples.   "Mock Chicken" - fake chicken (usually a vegetarian thing.)

 

It sounded a bit weird to me too; I don't think I've seen it made into a verb.

 

"Hey, you 'jmp' instruction - how come you aren't 'bra' to match the conditional branches?  Too worried about being mistaken for women's underwear??  Hah hah hah!"

 

Last Edited: Sun. Mar 11, 2018 - 03:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Talking about cmocka here:

 

cmocka is ... an elegant unit testing framework for C with support for mock objects. It only requires the standard C library, works on a range of computing platforms (including embedded) and with different compilers.

https://cmocka.org/

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sun. Mar 11, 2018 - 04:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Mock Chicken" - fake chicken

I see so "mock news"= "fake news".

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Hey, you 'jmp' instruction - how come you aren't 'bra' to match the conditional branches?  Too worried about being mistaken for women's underwear??  Hah hah hah!"

The 6809 wasn't worried ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mock is used as "simulate". If you use Google Test (gtest). (everyone developing software really should!). Then you will find out all about gmock too which is Google's mocking library...
.
https://github.com/google/googletest/blob/master/googlemock/docs/ForDummies.md
.
https://stackoverflow.com/questions/13696376/what-is-the-difference-between-gtest-and-gmock
.
Unit testing is an oft overlooked area of software engineering.

Last Edited: Sun. Mar 11, 2018 - 03:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahhhh! The englisher doth mock!