Protocol for streaming serial data?

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

Any suggestions for any "widely used" and/or "well-established" protocols for streaming serial data from a microcontroller-based box of sensors.

 

Sure, it's not hard to just make one up; but wondering if there's anything "off the shelf" before reinventing another wheel.

 

The idea with "widely used" and/or "well-established" is that there might be ready-to-use stuff to get the data into things like MatLab (beyond my remit).

 

Data would be sets of ~ eight 32-bit measurements, 100 sets per second - so ~ 3.5k byte/s

 

Also configuration & commands for the PC to the microntroller - but that would be infrequent and very little data.

 

This is just for a simple point-to-point link - so no addressing or networking required (which seems to be what over-complicates most of the things I've found so far).

 

I did find that ST have something which they use for talking between their sensor dev kits to their PC visualisation tools:

https://community.st.com/s/question/0D50X0000BCNJg3SQH/unicleo-comms-protocol-source-code

But that was too tightly locked-in to their specific boards & sensors.

 

I did find this:

https://en.wikipedia.org/wiki/Bristol_Standard_Asynchronous_Protocol

but it's polled rather than streaming. 

and has addressing overheads.

 

I did wonder if Sigrok might provide anything, but it just seems to list devices it can talk to - rather than give protocol details.

 

Cheers,

 

A.

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

Modbus?

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

As a bus, that has addressing - which I don't need.

 

But, then, it might be as easy to just ignore the addressing than have to invent something without addressing ...

 

It's certainly one to consider 

 

thanks.

 

EDIT

 

Ah;  and Modbus seems to require the Master to request each reading (blob of data) - rather than the slave/sensor just "streaming" out its data?

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...
Last Edited: Fri. Sep 27, 2019 - 04:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you're streaming 'packets' of binary data (eg.  sets of 8 32bit readings), one simple technique is to use something like slip encoding where you add a marker byte (c0) at the end, or at the start and the end, of each packet (and escape any actual c0 values contained in the packet, but that's a very minimal overhead).

The receiving end can then start receiving at any point and sync onto the start of a packet.

https://en.wikipedia.org/wiki/Se...

