Attiny841 vs 441 vs 44A and other questions

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

I have a circuit that is working nicely with an Attiny841, but failed with an Attiny441. I am considering the Attiny44A.

 

The circuit is a lithium cell monitor that uses 1 attiny to measure voltage and temperature. Each cell is daisy chained. The controller knows it has N cells, and sends N*4 bytes down the serial chain. Each cell writes it's 2 ADC values into the payload and relays it on to the next cell in the chain.

 

This sketch goes to sleep for 4 seconds. If the watchdog wakes it, it just turns off a load resistor and goes back to sleep. If it wakes from the serial port, it reads 2 ADC values, reads the serial data of at most 70bytes, optionally turns on that load resistor, retransmits the input serial data, and goes back to sleep with a new 4 second watchdog. It has 2 LEDs for no particular reason other than to help me debug.

 

I am using platformio and the arduino framework.

 

The serial com is set to 2400 baud. I use the PacketSerial library to encode/decode the bytes. (I am using a framing marker of 0, and I just realized that 0xff is probably much more appropriate for my data).

 

The Attiny841 works nicely because it is very low power when asleep. However, JLCPCB does not stock these terribly often. When I used the attiny441, it fails to read the serial data. It wakes up, but won't flash my LED indicating it got more than 0 bytes.

 

Questions:

1) I noticed that the thing is using 251 bytes of ram, which seems odd since I only have around 80bytes of static variables. A blank arduino sketch seems to eat up 170 or so bytes. I am thinking that the 441 is probably crashing because it is going past the real RAM. Is the arduino stuff bringing in some baggage that I don't want? Should I switch to Microchip Studio and start with a blank project? Is that a quick way to eliminate baggage I don't want?

 

2) Am I correct to think that the only thing that would be different from the attiny441 and attiny841 is the size of the ram and EPROM? The documentation shows 2 huge sections that show the electrical characteristics of each, but I can't find anything to suggest these are different and I have no desire to compare these many many charts looking for a meaningful difference.

 

But the attiny441 is not a lot more available at JLCPCB anyway.

 

3) The Attiny44A comes in a DIP package so I can hand solder it, if JLCPCB is out of the SMT part. So, I tried to run my code on the Attiny44A, but it failed to compile. The difference I see between the 44A and the 441 is the 441 has a UART and the 44A has the USI. My understanding is that I can do serial communication in the 44A using software serial. What's the effective difference for me? In both cases I am calling Serial.write/read, so why do I care if there's a UART vs USI? My bet is that I will need to wire up something that wakes the attiny to read the serial data. Am I correct about that?

 

What other differences will I find when switching from the 841 to 44A?

 

4) I've noticed the 0-series and 1-series and what looks like some helpful documents. What series is the 841/441? How does the 84/44/24 84A/44A/24A relate? Is there some key words I could use to help me find examples for these?

 

Thanks in advance for any advice you have to shorten my experimentation to get me productive sooner.

Last Edited: Sun. Nov 22, 2020 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the only thing that would be different from the attiny441 and attiny841 is the size of the ram and EPROM?

No, the MAIN difference would be the flash size, 8K vs 4K , will your code fit into the 4K chip?

I can't find anything to suggest these are different

How about JUST the first page of the docs?

 

 

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Sun. Nov 22, 2020 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I should have made it more clear. I totally get the EEPROM, FLASH and RAM size difference between the 841/441 and yes, my code seems to fit in the 441 easily. However, the RAM is close, but my statics are only about 70 bytes. Something is eating 170 or so bytes of RAM. I was asking if there's something that the arduino framework brings in that I don't need and the easiest way to eliminate that. 

 

441/841 has 256/512 Bytes Internal SRAM

Last Edited: Sun. Nov 22, 2020 - 10:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Thanks, I have no strings, and only a few static variables and the serial buffer of about 64 bytes. You didn't blame Arduino, so I think I will start with a blank project and add my stuff in and watch what eats that RAM.

 

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

The linker in the AVR toolchain can output a map file which shows where the flash and ram are being used. I'm not familiar with platformIO and how it configures the toolchain.

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

Not very cluey about Arduino stuff, I have occasionally used some Arduino code or done some small project where the client wanted to use Arduino.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Here's a useful function for determining free memory at runtime.

 

int freeSRAM(void) {
#ifdef __AVR__
  extern int __heap_start, *__brkval;
  int v;
  return (int)&v - (__brkval == 0 ? (int)&__heap_start : (int)__brkval);
#endif

#ifdef ESP32
  return ESP.getFreeHeap();
#endif
}

 

I'd run it at the end of setup() and then periodically from loop().

 

As John points out, the compilation output is based on global and static variables. Anything declared in a function will use the stack. 70 bytes doesn't feel like sufficient headroom to me.

 

This is a useful explanation: https://learn.adafruit.com/memor...

 

