atmega still alive ?

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

Hi, this is probably, or even hopefully a stupid question....

 

but,

 

I have tried to follow links, (im a clearly intermittant micro-developR) and seen that all are broken by microsnip management;

 

but worse, I tried to see what processors they supply (!?) and I dont find much at all, hopefully Im hopless in finding things,

 

or are they closing down most avr's ?

This topic has a solution.

Last Edited: Thu. Oct 10, 2019 - 09:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

try looking here, it might highlight some popular parts:

 

https://www.digikey.com/products/en/integrated-circuits-ics/embedded-microcontrollers/685?k=atmega

 

What broken link(s) did you try?

 

hopefully Im hopless in finding things,

I hope your luck hopefully changes

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

OK, actually I did find that digikey.com page (though I had problem in selecting avr with 2 UART... :)   

 

but then I wanted to see what microchip themselves offered and found only a 4809 somthing family which seems to be a much bigger thing, and no other..

but Ok all the old processors like m8, and the m48 like are still in there but I dont find...)

 

(and yes the first broken link was to atmel.com and for the same purpose, processor selection)

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

I agree the MC web site makes it very difficult to find what you are looking for...

 

And I think I'm viewing their recently new-and-improved web site...

 

Anyway, HERE is the "Big List" of all of their microcontrollers, Pics, AVRs, 8051's, etc., along with a parametric search.

 

JC

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

aH lots of thanks,

/ge

 

(And I guess it possibly would not make much diff, if microchip themselves stopped producing, guess the china will continue supply as long as there is demand ...)

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

actually; reading further in the datasheet chapter 17 (atmega48-328 family sheet) USART0 Im totally at loss for the "generality genie" of the descriptive text, I just cant make out what the n in e.g.  (UDRn) etc stands for

are there more pins for TX & RX then in the PINout, and which are in that case those PINS !! pray