(ignore talk of TCP/IP etc. it's just a way of dividing a uart stream into packets)

 

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

What is going to receive the serial data? I use Python on the receiving side for the most part, and JSON has been an easy way to move data from the MCU to the host, but I am looking at how Pythons pickle works, it has a compact binary format, and there are existing tools for analyzing data streams generated by it.

 

https://docs.python.org/3/library/pickle.html

 

After looking some at pickle stuff, I ran across Abstract Syntax Notation One (ASN.1)

 

https://ttsiodras.github.io/asn1.html

 

I have no experience with ASN.1, but it looks interesting.

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

awneil wrote:
Any suggestions for any "widely used" and/or "well-established" protocols for streaming serial data from a microcontroller-based box of sensors

DMX512 for lighting entertainments.
Streaming 512 of 1byte packets 250kbps
Simple Format
No checksum
1 master broadcasts data over bus, several slaves.
Twisted pair shielded cable required, D+/D-/COM
documented as ANSI E1-11
.
also RDM light control, sensor read
More complicated packet format, 250kbps, with checksum
Polling bus, 1 master, several slaves
Twisted pair shielded cable required, D+/D-/COM
Documented as ANSI E1-20
.
There is also DALI for Lighting control, sensor read
Complicated packet format 1.2 kbps
İsolated physical layer, robust bus, plain 2x wire with no polarity
I think it is patented document.

Majid

Last Edited: Fri. Sep 27, 2019 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does something like the ubiquitous Google protobufs fit the bill? https://en.m.wikipedia.org/wiki/...

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

What's wrong with SANDU protocoll? (Something Awneil dreamed up)

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

He He! You're spoilt for choice - Here's yet another:

 

S.N.A.P - Scaleable Node Address Protocol. (Simple - Generic - Flexible - Free)

http://www.hth.com/snap/

 

Read to the bottom of the page; there's loads of AVR examples.

 

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

Google Protocol Buffers are a good choice for data encoding (as also mentioned by clawson) since there is such wide support for them. On the microcontroller side of things I've had good experiences using the nanopb implementation so long as variable length fields are avoided or have established maximum sizes.

 

One thing to note about Protocol Buffers though is that they define the structure of serialized data, not how messages are framed. Prefixing messages with a varint message size is common (nanopb and Google C++ implementation support this, others probably do too). nanopb also supports null terminating messages but this is non-standard. Another option would be using SLIP for framing.

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

I’ve used S.N.A.P. On several occasions!
Works well.
Jim

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

awneil wrote:

Any suggestions for any "widely used" and/or "well-established" protocols for streaming serial data from a microcontroller-based box of sensors.

Sure, it's not hard to just make one up; but wondering if there's anything "off the shelf" before reinventing another wheel.

The idea with "widely used" and/or "well-established" is that there might be ready-to-use stuff to get the data into things like MatLab (beyond my remit).

Data would be sets of ~ eight 32-bit measurements, 100 sets per second - so ~ 3.5k byte/s

Also configuration & commands for the PC to the microntroller - but that would be infrequent and very little data.

This is just for a simple point-to-point link - so no addressing or networking required (which seems to be what over-complicates most of the things I've found so far).

 If it is that modest, and you think it may be used with matlab or similar, you could look at a simple ASCII CSV format.

I have loaded Serial HEX CSV data into spreadsheets, but if you have room in the MCU, you could send decimal or float to make even less work on PC side.

If you want to graph this info, another ASCII format could be the .RAW file LTSpice (etc) uses.

That needs a sample count in the header, so excludes a complete open-ended send, but it's a simple file that is then easy to read and view.

 

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

I think that I would use the common KISS packet structure. Its often used with SLIP links but certainly not restricted to that.

 

KISS involves some basic framing characters, an escape mechanism if a data character is the same as a framing character, some kind of check sum, and data characters in a structure of your choice. In more elaborate situations, a header is often included, with packet type, character counts. and such, which you don't need with only one packet type and a fixed number of values that are fully packed integers (for example, 0x00000000 for zero). Its fairly low overhead (without an escape situation, 3 additional bytes on top of your 32 data bytes) and dead easy to parse.

 

Jim

 

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

Last Edited: Sat. Sep 28, 2019 - 12:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Google protobufs

apcountryman wrote:
Google Protocol Buffers

 

Oh yes - that's one I'd meant to look at, and then forgotten!

 

and thanks to all for all the other suggestions ...

 

I also came across IEC 60870:

https://en.wikipedia.org/wiki/IEC_60870

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

As another suggestion for packet framing...

 

https://en.wikipedia.org/wiki/Co...

 

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Ha ha:  worked on a byte-stuffing protocol once - gave someone the chance to create a function called get_stuffed() !

 

laugh

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

clawson wrote:

Google protobufs

apcountryman wrote:

Google Protocol Buffers

 

Do you have a favourite library for implementing the microcontroller side in 'C' ?

 

Googling around shows there's plenty to try - just wondering if you have specific "favourites" or recommendations of any to try and/or any to avoid ... ?

 

 

 

Looking around

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


When I've used protobufs it's been the "real thing" as I've been using it on "big iron". Not sure about micro implementations.

 

EDIT: and as I typed that I realised I did have an interaction with a "small system" so it looks like it was "nanoPB" that was used.

 

EDIT2: so that would mean this:  https://github.com/nanopb/nanopb - even there it looks (on the surface) "heavy" so might still be for things more like ARMs than AVRs (it would have been ARM where we used it).

 

Ah yes:

 

https://jpa.kapsi.fi/nanopb/docs/index.html

 

Last Edited: Thu. Oct 3, 2019 - 11:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For my own testing / development the "other end" will be a PC - did you just use Google's libraries as "the real thing" ?

 

Yes "nanoPB" was one of my first hits laugh

 

It will be on a Cortex-M4

 

(I have seen stuff referring to it on an STM32)

 

EDIT

 

"it" as in "protbufs" - not necessarily nanoPB

 

This:  https://www.vittoriozaccaria.net/blog/2015/10/21/using-a-cheap-stm32-to-teach-remote-sensor-monitoring.html

 

which does seem to C++, and using something else

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...
Last Edited: Thu. Oct 3, 2019 - 11:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
might still be for things more like ARMs than AVRs

It does have some mention of AVR:

 

https://github.com/nanopb/nanopb/tree/master/examples/using_double_on_avr

 

The Nanopb documentation wrote:

Features

  1. Pure C runtime
  2. Small code size (2–10 kB depending on processor, plus any message definitions)
  3. Small ram usage (typically ~300 bytes, plus any message structs)
  4. Allows specifying maximum size for strings and arrays, so that they can be allocated statically.
  5. No malloc needed: everything can be allocated statically or on the stack. Optional malloc support available.
  6. You can use either encoder or decoder alone to cut the code size in half.
  7. Support for most protobuf features, including: all data types, nested submessages, default values, repeated and optional fields, oneofs, packed arrays, extension fields.
  8. Callback mechanism for handling messages larger than can fit in available RAM.
  9. Extensive set of tests.

So could fit larger AVRs ... ? 

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...
Last Edited: Thu. Oct 3, 2019 - 11:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

clawson wrote:

Google protobufs

apcountryman wrote:

Google Protocol Buffers

 

Do you have a favourite library for implementing the microcontroller side in 'C' ?

 

Googling around shows there's plenty to try - just wondering if you have specific "favourites" or recommendations of any to try and/or any to avoid ... ?

 

 

 

Looking around

 

I've used the official C++ implementation on Linux, and nanopb on the microcontroller side. When I was looking at options for using Protocol Buffers on the microcontroller side a few years ago I also looked at protobuf-c but had issues with building and using it (the project also appears to be less active than nanopb).

 

awneil wrote:

clawson wrote:
might still be for things more like ARMs than AVRs

It does have some mention of AVR:

 

https://github.com/nanopb/nanopb/tree/master/examples/using_double_on_avr

 

The Nanopb documentation wrote:

Features

  1. Pure C runtime
  2. Small code size (2–10 kB depending on processor, plus any message definitions)
  3. Small ram usage (typically ~300 bytes, plus any message structs)
  4. Allows specifying maximum size for strings and arrays, so that they can be allocated statically.
  5. No malloc needed: everything can be allocated statically or on the stack. Optional malloc support available.
  6. You can use either encoder or decoder alone to cut the code size in half.
  7. Support for most protobuf features, including: all data types, nested submessages, default values, repeated and optional fields, oneofs, packed arrays, extension fields.
  8. Callback mechanism for handling messages larger than can fit in available RAM.
  9. Extensive set of tests.

So could fit larger AVRs ... ? 

 

The microcontroller I used nanopb with is the Parallax P8X32A Propeller with convoluted memory expansion so it wasn't as resource constrained as an AVR. As the project documentation points out though, code size and RAM usage do depend on the messages you define and how you use them. I should have time this weekend to throw together a basic example to see how feasible using it with AVRs actually is.

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

apcountryman wrote:
I also looked at protobuf-c but had issues with building and using it (the project also appears to be less active than nanopb).

Thanks - I've also seem that one.

 

Note how it's not necessary to quote the entire post - just pick out enough to give context.

 

Otherwise it all gets very cluttered & hard to follow!

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

HDLC is another with framing.

QP/Spy™ (QS) is a subset of HDLC.

QTools: QP/Spy™ Data Protocol

...

The QP/Spy™ data protocol has many elements of the High Level Data Link Control (HDLC) protocol defined by the International Standards Organization (ISO).

...

QS is GPLv3 :

qpc/src/qs at master · QuantumLeaps/qpc · GitHub (C)

qpcpp/src/qs at master · QuantumLeaps/qpcpp · GitHub (C++)

qtools/qspy at master · QuantumLeaps/qtools · GitHub (PC)

 

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

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

awneil wrote:
I did wonder if Sigrok might provide anything, but it just seems to list devices it can talk to - rather than give protocol details.
Yea (details in the source code)

Protocol decoders - sigrok

 

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

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

yes - that was the page I found.

 

To be fair, it's not Sigrok's place to provide definitions of the 3rd-party protocols - but I was hoping there might be some links some definitions.

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...
Last Edited: Fri. Oct 4, 2019 - 04:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I threw together a basic nanopb example program to experiment with.

 

example.proto

syntax = "proto3";

message Example_Message {
    fixed32 a = 1;
    fixed32 b = 2;
    fixed32 c = 3;
    fixed32 d = 4;
}

example.c

#include <avr/io.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <util/delay.h>

#include "example.pb.h"
#include "pb_encode.h"

static void configure_usart0( void )
{
    UCSR0B = ( 0 << UCSZ02 ) |
             ( 0 << TXEN0  ) |
             ( 0 << RXEN0  ) |
             ( 0 << UDRIE0 ) |
             ( 0 << TXCIE0 ) |
             ( 0 << RXCIE0 );

    UCSR0A = ( 0 << MPCM0 ) |
             ( 0 << U2X0  );

    UCSR0C = ( 1 << UCSZ00  ) |
             ( 1 << UCSZ01  ) |
             ( 0 << USBS0   ) |
             ( 0 << UPM00   ) |
             ( 0 << UPM01   ) |
             ( 0 << UMSEL00 ) |
             ( 0 << UMSEL01 );

    UBRR0 = 103;
}

static void enable_usart0( void )
{
    UCSR0B = 1 << TXEN0;
}

static void transmit_usart0( uint8_t data )
{
    while ( !( UCSR0A & ( 1 << UDRE0 ))) {}

    UDR0 = data;
}

static uint32_t generate_value(
    char a,
    char b,
    char c,
    char d
)
{
    return (((uint32_t)a ) << 24 ) |
           (((uint32_t)b ) << 16 ) |
           (((uint32_t)c ) <<  8 ) |
           (((uint32_t)d ) <<  0 );
}

static bool transmit_callback(
    pb_ostream_t       * stream,
    uint8_t      const * data,
    size_t               count
)
{
    (void)stream;

    for ( size_t i = 0; i < count; ++i ) {
        transmit_usart0( data[ i ] );
        _delay_ms( 3 );
    } // for

    return true;
}

int main( void )
{
    configure_usart0();
    enable_usart0();

    for ( ;; ) {
        Example_Message const message = {
            .a = generate_value( 'a', 'b', 'c', 'd' ),
            .b = generate_value( 'e', 'f', 'g', 'h' ),
            .c = generate_value( 'i', 'j', 'k', 'l' ),
            .d = generate_value( 'm', 'n', 'o', 'p' ),
        };

        pb_ostream_t stream = {
            .callback      = transmit_callback,
            .state         = NULL,
            .max_size      = SIZE_MAX,
            .bytes_written = 0
        };

        pb_encode_delimited( &stream, Example_Message_fields, &message ); // encoded size is 21 bytes (varint message size plus 5 bytes per field)

        _delay_ms( 5000 );
    } // for
}

Compiled using avr-gcc 8.3.0 with the following flags/definitions:

-std=c17
-Werror -Wall -Wextra
-Wpointer-arith -Wstrict-prototypes
-mmcu=atmega328p -DF_CPU=16000000UL
-Os
-DNDEBUG

avr-size output:

   text	   data	    bss	    dec	    hex	filename
  10600	    518	      0	  11118	   2b6e	example

avr-size output with link time optimization enabled (-flto):

   text	   data	    bss	    dec	    hex	filename
   4014	    246	      0	   4260	   10a4	example

avr-size output with link time optimization enabled (-flto) and nanopb error strings disabled (-DPB_NO_ERRMSG):

   text	   data	    bss	    dec	    hex	filename
   3670	    68	      0	   3738	    e9a	example

Using some of the other nanopb compilation options may lead to further code size reductions.

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

breaking-out specific discussion on protobufs:

 

https://www.avrfreaks.net/forum/protobuf-google-protocol-buffers

 

 

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...