Last Edited: Sun. Nov 22, 2020 - 11:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#include <Arduino.h>

void setup() {
  Serial.begin(2400, SERIAL_8N1);
}

void loop() {
}

This sketch uses 159 bytes of RAM. If I comment out the Serial.begin, it uses 9 bytes. Then my 64 byte buffer eats the rest of the 256. How annoying. My serial stuff needs just the 64 bytes total. It can read into that buffer, do the decoding in place, modify, encode for sending all without copying it elsewhere.

 

Looks like I need to sort that out if I want to jump to the 44A, so I might as well tackle that now.

 

Do you have any thoughts on the 44A USI, vs the 441 UART differences or any other differences?

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

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.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

A 441 should be "very compatible" with an 841, except for the memory sizes.

 

This sketch uses 159 bytes of RAM. If I comment out the Serial.begin, it uses 9 bytes. Then my 64 byte buffer eats the rest of the 256.

 I'm pretty sure that the Arduino Serial has 64 bytes of serial buffer in each direction; you can look at changing that...

 

Why do you want to leave the 841, anyway?  The 441 is only a tiny bit cheaper, and the t44 is more expensive, even though its capabilities are worse.

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

I have created a COBSerial which is a heavily modified HardwareSerial that does away with the receive ring buffer. I do the COBS decoding in place, and my thingy modifies that data, the COBSerial then encodes the COBS in place and shoots it out. My RAM is now a comfy 100 or so bytes. (It is rather amazing the ludicrously small numbers, I mean 256 period, not a tiny 256k, or even a minuscule 256m). 

 

I wanted the 441 because the 841 is rarely in stock at JLCPCB. Now I have 2 choices.

 

I wanted the 44A because it comes in DIP and surface. So I would have a 3rd option at JLCPCB with 100+ in stock, and a 4th where you buy separately and solder the chip.

 

 

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

The USI makes an awful UART, most would rather use a soft serial, the USI is much better at SPI or I2C then async serial operation, you would be better off finding another board house that has access to the t841's you need, its not like there is only one board house, or a shortage of t841's.

 

Jim

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

I don't think I care. The device has nothing to do until it receives the packet. Once it receives it, it fires up the Vref, reads the ADC, stuffs that into the packet, and sends it on. So async is irrelevant. 2400 baud is fine. Right now the packet arrives every 2 seconds, which is plenty of time for a string of these to read, measure, and pass along.

 

But, I agree that it's probably not worth the software work.

 

Thanks for the info.

 

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

But just for my knowledge, am I correct to think that I would want a separate line going to the chip to wake it from the sender? Or can the same Rx pin wake it up no problem?

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

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

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

ki0bk wrote:

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

 

 

https://github.com/SpenceKonde/A... possibly. I think I used this combo on a board with multiple 841s as serial/I2C bridges.

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

I'm using platformio within visual studio code, so I am not using the arduino IDE. I have only used this setup, so I have no clue how well it is supported compared to other IDE. I'm able to make a project for that chip, and then it seems to provide me with the serial and other register stuff that matches the chip. It bitches at me if I try to flash the new code onto the 441 when it is set to 841. I have no complaints.

 

I don't have a dev board. I program the chip on my useful circuit that's on a PCB.

 

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

But just for my knowledge, am I correct to think that I would want a separate line going to the chip to wake it from the sender? Or can the same Rx pin wake it up no problem?

The 841/441 can wake up on start of frame, as I think you already have discovered. Do you mean if the 44A can do the same? If you're doing a soft uart then the Rx is just a normal gpio. For the USI I don't remember, but I'd guess Idle sleep would probably be the deepest you can use with that.

4) I've noticed the 0-series and 1-series and what looks like some helpful documents. What series is the 841/441? How does the 84/44/24 84A/44A/24A relate? Is there some key words I could use to help me find examples for these?

These chips predate the 0-series and 1-series nomenclature. "tinyAVR" is the closest equivalent to a series with these. The 841/441 are newer and have some more features than the 84A/44A. And the 'A'-versions are updates to the original 84/44.

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

johntaves wrote:

#include <Arduino.h>

void setup() {
  Serial.begin(2400, SERIAL_8N1);
}

void loop() {
}

This sketch uses 159 bytes of RAM. If I comment out the Serial.begin, it uses 9 bytes.

I just built it in Arduino simply set for the default "Arduino Uno" (which is mega328P) and I find:

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.

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

Did I overlook some other options besides the 44A, 441?

 

I want:

1) very low power consumption while waiting for either watchdog or serial to wake it. These are like 1.3uA with WD enabled.

2) I want to measure the voltage that is powering the chip, so unless the chip has an reference voltage that is independent of the variable supply voltage, I need vref in.

3) Measure a thermistor so at least 2 ADC readings.

