Author Topic: Failed first attempt to use ATMega on a breadboard.  (Read 6684 times)

0 Members and 1 Guest are viewing this topic.

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Failed first attempt to use ATMega on a breadboard.
« on: January 03, 2018, 12:21:33 pm »
I followed the guides on the Arduino website, but could not get the 328P from my UNO to work on a breadboard.

I don't have the 16MHz crystal so simply swapping the chip into the breadboard doesn't work.  I will need to flash the boot loader with the "Internal clock" bits set in the fuse.

When I tried this however using the schematic on the Arduino website it just didn't work.  "Timeout communicating"

I gather the tutorials and howtos are out of date now, some date from 2008, some from 2011.  Some seem to be for the 328 and I found various forum reference suggesting the fuse bits are different.  However that doesn't explain the lack of communications.

I then tried flashing the bootloader in the UNO board, but apparently that won't work over normal serial and needs to done over the ICSP header.

But I had given up at that point as it was 2am.

I ordered a handful of 16Mhz crystals and a few 5V regulators from RS so maybe that will make it easier.  I also have an ATTiny coming in the post which is why I'm looking into this first with the 328P to get a bit of know-how before I need to flash the ATTiny.

At ATTiny will run WS2811 LEDs from asm won't it?
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline sleemanj

  • Super Contributor
  • ***
  • Posts: 3020
  • Country: nz
  • Professional tightwad.
    • The electronics hobby components I sell.
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #1 on: January 03, 2018, 01:06:24 pm »
To flash serial bootloader and/or set fuses you need to do so over ISP, just buy a USBasp programmer

Miso->miso
Mosi->mosi
sck->sck
reset->reset
Vcc->vcc
Gnd->gnd

If you have a 16Mhz xtal and caps (but maybe breadboard has enough stray capacitance anyway) just choose arduino uno/pro-mini and use burn bootloader in IDE to set fuses.

Otherwise to use lower speed install a boards package, choose appropriate boards options and then burn bootloader to set fuses https://github.com/sleemanj/optiboot/blob/master/dists/README.md
~~~
EEVBlog Members - get yourself 10% discount off all my electronic components for sale just use the Buy Direct links and use Coupon Code "eevblog" during checkout.  Shipping from New Zealand, international orders welcome :-)
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #2 on: January 03, 2018, 02:41:52 pm »
To flash serial bootloader and/or set fuses you need to do so over ISP, just buy a USBasp programmer

This is the bit I'm, missing the arduino tutorials are trying to use the UNO board as a programmer with the chip removed, using digital pins 13,12,11,10 (from memory).
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #3 on: January 03, 2018, 03:16:51 pm »
You can use any functioning Arduino as a programmer to flash the bootloader in another Arduino circuit with the AVR chip in place. You need two microcontrollers - one to do the programming (programmer) and one to be programmed (target). I've used a Chinese clone Nano as a programmer and it worked fine. I believe you are limited to only the arduino supported AVRs via the board manager. Lots of examples on the web. If you go that route then you have the nano for other projects.

On your attiny question.  It depends on which attiny.  I've not been able to get the various WS2811/12/12B drivers to work on the ATTiny 85 at 8 MHz even though I've seen claims that they do work at 8 MHz. Drivers complain something like "not enough cycles". I have gotten one to work on the ATTiny 161x family which runs at 20 mhz with intOSC but doesn't program with ISP (it programs with UPDI, I use Atmel ICE). It looks feasible to add other attiny versions to the Arduino IDE though flashing the bootloader will still require some sort of UPDI programmer.  Wish Atmel had kept ISP support in the ATTiny 161x series - it's a fantastic little chip in many ways.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #4 on: January 03, 2018, 05:49:18 pm »
I think for the ATTiny85 you might need assembler for the pulse timing.  I was hoping for a bit of a challenge bit banging them.  As to how I can then get neat patterns and animations would be the really fun part.  I expect it will run initially on the UNO or Nano and port to the ATTiny eventually for finishing it off.

The ATTiny I bought 'claims' to be:
ATTINY85 20PU 8bit AVR Microcontroller 20MHz 8 kB Flash 8-Pin PDIP

But that is a chinese seller description, even though it was a UK only item.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #5 on: January 03, 2018, 06:08:14 pm »
Yes, the ws2811/12/12b require bit banging. All the libraries do that. The 85 defaults to 8Mhz.  I believe 20 mhz requires an external clock or crystal.  It looks like you can get 16 MHz with the High frequency PLL - you'll need to set the CKSEL fuse bits to get that.  Then, theoretically bit bang should work. I'll give it a try when I get time.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #6 on: January 04, 2018, 05:19:10 am »
Update.  Setting the PLL to 16 mhz works. 

I also got curious and went looking for asm code that drives the WS281x.  Found something that looks promising.  Using Atmel Studio 7, I have it sort of working at 8 MHz (needs some more attention though). Along the way I was reminded why I dislike Atmel Studio 7. Intensely dislike.  It seems if you mix ASM and C++ the assembler I/O port addresses are wrong. I found this out by debugging with Atmel ICE. I had to wade through the include files to discover why. What a load of crap. Not sure how someone without a debugger could have figured it out. Grrrrr.

Anyway, I need to play around with this code more because it's not working the way I expected but I can see with a logic analyzer that the timing is correct.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #7 on: January 04, 2018, 09:25:34 am »
Update.  Setting the PLL to 16 mhz works. 

