AVR Freaks

Stack takes some ram and if you have text strings or data that's not handled correctly (ie use PROGMEM or _flash) then this will be unnecessarily copied to RAM.

I think the T44 is an older chip, I would stick with the newer chips.

The USI is useful SOMETIMES but not as good as a real USART for comms if the chips has one.

How is the T841 supported in Arduino IDE, what core are you using (provide link please), or what board have you chosen in the board manager?

Jim

Sketch uses 1440 bytes (4%) of program storage space. Maximum is 32256 bytes.
Global variables use 184 bytes (8%) of dynamic memory, leaving 1864 bytes for local variables. Maximum is 2048 bytes.

so I guess it's a similar result. If I look at the build output (which I have set to verbose) to see where it built the ELF file I can then do:

...AppData\Local\Temp\arduino_build_816480>avr-nm --size-sort sketch_nov24a.ino.elf
00000001 b timer0_fract
00000004 b timer0_millis
00000004 b timer0_overflow_count
0000000c T __tablejump2__
00000010 T __do_clear_bss
00000012 d _ZTV14HardwareSerial
00000014 t _Z14serialEventRunv
00000014 t _Z17Serial0_availablev
00000016 T __do_copy_data
00000016 T __do_global_ctors
00000018 t _ZN14HardwareSerial9availableEv
0000001c t _ZN14HardwareSerial4peekEv
0000001e t _ZN14HardwareSerial17availableForWriteEv
00000028 t _ZN14HardwareSerial4readEv
00000040 t _ZN14HardwareSerial5flushEv
00000044 t _ZN14HardwareSerial17_tx_udr_empty_irqEv
0000004c T __vector_19
0000005a t _GLOBAL__sub_I___vector_18
0000005a t _ZN5Print5writeEPKhj
00000064 T __vector_18
00000094 T __vector_16
0000009a t _ZN14HardwareSerial5writeEh
0000009d b Serial
00000108 T main

This includes both RAM and flash but T/t = text, which are the size of things in flash are fairly irrelevant. What is important are those things in "b" or "d" as that is "BSS" (ie globals without init - so 0) and "data" (ie globals with init). as I asked for --size-sort (which was also responsible for it showing sizes, not addresses) then the list is in increasing order so the "big stuff" is at the bottom of the list. Bottom line the "Serial" class instance is using 0x9D bytes (157 bytes) of the RAm used  so it is is the "big chunk".

If you look at the class in:

D:\arduino-1.8.13\hardware\arduino\avr\cores\arduino>type HardwareSerial.h
/*
  HardwareSerial.h - Hardware serial library for Wiring
  Copyright (c) 2006 Nicholas Zambetti.  All right reserved.

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA

  Modified 28 September 2010 by Mark Sproul
  Modified 14 August 2012 by Alarus
  Modified 3 December 2013 by Matthijs Kooijman
*/

#ifndef HardwareSerial_h
#define HardwareSerial_h

#include <inttypes.h>

#include "Stream.h"

// Define constants and variables for buffering incoming serial data.  We're
// using a ring buffer (I think), in which head is the index of the location
// to which to write the next incoming character and tail is the index of the
// location from which to read.
// NOTE: a "power of 2" buffer size is reccomended to dramatically
//       optimize all the modulo operations for ring buffers.
// WARNING: When buffer sizes are increased to > 256, the buffer index
// variables are automatically increased in size, but the extra
// atomicity guards needed for that are not implemented. This will
// often work, but occasionally a race condition can occur that makes
// Serial behave erratically. See https://github.com/arduino/Arduino/issues/2405
#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif
#endif
#if (SERIAL_TX_BUFFER_SIZE>256)
typedef uint16_t tx_buffer_index_t;
#else
typedef uint8_t tx_buffer_index_t;
#endif
#if  (SERIAL_RX_BUFFER_SIZE>256)
typedef uint16_t rx_buffer_index_t;
#else
typedef uint8_t rx_buffer_index_t;
#endif

// Define config for Serial.begin(baud, config);
#define SERIAL_5N1 0x00
#define SERIAL_6N1 0x02
#define SERIAL_7N1 0x04
#define SERIAL_8N1 0x06
#define SERIAL_5N2 0x08
#define SERIAL_6N2 0x0A
#define SERIAL_7N2 0x0C
#define SERIAL_8N2 0x0E
#define SERIAL_5E1 0x20
#define SERIAL_6E1 0x22
#define SERIAL_7E1 0x24
#define SERIAL_8E1 0x26
#define SERIAL_5E2 0x28
#define SERIAL_6E2 0x2A
#define SERIAL_7E2 0x2C
#define SERIAL_8E2 0x2E
#define SERIAL_5O1 0x30
#define SERIAL_6O1 0x32
#define SERIAL_7O1 0x34
#define SERIAL_8O1 0x36
#define SERIAL_5O2 0x38
#define SERIAL_6O2 0x3A
#define SERIAL_7O2 0x3C
#define SERIAL_8O2 0x3E