(my aim is to construct something I though I could do, have to physically separated USART i/o's....)

 

OK found that, jim's explanation in thread:

 

https://www.avrfreaks.net/forum/...

 

the 2 UART are only present in 328PB but not in 328P  AND there should be (are) different datasheets .......  so I have the wrong datasheet 48P-328P will go look for 88PA 

 

this is scary experience; finding a datasheed where it says 88PA in blue all over, and when downloading still having only 88P series....... 

(the table on microchip says that 88PA should have 2 UART, and Im frantically trying to find a pinout with TXD0 AND TXD1 on it..... or am I wrong)

Last Edited: Wed. Mar 6, 2019 - 01:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IMO, the best way to find AVR chips with desired specs is the advanced parametric search at Microchip: https://www.microchip.com/maps/M...

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

Another option for a 2 usart solution is the mega324. Nice part. I use them all the time

Jim

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

 

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

 

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

 

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

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

 

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

Please Read: Code-of-Conduct

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

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

but but, Im eager to get going, my project stuck (communicating sms with M590) since I realized I needed to talk USART (conviniently) with both PC and M590,

and I first though I needed to wait for a new chip (working on a M8) but then realized I have a m88PA, and that that could get me stumbling on.....

well I think Im actually too eager, the seletion table didnt reset filter when choosing a specific component, so now I doubt that m88pa has 2uart.., so yes I guess I need a new chip /ge

 

PS havnt see :  Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"  before, but I guess that latter is anyway a kind of too Broadway :) DS

Last Edited: Wed. Mar 6, 2019 - 02:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

IMO, the best way to find AVR chips with desired specs is the advanced parametric search at Microchip: https://www.microchip.com/maps/M...

Right, checking this gives good information on each chip, thanks. I also see that I dont have any 2usart chip at home. 

 

and yes, 324 will be the one to go for , thanks all

 /ge

Last Edited: Wed. Mar 6, 2019 - 02:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

None of the mega 48/88/168 have two USARTs

according to the datasheets I have.

 

A similar chip to the mega88pa is the mega328pb

which does have two USART peripherals.  Also two

SPI and two TWI, plus five timers (2x 8-bit and 3x

16-bit).

 

--Mike

 

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

If you already have a board made and you are stuck with the M88 then possibly a software Usart?

Jim

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

 

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

 

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

 

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

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

 

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

Please Read: Code-of-Conduct

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

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

avr-mike wrote:
None of the mega 48/88/168 have two USARTs
The one thing that was confusing when the 48..168 (328 was later) first came out was that the datasheet talked about UDRn which seemed to suggest that while the preceding chips like mega16/mega32 and so on had only had "UDR" that maybe this implied that "n" was a placeholder for 0, 1 or even more. So you would have UDR0, UDR1 and the generic term to cover all of them was UDRn. It looked like it might have more than one UART.

 

But it seems that Atmel were just "future proofing". There were to be some chips later with more than one UART so they have UDR0, UDR1 but in 48..168(/328) there is only one value for "n" and it is 0.

 

Presumably the intention was to make code more "portable". So if you wrote:

void uart_pucthar(char c) {
    while(!(UCSR0A & (1 << UDRE0)));
    UDR0 = c;
}

then this would work on 48..168 with its single UART but later you could take this to a mega644P or whatever and build the identical code and on that chip (which has 2 UARTs) it would still work (for UART 0).

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

As I remember the mega162 was the first with two USART, and after the datasheet was made , I guess it has been kind of random which datasheet is the master for cut and paste for newer chips.

 

As I remember the GCC include files have ( or had) both UDR and UDR0 defined as the same for chips with one USART! (where UDR isen't defined in bigger chips to avoid confusion )

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

Right Jim,

 

when in trouble go back to main requirements; and yes: I dont think I really need 2USART (crossout USB), what Im after is a write-out of problems during develop for the second USB,

but for the M590 com I do need it. Also, I found no 2USART(edited USB) with a DIL/DIP formfactor, and I dont intend to do a PCB, so surface mount just adds to trouble for breadboard in dev.

So, my next think (tonight :) is to put two M8 back to back and have a trivial serial (SPI) between them...... 

And yes, my initial "hunt for 2 UART" was triggered by the n in chap 17.... even though the header of chap has n=0 (which has been a kind of warning/confusion :)

 

(in this lone case one could actually say that RTFM was not the right approach :)

Last Edited: Wed. Mar 6, 2019 - 11:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gechxx wrote:
So, my next think (tonight :) is to put two M8 back to back and have a trivial serial (SPI) between them...... 
Why wouldn't you just use something like a mega324?

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

Well possibly I missed formfactor ? is it pin-mount ? (second con would be to have to wait )  

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

Yeah, 324P is available as a 40 pin DIP.

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

gechxx wrote:

...I dont think I really need 2USB, what Im after is a write-out of problems during develop for the second USB...

 

USB? When did that enter your list of requirements?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

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

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

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

ah, so thats your thinking ! you were right all along, now its only impation thats left, I do & will get one ! 

meanwhile I will most probably loose time by some workaround (possibly if design turns out for reproduction, I might use it on PCB, my hands dont allow for surface mount)

thanks/ge

Last Edited: Wed. Mar 6, 2019 - 11:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nooo; my brain thinks it starts with Uxxx what follows is not so important ;)   (basically flawed i.e. )

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

If it's just for tests/dev get a 1284 in dip, it's always nice with ekstra buffers for dev. etc. (a 1284 has 16KB of RAM)

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

Good thought, however sometimes its good to have it nice an claustrophobic, so you dont exceed your limits and have to tighten later.... (which usually is a nuisance) Ill consider though.

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

Why don't you save yourself - and us - some grief and write out everything your device and the microcontroller needs to operate according to the specifications? For example what this gizmo does, the peripheral devices involved, etc. then post here.

Jim

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

 

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

 

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

 

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

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

 

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

Please Read: Code-of-Conduct

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

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

gechxx wrote:
Also, I found no 2USART(edited USB) with a DIL/DIP formfactor, and I dont intend to do a PCB, so surface mount just adds to trouble for breadboard in dev.
4 USART in mega3209 and mega4809 though no DIP; DIL PCBA : https://www.avrfreaks.net/forum/megaavr-0-series?page=3#comment-2648801

mega328PB is similar (2 USART, no DIP)

mega328PB in PCBA from several; one : Pololu - A-Star 328PB Micro - 5V, 20MHz

 

 

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

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

gechxx wrote:
my project stuck (communicating sms with M590) since I realized I needed to talk USART (conviniently) with both PC and M590, ...
To PC by USB?

If yes then mega32U4 (1 USB device controller, 1 USART)

PJRC - Teensy 2.0 Pins

C code for Teensy: USB Serial

C code for Teensy: UART (serial)

 

There are several mega32U4 breakout PCBA.

Some mega32U4 in Pololu A-Star series; one : Pololu - A-Star 32U4 Micro

 

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

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

clawson wrote:

There were to be some chips later with more than one UART so they have UDR0, UDR1 but in 48..168(/328) there is only one value for "n" and it is 0.

 

Presumably the intention was to make code more "portable".

 

This seems likely (attempt at code portability).  They

botched it a bit with the ATmega32U4 though which

only has one and it is called USART1.

 

--Mike

 

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

Hi again,

many good suggestions and thanks jim for offer, but most of the project is actually mentioned (reference to main req. were more a reflection of past work with "more serious products")

Just now Im designing as I go; the whole idea is to get a (cheap) remote measurement/sensor&control/actuator device based on a small Atmega. One application is the trivial, supervise temperature in a house, and turn-on/off heating stuff (some levels), also reporting other "environmen status" like outdoor temp, if sun is out. Bits and pieces tested and working.

Then complemented by a number of other possible tasks.

 

So for now many thanks for all support. ( I now need to choose from 2 UART 324p or a ,of cause convinient, 1Uart / 1 USB, tilting towrds the former but currently I dont see these go in the "ready thing". (but then I have to go into how to handle the USB also, learn new:)  )They will probably be handy.

/ge

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

gechxx wrote:
Just now Im designing as I go;
That doesn't sound like a great plan. Suppose you pick a chip then get 80% through your development and then realise it does not have some vital peripheral you just thought of or there isn't enough flash or RAM or EEPROM or whatever.

 

The idea is that you make all the design decisions up front so you know exactly which chip will satisfy the design requirements then there's no nasty surprises later.

 

Half the posts we see on this forum seem to be from people trying to solve something that's occurred because they didn't put enough up front thought into whatever it was they are designing.

 

As suggested above, if 164/324/644/1284 look like the right series to use then I'd start with a 1284 for prototyping - you can wind back to cheaper/smaller versions later if you realise you don't need all the resources it offers.

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

jgmdesign wrote:
Another option for a 2 usart solution is the mega324.
... and 3 for mega324PB.

By a quick search, could locate only one third party mega324PB board :

AS-mega324 Board | AS-kit hardware

its USB UART is CP2104 leaving two spare UART.

 

mega324PB can be in Arduino :

Supported microcontrollers - GitHub - MCUdude/MightyCore: Arduino hardware package for ATmega1284, ATmega644, ATmega324, ATmega324PB, ATmega164, ATmega32, ATmega16 and ATmega8535

...

* ATmega324PB has 3 serial ports, 9 PWM pins and 39 IO pins if internal oscillator is used.

 

though the PCBA for that is for DIP :

https://github.com/MCUdude/MightyCore#hardware

 

The follow-on to mega324PB is mega3209 or mega4809.

 


ATmega324PB - 8-bit PIC Microcontrollers

AVR42769: Differences Between ATmega324 and ATmega324PB

CP2104 Classic USB to UART Bridge - Silicon Labs

 

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

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

Half the posts we see on this forum seem to be from people trying to solve something that's occurred because they didn't put enough up front 

Well that I can see, and very much agree on that its good to think ahead. On the other hand many projects (successful) would never have been done if one had forseen all the trouble and mess ahead, many good ideas turn up along the way. Guess balance is best. Anyways would it be a terrible idea to for the time being put two M8 back to back with a TWI inbetween, Just now Im aiming to get just a write to console, output texts through that path. Starting to read manual, SPI seems clearly better choice, though there will be some handson for ISP. Will be back when utterly stuck :) tnx all.