I also got curious and went looking for asm code that drives the WS281x.  Found something that looks promising.  Using Atmel Studio 7, I have it sort of working at 8 MHz (needs some more attention though). Along the way I was reminded why I dislike Atmel Studio 7. Intensely dislike.  It seems if you mix ASM and C++ the assembler I/O port addresses are wrong. I found this out by debugging with Atmel ICE. I had to wade through the include files to discover why. What a load of crap. Not sure how someone without a debugger could have figured it out. Grrrrr.

What I meant was you should be able to get it working on 8Mhz with assembler.  The libraries are very inefficient.  I recall from a long evening watching youtube videos on the topic that the "FastLED" library is the better one, but it's still slow compared to toggling the data pin yourself in asm. 

Consider that, compiler optimisation (in-lining) aside a function call in C involves:

* Push all local variables and pointers currently in registers onto the stack  "N instructions"
* Push the return instruction pointer (IP) onto the stack "1 instruction"
* Push all function parameters onto the stack "N instructions"
* Copy the function address into the IP  (JMP) "1 instruction"

The function then:

* Pops the parameters off the stack
* Executes
* Pops the return address off the stack
* Pushes any return value onto the stack
* Copies the return address into the IP (JMP)

The calling code then:

* Pops the return value (if any) off the stack
* Pops all it's local variables back off the stack
* Continues

If you have a dozen or so local variables in registers and a half dozen parameters this single function call could result in 30 instructions, not including the code within the function itself.

In C++ if you are using classes it gets even worse as there are lookup V tables and what not to correctly determine the implementation involved in the call to potentially polymorphic methods.

In terms of efficiency you can see that from a development best practice point of view, dividing your code up into dozens and dozens of small nested functions to make it easier to maintain comes at a massive cost.  In normal enterprise business applications it doesn't really matter due to them running on multi-core processors clocked at 2.5Ghz and above with pipelining and what-not that can result in many instructions per single clock cycle.  It does matter in low latency applications such as stock exchange applications where microseconds cost millions and the speed of light is inconvenient.

In an average Enterprise Java application the number of Java code lines to assembler instructions could be a one to a million.  If written in assembler the code could be made 100,000 times faster.  But in Java world things are measured in milliseconds, not microseconds and if you need microsecond timing, you have to jump through all manor of hoops and optimise the JVM, heap, garbage collector etc. etc. etc.

C Compilers (and Java compilers) will optimise a lot of it for you.  If they determine that the full function call would be inefficient they will inline the code from the function directly, avoiding the function call overhead altogether.  (In Java world it will inline/sequence large nested calls and cache them in the JIT compiler). You can also pass the "inline" directive yourself to force inlining of functions.  At the cost of duplicating code in program address space.  Obviously the compiler needs to determine if you are tinkering with the stack in anyway or bad stuff could happen.  When running GCC for example in optimisation level 3 it is incredibly paranoid about your code and will throw errors and warnings if it's even slightly unsure about what you are doing with memory addresses.  (void*) for example or casting to (char*), the compiler will not touch it and will throw frame pointer errors if you attempt to optimise memory frames as it can no longer determine what exactly is in that memory address and what you have done with it.

If you think you can get around this by using inline assembler, think again.  The C compiler is not that easily fooled.  The optimisations occur after it has been assembled.  The compiler will also modify your ASM code because it will be using the registers itself to do stuff and needs to avoid collisions.  It might also use the stack to save and restore registers to allow you to use them for your ASM.  Sometimes its possible it can't work around your hard coded assembler and might very well cause a register collision which may well crash your program or give you rubbish data.  An example is you setting a register that the subsequent C code once assembled simply overwrites.  The register keyword can help, but IIRC it is "advisory" and not enforced and you don't choose which register to use.

GCC is a complicated beast best left to GCC aficionados.  I'm sure I have some of it wrong.  Inline assembler comes with risks.

As an aside, in multi-programming systems such as PCs the OS scheduler can and will suspend your code to handle an interrupt or allow another process to execute.  This involves copying the full CPU state and process state into memory, including all the memory look up buffers in the memory management unit.  Then copying the new processes full descriptor, CPU state and memory maps back into the CPU / MMU.  This can cost a microsecond or more.  If you need to get round it you can use processor core affinity to allocate a core specifically to your process.

I'm not sure how interupts are handled in MCUs, but I doubt there is a full context switch as above.
« Last Edit: January 04, 2018, 09:28:11 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #8 on: January 04, 2018, 04:23:41 pm »
Yes, I knew what you meant.  The FAST LED code complained about 8 MHz, not enough cycles and it's ASM.  What's interesting is they do it with asm directives in C++ code. 