class HardwareSerial : public Stream
{
  protected:
    volatile uint8_t * const _ubrrh;
    volatile uint8_t * const _ubrrl;
    volatile uint8_t * const _ucsra;
    volatile uint8_t * const _ucsrb;
    volatile uint8_t * const _ucsrc;
    volatile uint8_t * const _udr;
    // Has any byte been written to the UART since begin()
    bool _written;

    volatile rx_buffer_index_t _rx_buffer_head;
    volatile rx_buffer_index_t _rx_buffer_tail;
    volatile tx_buffer_index_t _tx_buffer_head;
    volatile tx_buffer_index_t _tx_buffer_tail;

    // Don't put any members after these buffers, since only the first
    // 32 bytes of this struct can be accessed quickly using the ldd
    // instruction.
    unsigned char _rx_buffer[SERIAL_RX_BUFFER_SIZE];
    unsigned char _tx_buffer[SERIAL_TX_BUFFER_SIZE];

  public:
    inline HardwareSerial(
      volatile uint8_t *ubrrh, volatile uint8_t *ubrrl,
      volatile uint8_t *ucsra, volatile uint8_t *ucsrb,
      volatile uint8_t *ucsrc, volatile uint8_t *udr);
    void begin(unsigned long baud) { begin(baud, SERIAL_8N1); }
    void begin(unsigned long, uint8_t);
    void end();
    virtual int available(void);
    virtual int peek(void);
    virtual int read(void);
    virtual int availableForWrite(void);
    virtual void flush(void);
    virtual size_t write(uint8_t);
    inline size_t write(unsigned long n) { return write((uint8_t)n); }
    inline size_t write(long n) { return write((uint8_t)n); }
    inline size_t write(unsigned int n) { return write((uint8_t)n); }
    inline size_t write(int n) { return write((uint8_t)n); }
    using Print::write; // pull in write(str) and write(buf, size) from Print
    operator bool() { return true; }

    // Interrupt handlers - Not intended to be called externally
    inline void _rx_complete_irq(void);
    void _tx_udr_empty_irq(void);
};

#if defined(UBRRH) || defined(UBRR0H)
  extern HardwareSerial Serial;
  #define HAVE_HWSERIAL0
#endif
#if defined(UBRR1H)
  extern HardwareSerial Serial1;
  #define HAVE_HWSERIAL1
#endif
#if defined(UBRR2H)
  extern HardwareSerial Serial2;
  #define HAVE_HWSERIAL2
#endif
#if defined(UBRR3H)
  extern HardwareSerial Serial3;
  #define HAVE_HWSERIAL3
#endif

extern void serialEventRun(void) __attribute__((weak));

#endif

then sure serial support has quite a few class members and they all have to be located in RAM somwhere but most of all are the _rx_buffer[] and _tx_buffer[] that I have highlighted. By default this bit is likely being used:

#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif
#endif

So on the whole you are going to get two buffers of 64 bytes. So that's 128 of your used RAM bytes before you even get started.

What is odd is that these #defines specifically cater for RAM sizes less than 1024 bytes and should make the buffers 16 bytes each rather than 64. But I'm guessing that in the "core" you use maybe this is not also the case?

If it is "SpecerKonde" then it would appear to be:

https://github.com/SpenceKonde/A...

but that actually does:

class HardwareSerial : public Stream
{
  private:
    volatile ring_buffer *_rx_buffer;
    volatile ring_buffer *_tx_buffer;

which seems to suggest the buffers are created elsewhere not within the class as the class only contains pointers, not an instances of the buffers?  In fact looking at the TinyCore HardwareSeiral.cpp I see:

#if (RAMEND < 1000)
  #define SERIAL_BUFFER_SIZE 16
#else
  #define SERIAL_BUFFER_SIZE 64
#endif

struct ring_buffer
{
  unsigned char buffer[SERIAL_BUFFER_SIZE];
  byte head;
  byte tail;
};

#if defined(UBRRH) || defined(UBRR0H) || defined(LINCR)
  ring_buffer rx_buffer  =  { { 0 }, 0, 0 };
  ring_buffer tx_buffer  =  { { 0 }, 0, 0 };
#endif
#if defined(UBRR1H)
  ring_buffer rx_buffer1  =  { { 0 }, 0, 0 };
  ring_buffer tx_buffer1  =  { { 0 }, 0, 0 };
#endif

So again they should be 16 byte, not 64 byte buffers.

Perhaps you are using some other "core" for tiny4x support ?

Anyway this post illustrates the analysis. It all hinges around finding out where Arduino builds the ELF and then run avr-nm on it.

So buy a few reels and ship them to your board house, or tell them to get them....  or tell them if they can't get them you will find a board house that can....!!!

Jim

Are there any where I shoot over the gerber/BOM/PnP and they can make the whole thing and will estimate the cost (per qty of course)?

Truck loads of them. I have used Elecrow a couple of times.

I use applied digital in branson mo, give them a call, they were very friendly and helpful for my project. https://www.appdig.com/  but there are many to choose from depending on where you live.

With out getting political, using a chinese pcb maker will mean you will soon find your product has been cloaned and made available for far less then you can make it.

why solder in the 2x3 header, I just place the header in my programmer, insert it into the holes and hold it while I burn program!