How to simulate the serial port in Atmel Studio?

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

Hi there,

 

I have a simple program written for the Atmega microcontroller.

 

The program reads something from the Serial port, and then it does something with the data.

 

I want to debug the program with Atmel Studio 7, but I do not know how can I send something to Serial port.

 

The program stops and is waiting to read from Serial, but I do not know how to send data to Serial.

 

I started the terminal from Tools | Data visualizer, pressed Connect (I do not have option to choose the port), and I get the terminal, but if I type some text there it will not get to my program.

 

So, how can I simulate some data coming from the Serial port in Atmel Studio?

 

thank you,

Mihai

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

I think the terminal just connects to a (virtual) COM port on the PC - so it would need external hardware to send to, and receive from.

 

The easiest way to do this is to forget about simulation, and get a proper target & debugger.

 

If you don't already have a debugger, the obvious choice would be to get an Xplained Mini or Nano - which gives you a real target complete with debugger:

 

https://www.avrfreaks.net/comment/2397171#comment-2397171

 

 

EDIT

 

added "virtual"

 

EDIT 2

 

For example, ATmega328 Xplained Mini:

 

https://www.avrfreaks.net/forum/xplained-mini-mega328pb?skey=xplained

 

https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/ATMEGA328P-XMINI

 

Under $10 from Microchip direct:

 

https://www.microchipdirect.com/product/ATMEGA328P-XMINI?productLoaded=true

 

or Digikey, et al:

 

https://www.digikey.com/products/en?mpart=ATMEGA328PB-XMINI&v=150

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jun 18, 2020 - 12:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you could pause the simulation and by hand put teh expected value in the RXD register and then continue the simulation.

When doing so, also look at the Receive complete flag. Not sure is AS sets it automatically when you put data in the register or if you also have to set that yourself.

It has been more than many moons since I used the simulator.

 

You do understand that your normal program is going to behave just like that right?????

better check if data is received poling wise, such that you can do other things while waiting for data to come in....

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

For peripheral simulation, Proteus is best, as an alternative, write some dummy getchr() function that returns the expected characters and use that to debug with, it's tedious but will get the job done.

Otherwise, as suggested, use real H/W.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

awneil wrote:
The easiest way to do this is to forget about simulation, and get a proper target & debugger.
+1

 

But there are a few options.

 

1) Assuming you have some kind of core UART_getchar() then what you can do is something like:

uint8_t UART_getchar() {
#ifdef SIMULATION
    uint8_t dummy_data[] = { ' H', 'e', 'l', 'l', 'o' };
    static int index = 0;
    uint8_t retval;

    retval = dummy_data[ index ];
    index++;
    if (index > sizeof(dummy_data)) {
        index = 0;
    }
    return retval;
#else
    while (!(UCSRA & (1 << RXC)));
    return UDR;
#endif
}

when you plan to simulate define "SIMULATION" and the "mock" version will be built, when it's not defined the real UDR version will be built. Now in simulation you have a source of "fake input" each time you call UART_getchar().

 

2) pay €300 or whatever it is an get Proteus VSm from Labcenter

 

3) if you don't mind a "trip back in time" revert to AS4 and its simulator then also google (may require "internet archive") a thing called "Hapsim". That was an add on that "hacked into" the simulator in AS4 that provided things like terminal simluation

 

The thing is though that the reason you need to debug UARTs is almost always to do with clock speed and neither (1) nor (3) will help you find an issue in that area. I think (2) will tell you if it thinks you have got the speed thing wrong but I'd kind of hope for that accuracy when paying €300 !

 

Given that you can get a real Xplained Pro board with a real AVR and a real debugger for a bit over $10 then I don't really see the point. You might as well get some debuggable hardware and try this for "real"!

 

EDIT: (4) I completely forgot VMLab ! It was a commercial simulator, then they stopped development and made it a free download, then the website eventually disappeared but you can still access it in the internet archive:  https://web.archive.org/web/20170713131347/http://www.amctools.com/vmlab.htm

 

EDIT2: wow, that took a bit of work but I found Hapsim in the archive too:  https://web.archive.org/web/20190705105037/http://www.helmix.at/hapsim/

Last Edited: Thu. Jun 18, 2020 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

clawson wrote:
1) Assuming you have some kind of core UART_getchar() then what you can do is something like ... when you plan to simulate define "SIMULATION" and the "mock" version will be built

although, once you've done that, you've removed all the dependence on the AVR hardware - so why not just build & test the hardware-independent code on a PC ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:
put teh expected value in the RXD register

can you do that?

 

does the simulator allow you to write to RXD ?

 

(I don't know - I always take the HW approach for this kind of thing)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

meslomp wrote:
put teh expected value in the RXD register

can you do that?

 

does the simulator allow you to write to RXD ?

 

(I don't know - I always take the HW approach for this kind of thing)

I also always use the HW approach, but if I recall correctly you can alter the IO line registers, so why not also the RXD register.

Only concern here is that you also need the reception complete flag, not sure if that is automatically set, or you also have to set that by hand.

Note I played with the simulator only when I was new to AVR programming  so that was probably 2007/2008 and then with studio4 since then I have hardware in plenty variants to have a go when I ant to. Just take a board from teh shelf and get going. But the OP should be able to test the posibility very easily and quickly.

 

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

Not in the case of UDR. Remember that it is two co-located registers at the same address, one Tx, one Rx. I'm pretty sure the simulation treats it as this too.

 

Of course one option I forgot above is:

 

5) "stimuli files". That will allow the simulation to make it look like data is emanating from UDR

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

meslomp wrote:
so why not also the RXD register.

Other simulator/debuggers I have used have used the same model as the code: so they only have access to the "data" register - and a write access the TX; a read accesses the RX.

 

EDIT

 

Ah - clawson just said it.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jun 18, 2020 - 01:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

BTW what I meant to say was actually:

clawson wrote:
two co-located registers at the same address, one Tx (so write only), one Rx (so read only).

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

From the old 8051 days I got used to make a rs232 back door for debugging, and if the product use the HW USART for some other things it would be a SW version (speed don't really matter), but that was before the chips had build in "ICE"

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

Ignoring the above confusion about RXD register. I've deleted my stuff on this - others have said it.

 

Atmel stimuli files are just about the only way to get stuff repeatedly into the simulator.

Here's an example .stim file to inject the character 'J' into the RX pin which on many lower pin-count AVRs is PORTD.0: (The # lines are actually cycle delays)

//
// F_CPU = 8000000 Baud = 115200 BitDelay = 69.4444 cy
//
// Send 'J' 0x50 0b01010000
PIND &= 0b11111110 // Start Bit
#69
PIND &= 0b11111110
#278               // 4 Bit Delays
PIND |= 0b00000001
#69
PIND &= 0b11111110
#69
PIND |= 0b00000001
#70
PIND &= 0b11111110
#69
PIND |= 0b00000001 // Stop Bit
#69