Simulating CodeVisionAVR code with GLCD in Atmel Studio 7?

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

Hi all,

 

Please find attached a zip file, with a simple CVAVR project that uses a clock interrupt at 40 ms to increase/decrease a variable, and a main function that uses that variable to draw a line on ILI9341 GLCD display.

 

Code works fine on ATxmega128A1U, everything is as expected. Also, setting breakpoints in this code in Atmel Studio 7 is also fine - the breakpoints stop the program, both in the main function, and in the interrupt.

 

That which puzzles me, is that I cannot simulate this code in Atmel Studio 7.

 

Rather, the simulator starts up, cycles and PC change as expected - however, the same breakpoints (lines 176 and 199 in `test_xmega_ILI9341_glcd_bp_main.c`), that hit properly in the live debug session with Atmel-ICE, never hit here in the simulator ?!

 

I've inspected a bit, and all that I can notice is, that when this code runs in the simulator, it gets stuck in an endless loop in assembly here:

00000AD8  SBIW R24,0x01		Subtract immediate from word
00000AD9  BRNE PC-0x01		Branch if not equal

R24 simply counts down from 255 to 0, and then it wraps, and then it counts down again - and this loop is never exited.

 

My guess is that the GLCD library functions apparently wait for some hardware response from the GLCD, - but as this is in the simulator, there is no model for the GLCD, and such a response/signal never arrives?

 

Now, I've met this before, and usually the way I handle it, is comment all glcd functions - which is a bit tedious, for one; but more importantly, commenting also changes the timing of the running code.

So, my question is - is there any way that I can "persuade" the Atmel Studio simulator to keep going with the GLCD functions (such that any given breakpoints in the code execute), mostly for the purpose of getting a bit more accurate timing in the simulator - provided that the GLCD libraries that come with CodeVisionAVR are commercial and closed (and thus, there is no source for them)?

 

Thanks in advance for any responses!

 

Attachment(s): 

This topic has a solution.
Last Edited: Tue. Mar 17, 2020 - 09:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sdbbs wrote:
That which puzzles me, is that I cannot simulate this code in Atmel Studio 7.

Why is that a puzzle?

 

CodeVision is an entirely independent, proprietary 3rd-party product - it's a completely different compiler & IDE.

 

 

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


Dunno about anyone else but when I try to load that in AS7 it just says:

 

 

Not sure what "null" value it is moaning about though?? It mentions "url" but nothing tagged "url" appears in the .cproj (or maybe that is the error??)

 

(I checked a working AS7 project and its .cproj does not mention "url" either - wish, when they threw the error, they would have given line number as well as filename!)

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

1.  declare your volatile variables as volatile.     CV may not be as ruthless as GCC but it is foolish to ignore C semantics

 

2.  what is your main intention?    CV libraries are fairly comprehensive.   They do not profess to be infinitely fast.

 

3.  I don't possess any 16-bit ILI9341 displays.   There are too many wires to solder.

 

4.  But I could run a regular 8-bit parallel ILI9341 on a 128A1 if necessary.

 

5.  your AS7.0 project builds.   It would be tedious to Simulate.  (unless you have a good reason)

 

David.

 

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

Hi all,

 

Thanks for all the responses!

 

Apologies for the false alarm - it turns out, Atmel Studio 7 *can* simulate GLCD CVAVR code just fine! Except, at times, it can get *extremely* slow - for instance, `glcd_clear()` needed some 20+ minutes to complete simulating on my desktop machine, that runs Atmel Studio 7!

 

The only reason I figured this out, was that the code setup implies that more-less all of the I/O lines on the ATxmega, involved in communicating with the ILI9341 GLCD are defined as outputs; therefore there cannot be any reasonable waiting for a specific input condition. So I set off the simulator, went to lunch, came back, did something else for like 5 minutes - and was surprised (pleasantly) to see Atmel Studio debugger/simulator suddenly break at the next breakpoint!

 

Also, the other glcd_* commands take somewhat less time: `glcd_init()` takes 4 mins 21 seconds to simulate on my desktop machine; while `glcd_setcolor()` and `glcd_line()` take significantly less - up to 10 seconds max, so I didn't even bother measuring the simulation time for them. I did however measure the time between two breaks at line 197 in *_main.c, which is in the `tcc0_overflow_isr()` interrupt; that takes 1 minute and 21 seconds on my machine; and since that interrupt is supposed to run each 40 ms, that means a factor of 81/40e-3 ~= 2025 between the PC simulation real time, and ATxmega processor (simulated) time ...

 

So, it's nice to have this finally confirmed - and out of the way! :)

 

awneil wrote:

Why is that a puzzle?

 

CodeVision is an entirely independent, proprietary 3rd-party product - it's a completely different compiler & IDE.

 

Well, that is true - and that is what I also thought at first, when I first had to start working with CVAVR about a year or so ago.

 

However, given that I tried debugging "live" CVAVR code on chip via Atmel-ICE in Atmel Studio, and saw that breakpoints typically stop (and ultimately, CVAVR has to compile to the same assembly commands/instruction set, as any other compiler for ATxmega, like gcc, would have to) - I did dare simulating CVAVR code in Atmel Studio 7 regardless, just to see what happens; and so far, never had problems with simulation of in-memory processing (usual assignments, branching etc); and I could even get stimuli file to simulate UART, - and the CVAVR code behaved as expected.

 

However, `glcd_*` stuff was specifically a puzzle, since it seemed to me at first that whenever one of those commands is encountered, the simulator just sort of "stops responding" - and I always thought there was something more complicated to it; rather than just a humongous wait time.

 

 