Last Edited: Wed. Mar 6, 2019 - 10:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I love multi-processor projects, but in my opinion you really need a really good reason to go that route.

Lack of enough USARTs would not qualify as an adequate reason in my mind.

There are plenty of multi-USART micros, some with up to 8 USARTs, so personally I'd order one of the big chips recommended above and then move forward  with your project.

 

For reliable intra-micro comm's  one often used ring buffered, interrupt driven, communications.

In your case, with the secondary micro having only one job, read the incoming data and send it out the USART, that might not be required.

 

But, you asked for an opinion, so mine is you are complicating the project by doubling the number of micros.

 

JC

 

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

you are complicating the project by doubling the number of micros.

Right on! yes, but I have a double(well multiple) problem; lack of good planing, and lots of impations, and possibly lack of judgement  and a very dim concept of how long time simple things take. There will be time to regrett.... (and its only intended for the test phase)

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

Be careful with thinking something is only for test

purposes, a prototype, etc. If the boss sees some-

thing working he's going to want to ship it!

 

--Mike

 

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

:)

 

By myself I wouldnt have no boss, Id be ..... 

You are completely right, Ive been there, actually that was a reson I decided to quit a company once;against my loud whining the stuff was sold, and I left, they had a hell..... ;) /g

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the boss sees some-thing working he's going to want to ship it!

