MACRO DEFINITION?

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

In the following macro statement for tiny-0 & tiny-1 TWI baud rate register value, there is a "\" floating out at the end of the first line.

#define TWI0_BAUD(F_SCL, T_RISE)                                                                                       \
((((((float)20000000.0 / (float)F_SCL)) - 10 - ((float)20000000.0 * T_RISE / 1000000))) / 2)

Does it have a purpose or a function or is it ignored?

 

Code is from Dieter Reinhardt library included at the end of Msg #1 in https://www.avrfreaks.net/forum/...

Have looked for the original source, but google-fu has failed me.

 

Thanks

Jim

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

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

That is a line continuation character that allows the macro body to be split across multiple lines.

github.com/apcountryman/build-avr-gcc: a script for building avr-gcc

github.com/apcountryman/toolchain-avr-gcc: a CMake toolchain for cross compiling for the Atmel AVR family of microcontrollers

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

OK, so it has a purpose.

 

Thanks

Jim

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

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

floating out at the end of the first line.

When a macro or other preprocessor statement spans multiple lines, it's pretty common to stick the backslash continuation character at the "left margin", beyond the longest line of the macro, for the sake of readability.

#if defined(__AVR_ATmega8515__) || defined(__AVR_ATmega8535__) ||       \
    defined(__AVR_ATmega16__)   || defined(__AVR_ATmega162__) ||        \
    defined (__AVR_ATmega128__)
  ch = MCUCSR;
#else
  ch = MCUSR;
#endif

 

(in your quoted code, it seems pretty annoying.)

 

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

westfw wrote:
"left margin"

You mean, "right margin" - surely?

 

westfw wrote:
in your quoted code, it seems pretty annoying

I wonder if that's down to inappropriate TAB expansion?

 

That's why TABs are best avoided, IMO  ...

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, part of the panic was that my favorite tuned-to-C editor, TextWrangler, did not pay attention to that continuation character and displayed it all on a single line, which meant that the arithmetic expression was WAAAY past the right margin and the whole thing was not visible unless you went looking for it. I found it quite by accident. Then I found several other previously confusing lines with the same construction. In fact, I never saw it in the form shown in #1 until I pasted the line into a code box here on the forum!

 

There may, also, have been tab "issues".

 

Thanks, for the  comments, though. Learned something new (and possibly important) today!

 

Jim

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

Last Edited: Thu. Jan 30, 2020 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Well, part of the panic was that my favorite tuned-to-C editor, TextWrangler, did not pay attention to that continuation character and displayed it all on a single line, which meant that the arithmetic expression was WAAAY past the right margin and the whole thing was not visible unless you went looking for it.
Looks like the C parser underwent a major rewrite in the follow-on BBEdit.

Would a BBEdit wrap work?

BBEdit 13.0 User Manual

[page 110]

How BBEdit Wraps Text

BBEdit includes Ctags for computer languages :

Parsers — Universal Ctags 0.3.0 documentation

[

  • assembly language via the C preprocessor
  • CMake
  • C/C++ (C++11, don't know which C standard)
  • HTML
  • multi tables regex
  • Python
  • Tcl
  • Vim
  • XSLT

]

 


Bare Bones Software | BBEdit Support Home | Documentation (macOS)

 

"Dare to be naïve." - Buckminster Fuller

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

There is an update to TextWrangler, also. I should apply it, and retry.

 

Thanks

Jim

 

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