clawson wrote:
Not sure what "null" value it is moaning about though?? It mentions "url" but nothing tagged "url" appears in the .cproj (or maybe that is the error??)

 

Hmm... not sure about that one myself, as well. Occasionally I also get weird messages from Atmel Studio 7 at startup randomly (not that one with the "url", though), but since I mostly get everything done regardless of if they show or don't, I've sort of learned to ignore them ...

 

 

david.prentice wrote:

1.  declare your volatile variables as volatile.     CV may not be as ruthless as GCC but it is foolish to ignore C semantics

 

Ups, yes - thanks for that! Actually they were volatile before I packaged the entire code for attaching, and now that you mention it, I cannot remember why I deleted the `volatile` keyword before uploading ... Maybe I got tired, and thought the keyword shouldn't be there :/

 

 

david.prentice wrote:

2.  what is your main intention?    CV libraries are fairly comprehensive.   They do not profess to be infinitely fast.

 

I did not expect them to be infinitely fast either. I just need to simulate a piece of code (not the example I attached), where I need to take into account the delays they might introduce. And as I mentioned: previously I thought `glcd_*` broke the simulator, so I used to get around this by commenting `glcd_*` functions, but that gives a false impression in the simulator of how the code would behave on chip, where those functions are actually running.

 

So, all I wanted was to keep the `glcd_*` functions in the code during simulation, so the simulation approximates the real-world situation better (especially when I print out `{CYCLE_COUNTER}`, which is only available in the simulator); and now that I know that the `glcd_*` functions do not, in fact, break the simulator, but just take a lot of time - now I can prepare accordingly ...

 

 

david.prentice wrote:

3.  I don't possess any 16-bit ILI9341 displays.   There are too many wires to solder.

4.  But I could run a regular 8-bit parallel ILI9341 on a 128A1 if necessary.

 

Ah, sorry if I was unclear - I don't think there is a need for that . The code works on live processor just fine/as expected, no problems there. What I was specifically wondering about, is the behavior in the simulator ... which is why I tried to come up with a simple enough example, that works fine "live", so that one could focus on the behavior in the simulator ...

 

 

david.prentice wrote:

5.  your AS7.0 project builds.   It would be tedious to Simulate.  (unless you have a good reason)

 

Apologies, but I cannot really parse this sentence. Do you mean I should have included some AS7 build files in the attached .zip, because otherwise it would be tedious to simulate? Or did you mean that, even if I've included AS7 build files in the .zip, it would be still tedious to simulate, so I should drop the whole idea about simulating?

 

 

Thanks again, all!

 

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

sdbbs wrote:
it can get *extremely* slow - for instance, `glcd_clear()` needed some 20+ minutes to complete simulating on my desktop machine, that runs Atmel Studio 7!
I think it's been determined in the past that Studio simulator acts something like a 50kHz AVR so, for example, if you have timers or soft delays calculated on a typical 8/16MHz AVR speed then in simulation they may take 160..320 times longer than normal. If you do have things like _delay_ms(50) (for 16MHz) say then that is going to become 16 seconds in simulation etc etc.

 

So rebuild code to remove all such delays and timer waits etc if building to simulate.

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

sdbbs wrote:
it can get *extremely* slow

Yes, it can - it simulates at a lot less than the real life speed of the AVR!

 

This is especially noticeable if you have busy loop delays - eg, using the delay_us(), etc.

 

david.prentice wrote:

  It would be tedious to Simulate. 

 

Apologies, but I cannot really parse this sentence

I guess he's referring to the above?

 

plus the fact that you would have to manually simulate all external stimuli.

 

Nowadays, with on-chip debug, it's usually easier to just use the real hardware.

 

If your issue is now resolved, see Tip #5 in my signature

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

clawson wrote:
I think it's been determined in the past that Studio simulator acts something like a 50kHz AVR

Which always strikes me as odd, because the Keil 8051 simulator has exactly the opposite "problem" - it runs everything way faster than real life!

 

Surely, an AVR can't be that much harder to simulate than an 8051 ... ?

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:
Surely, an AVR can't be that much harder to simulate than an 8051 ... ?
While it's true that back in the mists of AS4 and Win95 and stuff that perhaps it was a resource issue in a PC the fact is that over the years it has not improved even thought PC performance has probably imrpoved 10 fold or 100 fold or whatever. So I think it's safe to assume it's not about the ability of the PC to run opcode simulations "fast" but that it looks like the whole "state machine" is probably "ticked" by some fixed rate timer. In fact if it is a fairly fixed 50kHz it maybe suggests someone asked Windows for a 20us "tick" perhaps? 

 

All conjecture of course but it does seem likely.

In this modern age I guess they could ask for a timer with a much finer granularity. (or use a software spin loop in which case it'd just get faster and faster with PC performance which is presumably what Keil are doing for 8051).

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

 

sdbbs wrote:

I've inspected a bit, and all that I can notice is, that when this code runs in the simulator, it gets stuck in an endless loop in assembly here:

Well, not having Codevision, I loaded your COF file into Studio and ran that. Lo and behold my laptop fans went into hurricane mode. On breaking the debugger I was indeed at the program location you indicated. However contrary to what it may seem; that is NOT an endless loop. Simply change R24/R25 & R26/R27 to a low value (I entered 2 & 1) and step out.

You will find your code was actually executing this massive delay (massive in relative terms).

 

 

david.prentice wrote:
It would be tedious to Simulate.

And then some. The lack of LCD source is a real pain.

 

 

Last Edited: Mon. Mar 16, 2020 - 09:18 PM