I've never known them to wait that long!  crying

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

The "go-to" 2-UART DIP AVR is probably the ATmega1284  (40 pins.)
there are several Arduino-compatible boards using it...

 

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

Ok, having taken yr time, I post this, just in case anyone, well dont suppose you will use it but anyhow:

It works, but fine-tuning missing, a strange thing is that my live-led on the sending side has

seriously less lumination when blinking with this code..... (and there is a rubbish char after :::)

(as usual it was a quite quick slow fix, slow for all fumblings, chineese breadbords etc :)

 

// schematics is simple: connect MOSI-2-MOSI, MISO-2-MISO, SS-2-SS, SCK-2-SCK //

// ( beauty of this follows that you need only move the reset to chose whom you want to load //

 

first is a kind of lib file, linked with both mains, following:

    #include <avr/io.h>

    #define MOSI_PIN PB3    // there are probably generic symbols for this....
    #define MISO_PIN PB4    // well this will do for m8 and the m48 series
    #define  SCK_PIN PB5
    #define   SS_PIN PB2

    // code for doing relay function of outward messages from master config chip (m8)
    // to output relying config slave chip 
    // the latter will have sole purpose of relaying incoming to slave, to Uart, so 
    // it will be hanging on the live wait (for now)

    //------------------master side code--------------------------

    void SPI_MasterInit(void) {
        /* Set MOSI and SCK output */
        /* for my purpose, only one master, so SS can be output, all others input */
        DDRB = (1<<MOSI_PIN)|(1<<SCK_PIN)|(1<<SS_PIN);

        /* Enable SPI function, as Master, set clock rate fck/64,  */
        /*  no need for high speed with 8Mhz this is then 125k */
        SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1);

    }
    void SPI_MasterTransmit(char cData) {
       /* Start transmission */
        SPDR = cData;
        /* Wait for transmission complete */
        while(!(SPSR & (1<<SPIF)));
    }

    void SPI_MstrTransm(char * str) {
       // routin to transmitt a (text) string,terminated by CR 
       // over the SPI interface

       char * sendchar;

        sendchar = str;

        while ( *sendchar-1 != 0 || sendchar == str) {
            /* Start transmission, by entering data in data reg */
            /* we want to send the terminating null also */
            SPDR = *sendchar;
            /* Wait for transmission complete, live wait */
            while(!(SPSR & (1<<SPIF)));
           sendchar++;                 // move one char fwd in string
        }
    }

    //-----------------------slave side  code----------------------

    void SPI_SlaveInit(void) {
        /* Set MISO output (as addon to other possible already set, all others SPI should be input */
        DDRB |= (1<<MISO_PIN);
        /* Enable SPI */
        SPCR = (1<<SPE);
    }

    void SPI_Slv_String_recv(char * outstr, int max) {
        // this routine does live wait for input on the SPI,
        // programs only purpose is to relay input received here on SPI
        // reception is done for a number of characters (max is set by provided inbuf)
        // terminated by a null

        char * outpt;
        char * outend;
        char inchar;

        outpt = outstr;        // set pointer to where output goes
        outend = outstr+max;   // we dont want to write around mem if something goes wrong

        inchar = 1;            // get started
        while ( outpt < outend && inchar !=0 ) {      // CR terminates reading and returns string.
          /* Wait for reception complete */
          while(!(SPSR & (1<<SPIF)));      // live wait for interrupt flag
                                           // but how is SPIF reset ! just by reading SPDR ?
                                           // datasheet p127; bit7/SPIF: Alternatively,
                                           // the SPIF bit is cleared by:
                                           // first reading  the SPI Status Register (SPSR) (with SPIF set),
                                           // then accessing the SPI Data Register (SPDR).
          inchar = SPDR;
          *outpt = inchar;
          outpt++;
       }
       *outpt = 0;   // add a "new" trailing null
    }
    //both must also set sei(); in main

    //----------------------------------------
    //  main test program testing SPI relay to UART
    //  program just repateadly sends text to the SPI interface 

    #define F_CPU 8000000UL
    #include <avr/io.h> 
    #include <avr/delay.h>
    #include <avr/interrupt.h>  // only if sei() needed

    #define LED PB0
    #define LED_DDR  DDRB
    #define LED_PORT PORTB

    /* Declarations for connecting UART library read routines */

    /*
    extern   USART_RXC;  // make ISR routine visible and included (two variants of lib, both with same shared params
    uint8_t  UART_IN;    // global variable for value recieved by uart
    uint8_t  RX_rcv;     // global variable (used as boolean) 0= no new recieved, 1=uart variable above contains new
    */

    int main() {
       //********************************************************************
       // program generting text strings to SPI
       //  a toggle at
       // each transfered buffer (LED on PB0)
       
       char CR = 13;
     
       LED_DDR = (1<<LED);    // init out for LED

    /*
       //--- initiate UART, 4800 baud

       USART_Init(baud);
       USART_Init_rcv();
    */
       sei();

     
       //    initialize SPI  ( how it takes over from ISP funktion.. ?)

       SPI_MasterInit();   // sei är satt via UART init -- NEJ INTE !!!!

       // transmitt on SPI

       while(1) {

           SPI_MstrTransm("** transmitted from M8 master **");
           //USART_Trsm_string(":::");
           //USART_Trsm_string(buffer);

           LED_PORT ^= (1<<LED);   // toggle only LED pin 

           _delay_ms (2000);
       }  

}  // ** end MAIN **

       

    //----------------------------------------
    //*  main program for RELAY of SPI to UART

    #define F_CPU 8000000UL
    #include <avr/io.h> 
    #include <avr/delay.h>
    #include <avr/interrupt.h>  // only if sei() needed

    #define LED PB0
    #define LED_DDR  DDRB
    #define LED_PORT PORTB

    /* Declarations for connecting UART library read routines */

    extern   USART_RXC;  // make ISR routine visible and included (two variants of lib, both with same shared params
    uint8_t  UART_IN;    // global variable for value recieved by uart
    uint8_t  RX_rcv;     // global variable (used as boolean) 0= no new recieved, 1=uart variable above contains new

    int main() {
       //********************************************************************
       // program with sole task to run on M8 to relay incoming SPI data to
       // UART output port, so there is no live blink, only a toggle at
       // each transfered buffer (LED on PB0)
       
       char buffer[80];
       char CR = 13;
       uint16_t baud=103;   // should be 4800 in 8Mhz (M8)

       LED_DDR = (1<<LED);    // init out for LED

       //--- initiate UART, 4800 baud

       USART_Init(baud);
       USART_Init_rcv();

       sei();

       // starts with blinking phase, until Recive order on UART to start relay

       while(1) {
           LED_PORT ^= (1<<LED);   // toggle only LED pin 
           _delay_ms(1000);

           if (RX_rcv && RX() == 'R') break;   // skip out when R (as in relay) received
           USART_Trsm_string("** relay program, type R **"); USART_Transmit(CR);
       }
           
       //--- Order to start relay receivd
       //    initialize SPI  ( how it takes over from ISP funktion.. ?)

       SPI_SlaveInit();   // sei är satt via UART init -- NEJ INTE !!!!

       // loop on;  read wait on SPI, when receive, transmitt on UART

       while(1) {

           SPI_Slv_String_recv(buffer, 80);   // here we hang waiting for input
           USART_Trsm_string(":::");
           USART_Trsm_string(buffer);

           LED_PORT ^= (1<<LED);   // toggle only LED pin 
       }  

}  // ** end MAIN **

 

Last Edited: Thu. Mar 7, 2019 - 11:07 PM