4) blink an LED (so I know it's alive), 2 would be nice

5) serial communication, but software serial is probably good enough.

 

If there is another option and JLCPCB has a truckload in stock, I'll switch to it.

 

Thanks for the help. I appreciate it.

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

 

johntaves wrote:

Did I overlook some other options besides the 44A, 441?

 

I want:

1) very low power consumption while waiting for either watchdog or serial to wake it. These are like 1.3uA with WD enabled. Any AVR with p after it's name (p= pico power)

2) I want to measure the voltage that is powering the chip, so unless the chip has an reference voltage that is independent of the variable supply voltage, I need vref in.  (most if not all AVR's have one or more internal vref's)

3) Measure a thermistor so at least 2 ADC readings. (Most AVR's have an ADC with mux, some even have an internal temp sensor)

4) blink an LED (so I know it's alive), 2 would be nice (nothing here it see, move along)

5) serial communication, but software serial is probably good enough. (The AVR you have chosen seems an ideal fit, it even has two USARTS)

 

If there is another option and JLCPCB has a truckload in stock, I'll switch to it. (Lots of other board houses, and as far as I know, no shortage of AVR's, digikey, mouser, farnel, etc.)

 

Thanks for the help. I appreciate it.  (Your welcome)

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

 

 

 

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

Last Edited: Tue. Nov 24, 2020 - 08:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yea, I know I can get them from other places. JLCPCB is in china. I just pump in my gerber, BOM, and PnP file to their website, and a few days later the PCB shows up with all the SMT stuff on it. I just solder the THT stuff, which I buy from digkey or mouser. I have soldered the attiny SMT, and it was not that bad, but I want to enable others to make this board.

 

If I open source this design, then I would really like to make it so that nobody has to do surface mount. The THT is easy enough for a novice to solder, but the SMT is a PIA.

 

The other option is to get a board house to make the whole thing, including the THT stuff. I've never done this so I am a total noob.

How do I revise the board to make it cheaper to build? I expect I would have a conversation with them and they would suggest different, but similar, parts to make it easier.

What board/assembly place should I pick?

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)?

 

If I go this route, maybe I should have them burn the EEPROM, so the thing is turnkey. I assume that is possible, but maybe they have to have equipment to hold the chip to burn it before it is mounted. Right now, I solder in a 2x3 header so I can burn it. That's an annoying thing to solder in for a 1x use. I wonder if I can buy the attiny burned with my code and I hand solder it?

 

I apologize for moving off topic, but this does fall back to what attiny I use. And again, this the advice is highly appreciated.

 

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

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.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

johntaves wrote:
If I go this route, maybe I should have them burn the EEPROM, so the thing is turnkey. I assume that is possible, but maybe they have to have equipment to hold the chip to burn it before it is mounted.
Some distributors can program AVR; likewise Microchip.

johntaves wrote:
Right now, I solder in a 2x3 header so I can burn it. That's an annoying thing to solder in for a 1x use.
Tag-Connect is somewhat popular though a PCBA manufacturer may prefer pogo pins.

 


AVR8 on Microchip Direct | AVR Freaks

https://www.microchipdirect.com/product/search/all/ATtiny44A

[select PDIP, should see "Upload your code ..."]

 

- Tag Connect (AVR via AVRISP mkII or Atmel-ICE; AVR on MPLAB Snap and MPLAB PICkit 4 are forthcoming)

 

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

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

johntaves wrote:

Yea, I know I can get them from other places. JLCPCB is in china. I just pump in my gerber, BOM, and PnP file to their website, and a few days later the PCB shows up with all the SMT stuff on it. I just solder the THT stuff, which I buy from digkey or mouser. I have soldered the attiny SMT, and it was not that bad, but I want to enable others to make this board.

 

If I open source this design, then I would really like to make it so that nobody has to do surface mount. The THT is easy enough for a novice to solder, but the SMT is a PIA.

 

The other option is to get a board house to make the whole thing, including the THT stuff. I've never done this so I am a total noob.

How do I revise the board to make it cheaper to build? I expect I would have a conversation with them and they would suggest different, but similar, parts to make it easier.

What board/assembly place should I pick?

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)?

 

If I go this route, maybe I should have them burn the EEPROM, so the thing is turnkey. I assume that is possible, but maybe they have to have equipment to hold the chip to burn it before it is mounted. Right now, I solder in a 2x3 header so I can burn it. That's an annoying thing to solder in for a 1x use. I wonder if I can buy the attiny burned with my code and I hand solder it?

 

I apologize for moving off topic, but this does fall back to what attiny I use. And again, this the advice is highly appreciated.

 

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

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!

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

Lets go Brandon!

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

Good point about China.

 

I have no idea why I have not just held the 2x3 in place while I programmed it. I thought about trying that several times, but then managed to forget that and soldered in the 2x3 a billion times now. DUH!!! Thanks.