I got the asm code working on an 8MHz Tiny85.  Driving 8 WS2812Bs right now.   Here's ASM code for Atmel Studio. The WS2812B uses GRB order.  Called from C++. You pass the GRB data and count to outputgrb.
Code: [Select]
;;
;;  outputgrb
;;      outputgrb( bufp, count);
;;      where:
;;        bufp - 16 bit pointer to 8 bit GRB sequences
;;        count - number of 8 bit GRB sequences (3 per LED)
;;
;;  This routine bit bangs the WS2812B LED at 8 MHz. The protocol is kind of ugly. It's timing
;;  based and there is no hardware in standard microcontrollers that can drive it so software
;;  is the only solution. Each bit is clocked at approx 1.25 uS with the length of the
;;  on section determining if it's a one or a zero. Each LED requires about a 30 microsecond
;;  command with interrupts disabled. Sure wish they just used good old SPI but that would
;;  have required an extra pin.
;;
;;  A 10 LED string will require 300 microsecond of interrupt off. A 100 LED string
;;  will take 3 mS.  A 1000 LED string will take, well you get the idea. The good
;;  news is the LEDS will continue for ever once sent a specific set of commands.
;;
;;  This code was originally written by Mike Silva and posted on his blog at [url=http://www.embeddedrelated.com]www.embeddedrelated.com[/url]
;;  with a very nice explanation of how it works.
;;
;;  Todo:
;;     - make output pin a parameter
;;     - mul count by 3 to make it 1 per LED, not 3.
;;     - investigate SPI version
;;     - rewrite for 16 and 20 MHz clocks
;;     - put on github
;;
 
 ; let us start off with a grotesque hack to make I/O PORT addresses be right under Atmel Studio 7
 #define __SFR_OFFSET 0x0
 #include <avr/io.h>
 .global outputgrb

 ; This is the output pin.
#define OUTBIT 4

outputgrb:
         movw   r26, r24      ;r26:27 = X = p_buf
         movw   r24, r22      ;r24:25 = count
         in     r22, SREG     ;save SREG (global int state)
         cli                  ;no interrupts from here on, we're cycle-counting
         in     r20, PORTB
         ori    r20, (1<<OUTBIT)         ;our '1' output
         in     r21, PORTB
         andi   r21, ~(1<<OUTBIT)        ;our '0' output
         ldi    r19, 7        ;7 bit counter (8th bit is different)
         ld     r18,X+        ;get first data byte
loop1:
         out    PORTB, r20    ; 1   +0 start of a bit pulse
         lsl    r18           ; 1   +1 next bit into C, MSB first
         brcs   L1            ; 1/2 +2 branch if 1
         out    PORTB, r21    ; 1   +3 end hi for '0' bit (3 clocks hi)
         nop                  ; 1   +4
         bst    r18, 7        ; 1   +5 save last bit of data for fast branching
         subi   r19, 1        ; 1   +6 how many more bits for this byte?
         breq   bit8          ; 1/2 +7 last bit, do differently
         rjmp   loop1         ; 2   +8, 10 total for 0 bit
L1:
         nop                  ; 1   +4
         bst    r18, 7        ; 1   +5 save last bit of data for fast branching
         subi   r19, 1        ; 1   +6 how many more bits for this byte
         out    PORTB, r21    ; 1   +7 end hi for '1' bit (7 clocks hi)
         brne   loop1         ; 2/1 +8, 10 total for 1 bit (fall thru if last bit)
bit8:
         ldi    r19, 7        ; 1   +9 bit count for next byte
         out    PORTB, r20    ; 1   +0 start of a bit pulse
         brts   L2            ; 1/2 +1 branch if last bit is a 1
         nop                  ; 1   +2
         out    PORTB, r21    ; 1   +3 end hi for '0' bit (3 clocks hi)
         ld     r18, X+       ; 2   +4 fetch next byte
         sbiw   r24, 1        ; 2   +6 dec byte counter
         brne   loop1         ; 2   +8 loop back or return
         nop
         out    SREG, r22     ; restore global int flag
         ret
L2:
         ld     r18, X+       ; 2   +3 fetch next byte
         sbiw   r24, 1        ; 2   +5 dec byte counter
         out     PORTB, r21   ; 1   +7 end hi for '1' bit (7 clocks hi)
         brne   loop1         ; 2   +8 loop back or return
         out    SREG, r22
ret

« Last Edit: January 04, 2018, 04:40:47 pm by phil from seattle »
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #9 on: January 04, 2018, 04:55:28 pm »
Interesting, literally instruction counting it.

I recall that the timing is not as critical as the protocol suggests.  I wish I could remember whose video it was but they determined you could get away with up to 5 microsecond per bit.  Obviously the timing of the 0 or 1 pulse is more critical.

The downside with that code is it won't work on a different clock.  Then again there isn't much you can do about that as interrupts will be too slow.

Also curious as to the parameters ending up in the 16 bit registers.  How do you call this from C++?  Is it an inline macro and you inject the params into the registers somehow and then insert the ASM macro?  Or do you just call it like a regular C function?
« Last Edit: January 04, 2018, 04:58:44 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #10 on: January 04, 2018, 05:49:35 pm »
The C/C++ call is simple in AVR GCC. It takes care of marshalling the params into regs. No stack is used other than the return address.
Code: [Select]
extern "C" void outputgrb( uint8_t *bp, int count);

uint8_t buf[] = {0xFF, 0x0, 0x0};

outputgrb(buf, 3);  // tell the WS2812B to display green
« Last Edit: January 04, 2018, 05:51:55 pm by phil from seattle »
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #11 on: January 04, 2018, 05:59:35 pm »
I found it in the Atmel documentation.

Quote
6. Parameter passing
Arguments in a fixed argument list are assigned, from left to right, to registers r25 through r8. All arguments use an
even number of registers. This results in char arguments consuming two registers. Additional arguments beyond that
which will fit in the registers are passed on the stack.
Arguments in a variable argument list are pushed on the stack in right to left order. Char arguments consume two bytes.

I wonder if GCC does the same or different though.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline Nusa

  • Super Contributor
  • ***
  • Posts: 2416
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #12 on: January 04, 2018, 06:22:41 pm »
https://www.microchip.com/webdoc/avrlibcreferencemanual/FAQ_1faq_reg_usage.html

In addition to the function call conventions, it's important to know what registers you must preserve when integrating with C code.

 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #13 on: January 04, 2018, 08:14:39 pm »
yup, it's all there in the doc.  well, almost all.
 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #14 on: January 04, 2018, 11:57:47 pm »
g++ in general doesn't emit vtables for classes without virtual functions.  Correspondingly, it doesn't emit vptrs for instances of classes without virtual functions.  The only compiler I'm aware of that does is Microsoft's, and they only do it (I think) because their DLL ABI requires pro forma vptrs, vtables (and RTTI info to boot) - so they do it by default unless told not to (there's a "novtable" declspec to suppress it).
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #15 on: January 05, 2018, 01:11:17 am »
I had a play with linking asm compiled modules and c compiled modules (mickey mouse example), but got it to work.   

I switched to avr-gcc to assmble from avra but I think both can be coaxed to work.  The default output of avra is not an elf object file so avr-gcc rejects it... or so it seemed.

I ended up with this build script:
Code: [Select]
# C Code
avr-gcc -Os -DF_CPU=16000000UL -mmcu=atmega328p -c -o blink.o blink.c

# ASM
avr-gcc -mmcu=atmega32 -nostartfiles -g ddrb_set.S -o ddrb_set.elf

# Linky blinky :)
avr-gcc -mmcu=atmega328p blink.o ddrb_set.elf -o blink

# Hex-ify
avr-objcopy -O ihex -R .eeprom blink blink.hex

# Upload
avrdude -C/etc/avrdude.conf -F -V -c arduino -p ATMEGA328P -P /dev/ttyUSB0 -b57600 -U flash:w:blink.hex

I then started into seeing if I could do PWM, kinda realised that it's not a assembler thing unless you do hot loop delays, so I started it in C.  Some of it could be converted to asm for efficiency, but meh.  Here it is, my first attempt to a LED PWM triangle wave.

Quote
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

#define DUTY_MAX 255
int duty = 0;

ISR(TIMER0_COMPA_vect)
{
   int led_state=PORTB & PORTB5;
   if( led_state > 0 ) {
     TCNT0 = 0; // Reset timer value
     OCR0A = DUTY_MAX-duty;
     PORTB = (1<<PORTB5);
   } else {
     TCNT0 = 0; // Reset timer value
     OCR0A = duty;
     PORTB = ~(1<<PORTB5);
   }
}

int main (void)
{
 /* set pin 5 of PORTB for output*/
 DDRB |= 0b00100000;

 duty = 0;
 int delta = 1;

    // Set the Timer0 Mode to CTC
    TCCR0A |= (1 << WGM01);

    // LED On
    PORTB = (1<<PORTB5);

    // On for 'duty' cycles
    OCR0A = duty;

    TIMSK0 |= (1 << OCIE0A);    //Set the ISR COMPA vect

    sei();         //enable interrupts

    // 64 prescaler
    TCCR0B |= ((1 << CS01) | (1<<CS00));
   
// Sweep duty
 while(1) {
        duty += delta;
        if(duty==DUTY_MAX || duty==0) {
          delta = -delta;
        }
       _delay_ms(4);
}
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #16 on: January 05, 2018, 07:43:58 pm »
The 328p from my UNO works on the breadboard fine with a 16Mhz crystal.  I can program it via the UNO board with jumpers to the relevant pins.

This removes the need to burn the bootloader which I get round to when I need to :)
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline AllTheGearNoIdea

  • Supporter
  • ****
  • Posts: 269
  • Country: gb
    • AllTheGearNoIdea
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #17 on: January 07, 2018, 09:03:54 am »
I recently had some pain trying to load the bootloader and the software onto an OpenLog device using the 328p. Kind of found the whole experience really quite tedious and unpleasant. You may get a laugh watching me have no idea what I’m doing. There are however lots of very good videos by people on YouTube that do know how to do this and advice on setting the AVR fuses so it’s worth having  a google. Bewarned my videos are pretty juvenile and silly so if you’re easily offend probably better not to watch.



https://youtu.be/xHvkOGR4nCs
AllTheGearNoIdea Where Its All About The Gear
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #18 on: January 07, 2018, 12:55:16 pm »
Thanks AllTheGearNoIdea, more videos to watch now :)

I had a few developments today.  My ATTiny85 arrived and a new bare chip Mega328P

I also got an FT232LR USB to serial adapter. 

Things didn't go well.

The FT232 doesn't appear to function in Linux.  This could be drivers, but I have what appear to be the relevant modules loaded.  The device "Fails to enumerate" and doesn't even get an ident in lsusb.  I'm not even sure the board is alive.  When I power it up, Power, Rx, Tx all flash 3 times and it goes dark.  I would have expected "Power" to remain on.

Anyway, so I moved to the 328P and put it into the breadboard my existing one was working on and tried to program it.  It was sold as having the bootloader installed and it's 5V.

Nothing. 

Swapped it into the UNO board and ... nothing.  D13 remains lit, but no communicado.

I was about to message the seller that's it's DOA but I noticed it says "Clock speed: 20Mhz".  I only have an 16Mhz xtal.  Surely this shouldn't matter though?

What are the normal symptoms of a non-bootloadered chip in an UNO board?  When I reset a normal 328P the Rx/Rx and builtin led flash a few times, this one does not do that, the built in LED comes on and stays on and that's it.

Not been a good "post bag" for me this morning.  Nothing worked.  Though I haven't tried the ATTiny, but that will need a bootloader installed.  I also have a strip of WS2811s to play with and a ADC breakout board.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline AllTheGearNoIdea

  • Supporter
  • ****
  • Posts: 269
  • Country: gb
    • AllTheGearNoIdea
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #19 on: January 07, 2018, 01:32:53 pm »
I think it’s likely that you know more about programming these than I do. But have you checked you have the correct ftdi cable etc. Just mentioned this as I think the Arduino IDE need to reset the 328 to make the boot load talk serial. The ftdi cable I used did not have the required DTR pin exposed to do the reset. So I used an alternative serial converter that has DTR. I believe you can also manually reset the 328 when you select programming in the Arduino IDE if you hold your tongue at the right angle.  I’m sure you will figure it out probably something obvious when you find it. Good luck.

Well I assume the clock speed will matter massively if the serial data clock is derived from the crystal.  I think you need to check that out.

I found the whole Atmel and AVR studio  and bootloader etc a total pain in the arse but then again I have no idea what I’m doing most of the time.

Regards Chris
« Last Edit: January 07, 2018, 01:37:42 pm by AllTheGearNoIdea »
AllTheGearNoIdea Where Its All About The Gear
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #20 on: January 07, 2018, 02:00:49 pm »
Current versions of AVRDUDE support resetting the target AVR using either DTR or RTS when using a bootloader.  For an Arduino compatible  reset circuit for a breaboarded AVR, simply use a 10K pullup on the /RESET pin, and a 100nF capacitor to couple it to either DTR or RTS of your USB<=>Logic Level Serial converter.

An AVR programmed with a 20MHz bootloader wont work with a 16MHz crystal as the baud rate it will accept will be 20% too low.  You should be able to reprogram it for a 16MHz bootloader (or even an 8MHz one using the internal oscillator) using an Arduino, the ArduinoISP sketch and a breadboard. See https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard

If you've FUBARed the fuses, it *MAY* need a HV parallel programmer to recover, but 90% of the time simply supplying a logic level clock signal of between 1MHz and 16MHz (use a crystal oscillator module) to the target's XTAL1 pin will allow normal logic level AVR ISP programming to work.
 
The following users thanked this post: AllTheGearNoIdea

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #21 on: January 07, 2018, 02:32:37 pm »
As to knowing more about programming these things, I only started using an Ardiuno about a month ago and only tried branching out from the IDE and into USB to serial about 2 weeks ago.  I'm a complete noob!  Being a software engineer does help, but only a little as my day job is on the other end of the spectrum from embedded stuff and MCUs.  I write enterprise banking applications and the like.

I'll look into it later in the week, I start back to work tomorrow after 3 weeks off 1 with flu, 2 for xmas, so I'm banned from electronics today.  Have to get back into routine for the ultimate Monday morning shock tomorrow.

I can't get the FTDI 232 board to work at all.  It might be bricked, but I'll try it in windows first in case it's a driver issue (highly likely).

I tried with another Adafruit multi-protocol serial/GPIO board based on the FT232L which does basic USB->Serial without poking at it, but it didn't work.  I might need to get use AVRDude myself to get it working as I don't know the default baudrate etc.  I have successfully used it to program an Arduino nano and uno, but the DTR (nor any of control pins) would reset the Arduino I had to do that manually for it to work.

And yes, you can reset the Arduino manually to flash.  The bootloader waits on serial for a brief while before going on and running the program.  So while AVRDude is running, usually timing out/unsync'd, you hold reset and try and let it go just before avrdude times out and retried.  It's fiddly but you get it after a few tries.

I think I need to get myself some reliable programmers that work in linux for both normal programming and ISP programming.  Any suggestions?
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 
The following users thanked this post: AllTheGearNoIdea

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #22 on: January 07, 2018, 02:38:40 pm »
Current versions of AVRDUDE support resetting the target AVR using either DTR or RTS when using a bootloader.  For an Arduino compatible  reset circuit for a breaboarded AVR, simply use a 10K pullup on the /RESET pin, and a 100nF capacitor to couple it to either DTR or RTS of your USB<=>Logic Level Serial converter.

An AVR programmed with a 20MHz bootloader wont work with a 16MHz crystal as the baud rate it will accept will be 20% too low.  You should be able to reprogram it for a 16MHz bootloader (or even an 8MHz one using the internal oscillator) using an Arduino, the ArduinoISP sketch and a breadboard. See https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard

Looks like I will need to flash the bootloader in the new chip, or chance buying a 20Mhz xtal for it from RS and see.  The ATTiny probably doesn't have bootloader so it will need doing too.  The target for that is to play with the WS2811s in assembler.

I didn't know about the 100nF cap for DTR->Reset.  I just had my DTR pin connected to RESET at the same times as the pull up resistor.  However it didn't work when connected to the UNO board either.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #23 on: January 08, 2018, 06:49:51 pm »
A subject near and dear to my heart.  These issues are all relatively easy to sort out but the number of moving parts make it hard to get everything to line up.

First, when you have a USB-Serial board (or circuit on a board) that's not working, you should do a "loop back" test.  This entails connecting the USB chip's RX to the USB chip's TX and use a terminal program to send characters. They should be echoed back to you. If not, your USB-serial isn't working. Baudrate doesn't matter (because TX and RX are the same). In this example, connect RX-I to TX-O


If your PC isn't seeing the USB-serial adapter, try switching to a different USB port.  Also, check to see that you have to most up to date USB driver.  Windows 10 seems pretty good but you never know.  I know Macs can be troublesome in that regard.

Atmel Studio 7. What a mess. I use it a lot and still wonder how self-respecting engineers could have ever let it ship. Just. Plain. Horrible. I'll stop here but could overflow buffers with this topic.

I agree most "bricked" AVRs can be rescued without HV programming but the specifics are chip dependent. Often the fuses are programmed wrong and you need to reset them. Look at the datasheet (warning, can be confusing at first, persevere). There are fuse calculators floating around but the best way to do it is to, shudder, use Atmel Studio 7 since it's up to date.  Warning for any debugWire AVRs (like the ATTiny85), do not let AS7 set the debugWire fuse (it readily offers to do it) as you will need Atmel ICE (or Dragon) to turn it off.  AVRISP, ArduinoISP, and most other cheap programmers will not see a debugWire enabled AVR.  Looks bricked because you need a debugWire programmer to turn off debugWire.

No bootloader for the ATTiny85. You can write code for it with the Arduino IDE but you need to program the chip via ISP (AVRISP or ArduinoISP programmers). Lots of tutorials on how to do that.

On a different point, there are some fake FTDI 232 chips out there. Quite a scandal a couple years back over genuine FTDI drivers "bricking" fake chips.  The CH340 based adapters do work.

 

Offline Nusa

  • Super Contributor
  • ***
  • Posts: 2416
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #24 on: January 08, 2018, 09:05:07 pm »

The FT232 doesn't appear to function in Linux.  This could be drivers, but I have what appear to be the relevant modules loaded.  The device "Fails to enumerate" and doesn't even get an ident in lsusb.  I'm not even sure the board is alive.  When I power it up, Power, Rx, Tx all flash 3 times and it goes dark.  I would have expected "Power" to remain on.

After you plug in the module, try "dmesg | grep ftdi" to see if the vcp drivers were loaded.
 

Offline m12lrpv

  • Regular Contributor
  • *
  • Posts: 175
  • Country: au
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #25 on: January 08, 2018, 10:32:19 pm »
Yes, the ws2811/12/12b require bit banging. All the libraries do that. The 85 defaults to 8Mhz.  I believe 20 mhz requires an external clock or crystal.  It looks like you can get 16 MHz with the High frequency PLL - you'll need to set the CKSEL fuse bits to get that.  Then, theoretically bit bang should work. I'll give it a try when I get time.

Glanced through the rest of your posts and didn't see you mention it but you did switch off the 8x clock divider didn't you?

(CKDIV8 on the fuse lowbyte)
If you didn't you'll be running at 1MHz with the 8MHz internal oscillator.


 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #26 on: January 09, 2018, 12:23:55 am »
Yes. if you saw later posts, I got it working at 8 MHz. Also, got it running at 16.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #27 on: January 09, 2018, 07:54:50 pm »

The FT232 doesn't appear to function in Linux.  This could be drivers, but I have what appear to be the relevant modules loaded.  The device "Fails to enumerate" and doesn't even get an ident in lsusb.  I'm not even sure the board is alive.  When I power it up, Power, Rx, Tx all flash 3 times and it goes dark.  I would have expected "Power" to remain on.

After you plug in the module, try "dmesg | grep ftdi" to see if the vcp drivers were loaded.

No, I think it's DOA.  I can't even detect if it's a fake FTDI as it's just plain broken.

Still to test in windows, but here is the diagnostics:

Code: [Select]
[ 7147.243011] usb 3-2: new low-speed USB device number 12 using xhci_hcd
[ 7147.363067] usb 3-2: device descriptor read/64, error -75
[ 7147.473004] xhci_hcd 0000:06:00.0: WARN urb submitted to disabled ep
[ 7147.473010] xhci_hcd 0000:06:00.0: WARN urb submitted to disabled ep
[ 7147.473014] xhci_hcd 0000:06:00.0: WARN urb submitted to disabled ep
[ 7147.593062] usb 3-2: device descriptor read/64, error -2
[ 7147.823020] usb 3-2: new low-speed USB device number 13 using xhci_hcd
[ 7147.943063] usb 3-2: device descriptor read/64, error -75
[ 7148.053003] xhci_hcd 0000:06:00.0: WARN urb submitted to disabled ep
[ 7148.053009] xhci_hcd 0000:06:00.0: WARN urb submitted to disabled ep
[ 7148.053012] xhci_hcd 0000:06:00.0: WARN urb submitted to disabled ep
[ 7148.173064] usb 3-2: device descriptor read/64, error -2
[ 7148.402999] usb 3-2: new low-speed USB device number 14 using xhci_hcd
[ 7148.403287] xhci_hcd 0000:06:00.0: ERROR: unexpected setup address command completion code 0x3.
[ 7148.613287] xhci_hcd 0000:06:00.0: ERROR: unexpected setup address command completion code 0x3.
[ 7148.822963] usb 3-2: device not accepting address 14, error -22
[ 7148.943007] usb 3-2: new low-speed USB device number 15 using xhci_hcd
[ 7148.943282] xhci_hcd 0000:06:00.0: ERROR: unexpected setup address command completion code 0x3.
[ 7149.153282] xhci_hcd 0000:06:00.0: ERROR: unexpected setup address command completion code 0x3.
[ 7149.362996] usb 3-2: device not accepting address 15, error -22
[ 7149.363032] usb usb3-port2: unable to enumerate USB device

Code: [Select]
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 011 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 007: ID 044f:0404 ThrustMaster, Inc. HOTAS Warthog Throttle
Bus 009 Device 006: ID 045e:07f8 Microsoft Corp. Wired Keyboard 600 (model 1576)
Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 005: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 008 Device 004: ID 044f:0402 ThrustMaster, Inc. HOTAS Warthog Joystick
Bus 008 Device 003: ID 131d:0158 Natural Point
Bus 008 Device 002: ID 08bb:2702 Texas Instruments PCM2702 16-bit stereo audio DAC
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Code: [Select]
paul@localhost ~/Downloads $ python detect_ftdi_clone.py
Detecting device...
No devices found

The power, rx and tx lights flash 4 times when I plug it in, but then nothing.  No power light even.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #28 on: January 09, 2018, 08:57:19 pm »
Mission complete.

Stage 1:
ATMega328P (bought from RS arrived today) on a breadboard w/ 16Mhz xtal
UNO Board as ISP
Burn boot loader.  After some faffing this worked!

Stage 2:
AdaFruit USB to Serial/GPIO FT232H board
Tx/Rx connected.
Nothing.

Disconnected the 5V PSU and powered the breadboard from the FT232H board
Retried.
Success!

A few issues.  The FT232H board does not seem to work with resetting the board. However I found the timing is simple.  Hold the reset pin to ground with a jumper, hit ENTER on the avrdude command, pull the reset jumper at the same time.

It's odd that the FT232H will not program the board if it's not powering it.  Maybe I have a ground mismatch, but I doubt it.

Also, there was nearly a casualty.  I had the 328P power by a 5V regulator and I connected the FT232H's 5V on the same rail thinking this would be fine.  No.  The smell alerted me that something wasn't right.  5V reg and the 5V/GND wires to the FT232 were toasty.  I think the 5V reg provides a path to GND if you put a voltage on it's output.  Whatever it didn't like it.  Nothing died though.  Chip, regulator, FT232H all survived.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #29 on: January 10, 2018, 08:57:25 pm »
And the ATTiny85 followed tonight using the Arduino UNO as ISP again I managed to set it's internal clock to 16Mhz and get it to run a set of 10x3 WS2811 LEDs with FastLED.

I was hoping it would not work, but when it accepted the 16Mhz clock I knew FastLED would work.

Still I'll have a play with assembler with them too.

Slightly miffed that the LEDs turned out to be 10 sets of 3 LEDs.  ie.  3 LEDs per WS8211 chip instead of 1.

Time to go back on ebay for some better ones.

Also slightly daunting, but I trusted myself as I these LEDs are 12V.  So I have 12V sometimes at 0.5Amps running right beside the ATTiny which is got a tiny little 5V regulator defending it.  No smoke has been released.
« Last Edit: January 10, 2018, 08:59:38 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #30 on: January 11, 2018, 04:44:23 pm »
Go for WS2812Bs - they are an all in one 4 pin 4mm x 4mm chip. Same protocol. Be aware there is a difference between WS2812 and WS2812B - the former is 6 pins and the latter is 4. Here's one of my PCBs with 8 WS2812Bs and and an ATTiny 85 on it. (the wires are for a logic analyzer to look at the protocol). and, yes, I need to scrub the flux off.

By the way, I got the same code I posted previously running on an ATTiny 1614. I'm really liking the ATTiny 161x family.

Edit: the WS2812Bs are 5V chips.

« Last Edit: January 11, 2018, 04:49:16 pm by phil from seattle »
 

Offline Avacee

  • Supporter
  • ****
  • Posts: 299
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #31 on: January 11, 2018, 04:52:32 pm »
A few issues.  The FT232H board does not seem to work with resetting the board. However I found the timing is simple.  Hold the reset pin to ground with a jumper, hit ENTER on the avrdude command, pull the reset jumper at the same time.

You need a capacitor on the reset pin - I had a search but google-fu is weak but if you look around you can probably find it.
This gets the timing on the reset correct and saves you having to time it manually.

Edit: Google-fu is back:
http://forum.arduino.cc/index.php?topic=296374.0
https://electronics.stackexchange.com/questions/106870/programming-an-atmega328-with-arduino-bootloader-via-a-ftdi-usb-serial-adapter


« Last Edit: January 11, 2018, 06:24:39 pm by Avacee »
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #32 on: January 11, 2018, 09:05:34 pm »
WooHoo!

I could see this coming.

I killed one.  Gonna need to build a HV fuse programmer. 

I killed it while figuring out if I could program it while it was running the LED strip.  It obviously failed due to interference / impedance and what not, so I put a small 220Ohm resistor on the data line, the LEDs continued to work.  Hit upload on the IDE and it uploaded and then failed verification.  When I then attempted to flash it again, "Yikes, invalid device signature 0x00000"

Tried everything from the google searches including using an external crystal.  It's dead Jim.

Swapped in another ATTiny and it worked fine.  I've labelled it and might get round to fixing it some night I'm bored and want to knock up the HV programmer circuit.

It's a bit of a bugger as the plan was to put the tiny on a perf board and wrap it in heatshrink to run the 1 meter strip as a background light on my monitor to replace the rubbish blue LEDs it has, which don't even light the desk underneath it up.  Was going to wire it from an old external harddisk 12V supply.  However I wanted a way to reprogram it, so was going to attach the ISP pins to a header.  It appears that with pin 0 connected that's not going to work.   

Although come to think I could always run the LED data line off pin PB3 which might (hopefully) not interfere with any of the ISP pins.
« Last Edit: January 11, 2018, 09:09:06 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #33 on: January 14, 2018, 05:55:12 pm »
I got a USBAsp and my first reaction is... WTF?

Apparently he has received warnings from the USB consortium about making up his own VID and releasing devices on it. So he no longer sells them (they are probably cloned a lot now though)  But that isn't my issue.  It's a barebones USB to chip with the Atmel MCU apparently doing the USB communications.  There is no USB interface chip.  It appears to be bit banging the USB.

So when you plug it it does not register with the OS, there is no driver, it's a completely unknown device.  The only way to access it is via the raw USB bus interface (in /proc or /sys on linux).

Devices that use it such as avrdude look for the VID and serial code in that bus interface and read/write directly to the USB Rx/Tx lines.

U...g...l...y.

I suppose if it works, it works. 

"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #34 on: January 14, 2018, 06:06:41 pm »
Then I'd buy an Arduino Nano and use the ArduinoISP sketch. Easy to build the circuitry around it on perf.  I have a PCB for that. You can order it through OSHPark - $9 for 3 boards. https://oshpark.com/shared_projects/oT9Wuzrx
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #35 on: January 14, 2018, 06:17:18 pm »
Then I'd buy an Arduino Nano and use the ArduinoISP sketch. Easy to build the circuitry around it on perf.  I have a PCB for that. You can order it through OSHPark - $9 for 3 boards. https://oshpark.com/shared_projects/oT9Wuzrx

Other than a Nano and a bunch of jumper leads what else is needed?  I thought it was literally just jumpers from the SPI pins?  That's what I used from the UNO and it worked fine.

Is the extra circuitry going to help with interference from the LED data line being connected to the ATTiny85?
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #36 on: January 14, 2018, 08:08:46 pm »
I don't think the LED data-in line is a problem though I put it on PB4 just to eliminate that concern. You might see some funky colors on the strip during programming.

Here's my schematic for the Nano ISP programmer. ISP header, LEDs, 10 uF cap you can switch into reset in the case your target needs it. I also included a jumper to allow programming the nano via the header. Makes a nice little package.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #37 on: January 14, 2018, 08:35:17 pm »
LED Dataline is definitely a problem.  With my LED data line on PB0 shared with MOSI AVRDude would lose sync with the device in the middle of programming it.  When I tried a resistor to dampen the effect it bricked the Tiny with corrupted fuses after a failed verify.

On all occasions if I disconnected the data line, all worked fine.

As you say, there are other pins.  PB4, for example.

I'll maybe check the schematic out.  If that the PCB you linked earlier?
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #38 on: January 14, 2018, 08:39:06 pm »
yes. same as the pcb
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #39 on: January 21, 2018, 03:17:35 pm »
Finally got an in circuit programmer working for my LED dev board.

Just an ATTiny85 w/ 5V regulator, 100uF cap, 100nF cap, 470Ohm resistor+ power LED.

On one end it has a 4 pin header for SCK,MISO,MOSI,RST and a single pin for GND.  On the otherside it has a single data pin for the LEDs and a DC socket with 12V links for the board and the LED strip.  All on a perf board, wrapped up tight in a shrink wrap tube, so it can knock about my desk and not short anything.

I can now program the ATTiny without even disconnecting the LEDs.

Out of interest, apparently Atmel say you need 860 Ohms between the active circuit and the programmer pins to program in circuit if you are sharing pins.  So my previous resistor idea was on the right track, just not enough.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: gb
Re: Failed first attempt to use ATMega on a breadboard.
« Reply #40 on: January 28, 2018, 05:50:11 pm »
Ahhhhh, the guessing is over.

One HV programmer.  So I no longer need to guess why the chip won't talk nice.  I can probe and set it's fuses.

Put all my Megas into external clock (UNO) mode.  Now just need to modify it for ATTiny85 and see if I can fix them up a bit.



Out of interest.  I highly recommend these breadboards.

Pro's kit BX4112N .  The connections are positive, they tactilely feel good and I've never had an issue.  Note the round holes and fluting appears different, slightly rounded round the pins.  They are backed by hard blue plastic too.  Think I got them on CPC.

« Last Edit: January 28, 2018, 05:54:50 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf