Please Help, Some lines of code are not compiled...!!!!!!!

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

Dear All;
I new at winavr, i'm using AVR studio 4.14, the chip is ATmega8, The problem is some lines of C code are not compiled!!!!
I can not make point at these lines because they are not compiled.
Please not tha picture.
the functions are not called
thank you

Attachment(s): 

Last Edited: Wed. Feb 10, 2010 - 01:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are the symptoms and what are the expectations?

JW

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

The symptoms:
* the functions are not called;
* Also, there are simple lines like y = 0, or z++ are not compiled too
expectations:
Really I don't know.

Attachment(s): 

Last Edited: Tue. Feb 9, 2010 - 01:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do not say which lines are not compiled. My crystal ball says the 'delay(0x5FFF)' does nothing.

The compiler has decided that the code does not do anything useful. So it removed it as an 'optimisation'.

If you want a delay, use and _delay_ms(milliseconds). e.g _delay_ms(10000) for 10 seconds. This will behave as you expect.

I also note that you say:

TCCR0 = (2 << CS00);    // = (2 << 0) = 2

If you want the div256 prescaler

TCCR0 = (1 << CS02);    // = (1 << 2) = 4

David.

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

I assume, your delay-function is omitted by the optimizer because ist does nothing. Watch the manual of avr-libc and use the functions described in .

/Martin.

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

david.prentice wrote:
You do not say which lines are not compiled. My crystal ball says the 'delay(0x5FFF)' does nothing.

The compiler has decided that the code does not do anything useful. So it removed it as an 'optimisation'.

If you want a delay, use and _delay_ms(milliseconds). e.g _delay_ms(10000) for 10 seconds. This will behave as you expect.

I also note that you say:

TCCR0 = (2 << CS00);    // = (2 << 0) = 2

If you want the div256 prescaler

TCCR0 = (1 << CS02);    // = (1 << 2) = 4

David.

Dear David
Many thanks for ur interest. I just forgot to change the comment
The delay function as attached, Note that the while loop in this function is not compiled too !!!!!

Attachment(s): 

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

You have called the function with 'Delay(0x0FFF)'
The compiler sees that all your function does is to make D = 0x0FFF
Then you never do anything with 'D'.
So it says 'why bother?'

The better solution is to use
A bad kludge is to say:

volatile unsigned long D = 0;

Have you tried simulating your code? You can see exactly what happens. And how long it takes in microseconds.

You can still get confused by the avr-gcc optimiser. You 'watch' a variable and nothing seems to happen. Only to discover that avr-gcc has copied the variable to a register and Studio does not display it.

David.

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

david.prentice wrote:
A bad kludge is to say:

volatile unsigned long D = 0;

no better kludge, but easier to debug: turn optimization off.

/Martin.

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

mtaschl wrote:
david.prentice wrote:
A bad kludge is to say:

volatile unsigned long D = 0;

no better kludge, but easier to debug: turn optimization off.
I must disagree. In this case, turning off optimization is an even worse kludge.

The "disappearing delay loop" is an extremely common newbie problem, perhaps exceeded only by problems with UARTs. It is a problem that must be understood by the newbie before he/she can continue. The compiler's optimizer can and will remove code that it deems "useless" from a functional point of view. Remember that it is only concerned with results that can be reported via a pin or will potentially cause a change in program flow.

A delay loop does neither of these things.

The compiler does not understand that "time" is a function. In fact, it has been specifically told to reduce time where ever possible. Thus, removing a delay loop looks like a huge win to the optimizer.

So the above Delay loop looks to the compiler like a complete waste of time. It will remove it, as it should.

If the newbie gets the idea that he/she must compile with no optimization, all sorts of other gremlins creep into view. Far better to compile with full optimization and to use the _delay_* functions when a specific delay is needed. That's why they are in the library. In fact, the advanced newbie might get inspired to look at the hardware timers! :D Gosh, the processor can do more than one thing at a time!

Don't get me wrong -- I certainly will advocate using the -O0 option under some circumstances (and have come back bloody from saying so), but this is not one of those cases.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:

In this case, turning off optimization is an even worse kludge.

Can I quote you on that? ;-)

(looks like I just did)

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

dear all.many thanks to all of u, now i understood the proplem of delay loops. But what about the line in which the variable is incremented?? And there is another line in which i clear the variable z, it is not compiled too...!!!!

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

Quote:

And there is another line in which i clear the variable z, it is not compiled too...!!!!

You are wrong, they HAVE been compiled, it's just the compiler decided they didn't do anything useful or that it could combine the functions of several statements into one smaller block of code or that it needn't create variables in RAM (on the stack) because it could use a machine register. So the debugger is left with nothing to look at. This is the nature of optimization. I always think the best way to learn about it is to debug with a mixed C/asm view then you'll see which lines have generated what code. For the same reason you'll find lines in the source that you cannot put a breakpoint on.

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

Dear all
Many thanks to all of u,
I've changed the code to avoid using delay loops
look at the Pictures,The Delay() function uses the _delay_ms() function, and because i can not use the _delay_ms() for more than 262.14 ms / F_CPU in MHz i.e. 262.14/7.372800 = 35.55 ms, I used a loop to call the _delay_ms () many times to make the needed delay,
BUT, it is not compiled.
The function Delay() is called from the function CLS(); and this line is not compiled too...!!!!!!!
Also the forever loop calls the Delay() and it's not compiled too......!!!!!!!!

I can attach the main.c for your reference

Thanks a lot and Best Regards

Attachment(s): 

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

Who says that the lines are not compiled? I would guess that when you run the code, the delays happen. The hex-address of the program source lines definitely hint that there is something between disply_Arabic() and disply_English().

The current avr-gcc and associated libc.a handle longer _delay_ms()'s. But you have made an excellent choice of Delay() function. You can pass a variable # of milliseconds. With the straight _delay_ms() macro, you can only use constant values.

I do not recognise your debugger. Can you ask it to display the ASM view?

Then you will see what code has actually been generated.

David.

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

Here is the disassemble of the 2 functions: Delay(), and CLS();

Attachment(s): 

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

If you can be bothered to follow the actual ASM code you will see what is happening.

Only a masochist would try to read this display.

When you ask it to Delay(2000) does it pause for 2 seconds?

Which debugger are you using?

David.

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

Why has the disassembler not shown the code between 0xA9C and 0xAB6? You can even see that the RJMP at location 0xAC2 jumps back to 0xAA4 which is in that range. The disassembler has just shown:

---

???

What is this development system/debugger/disassembler anyway? (it seems a bit crap if you don't mind me saying)

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

Quote:
What is this development system/debugger/disassembler anyway? (it seems a bit crap if you don't mind me saying)

Quote:
Which debugger are you using?

I'm using Proteus, .elf file,

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

I am looking forward to an experienced Proteus user who can report on whether Proteus actually works.

Meanwhile, I will just assume that it is dead. I can see little point in struggling with something that does not seem to work at all.

On the other hand, the concept of Proteus is brilliant. I have just never got anywhere with it at all. And I have never heard from anyone who has.

If the evaluation version actually worked, I would seriously consider buying the full version.

David.

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

Quote:

I am looking forward to an experienced Proteus user who can report on whether Proteus actually works.

Perhaps we get a tainted view here because no one ever writes to say "I'm using XXX and it's working well" so perhaps we get a mis-leading view of Proteus (and let's face it a lot of the users probably aren't using legal copies and can't call for official help ;-)) but it does seem like the biggest pile of steaming poo from all the evidence presented so far!

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

Hi there
I think it is not Proteus Problem, Because AVR studio simulator make the same behavior, when I run the AVR-studio simulator, It is not accept to make a break point at the same lines that Proteus shows that it is not compiled!!, and never execute these lines

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

Show us the disassembly that Studio gives you. As it uses word not byte addressing lets see what it's showing you between 0x54D to 0x55A I'll warrant that the entire code of CLS() that does the job you wrote in the lines of source IS there. (there may not be a 1-2-1 correspondence of course because of optimisation)

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

Quote:
Show us the disassembly that Studio gives you. As it uses word not byte addressing lets see what it's showing you between 0x54D to 0x55A

@0000054D: CLS
86:       {
+0000054D:   E7A4        LDI       R26,0x74       Load immediate
+0000054E:   E0B0        LDI       R27,0x00       Load immediate
---- H:\Projects\DotMattrixLEDDisplay\default/c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h 
105: File not found
+0000054F:   E323        LDI       R18,0x33       Load immediate
+00000550:   E037        LDI       R19,0x07       Load immediate
+00000551:   C00D        RJMP      PC+0x000E      Relative jump
+00000552:   01F9        MOVW      R30,R18        Copy register pair
+00000553:   9731        SBIW      R30,0x01       Subtract immediate from word
+00000554:   F7F1        BRNE      PC-0x01        Branch if not equal
---- main.c ---------------------------------------------------------------------------------------
102:         for  (x = 0; x < D; x++)
+00000555:   9601        ADIW      R24,0x01       Add immediate to word
+00000556:   E041        LDI       R20,0x01       Load immediate
+00000557:   3F84        CPI       R24,0xF4       Compare with immediate
+00000558:   0794        CPC       R25,R20        Compare with carry
+00000559:   F7C1        BRNE      PC-0x07        Branch if not equal
91:           Buffer [x] = 0x00;
+0000055A:   921D        ST        X+,R1          Store indirect and postincrement
88:         for (x = 0; x < DISPLY_SIZE; x++)
+0000055B:   E080        LDI       R24,0x00       Load immediate
+0000055C:   39AC        CPI       R26,0x9C       Compare with immediate
+0000055D:   07B8        CPC       R27,R24        Compare with carry
+0000055E:   F019        BREQ      PC+0x04        Branch if equal
+0000055F:   E080        LDI       R24,0x00       Load immediate
+00000560:   E090        LDI       R25,0x00       Load immediate
+00000561:   CFF0        RJMP      PC-0x000F      Relative jump
+00000562:   9508        RET                      Subroutine return
100:      {
+00000563:   E020        LDI       R18,0x00       Load immediate
+00000564:   E030        LDI       R19,0x00       Load immediate
---- H:\Projects\DotMattrixLEDDisplay\default/c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h 
105: File not found
+00000565:   E343        LDI       R20,0x33       Load immediate
+00000566:   E057        LDI       R21,0x07       Load immediate
+00000567:   C005        RJMP      PC+0x0006      Relative jump
+00000568:   01FA        MOVW      R30,R20        Copy register pair
+00000569:   9731        SBIW      R30,0x01       Subtract immediate from word
+0000056A:   F7F1        BRNE      PC-0x01        Branch if not equal
---- main.c ---------------------------------------------------------------------------------------
102:         for  (x = 0; x < D; x++)
+0000056B:   5F2F        SUBI      R18,0xFF       Subtract immediate
+0000056C:   4F3F        SBCI      R19,0xFF       Subtract immediate with carry
+0000056D:   1728        CP        R18,R24        Compare
+0000056E:   0739        CPC       R19,R25        Compare with carry
+0000056F:   F3C0        BRCS      PC-0x07        Branch if carry set
106:      }
+00000570:   9508        RET                      Subroutine return
@00000571: DisplyArabic
112:      {
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK and which part of the code do you NOW think is missing?

Buffer[] is clearly based at 0x0074 in SRAM as you can see X (that is R27:R26) being loaded with this address:

+0000054D:   E7A4        LDI       R26,0x74       Load immediate 
+0000054E:   E0B0        LDI       R27,0x00       Load immediate 

The Delay(500) is there as:

+0000054F:   E323        LDI       R18,0x33       Load immediate 
+00000550:   E037        LDI       R19,0x07       Load immediate 
+00000551:   C00D        RJMP      PC+0x000E      Relative jump 
+00000552:   01F9        MOVW      R30,R18        Copy register pair 
+00000553:   9731        SBIW      R30,0x01       Subtract immediate from word 
+00000554:   F7F1        BRNE      PC-0x01        Branch if not equal 
---- main.c --------------------------------------------------------------------------------------- 
102:         for  (x = 0; x < D; x++) 
+00000555:   9601        ADIW      R24,0x01       Add immediate to word 
+00000556:   E041        LDI       R20,0x01       Load immediate 
+00000557:   3F84        CPI       R24,0xF4       Compare with immediate 
+00000558:   0794        CPC       R25,R20        Compare with carry 
+00000559:   F7C1        BRNE      PC-0x07        Branch if not equal 

The Buffer [x] = 0x00 is there as:

+0000055A:   921D        ST        X+,R1          Store indirect and postincrement 

(the compiler always keeps 0x00 in R1 when it can).

You can also see Buffer[x] being indexed up to 0x009C when it does:

+0000055B:   E080        LDI       R24,0x00       Load immediate 
+0000055C:   39AC        CPI       R26,0x9C       Compare with immediate 
+0000055D:   07B8        CPC       R27,R24        Compare with carry 
+0000055E:   F019        BREQ      PC+0x04        Branch if equal 

From this I deduce that Buffer[] is being indexed for 0x009C-0x0074 = 40 elements so DISPLY_SIZE is 40.

The variable 'x' itself never really exists as the code just increments the index register from start to finish.

As 'x' never actually existed you wouldn't, or example, be able to observe it in a debugger watch window.

This is OPTIMISED code - either learn to study/debug it or switch the optimiser off and bare the consequences. (one of which is that will lead to about 1..2K of floating point code being added to your program!)

Cliff

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

Hi Cliff
Really I appreciate your effort to help me. many thanks.
I'm not familiar with assembly language, so, could u please tell me where the function Delay() calls the function _delay_ms()??? or how?? Is that at the label 102: ??

102:         for  (x = 0; x < D; x++)
+00000555:   9601        ADIW      R24,0x01       Add immediate to word
+00000556:   E041        LDI       R20,0x01       Load immediate
+00000557:   3F84        CPI       R24,0xF4       Compare with immediate
+00000558:   0794        CPC       R25,R20        Compare with carry
+00000559:   F7C1        BRNE      PC-0x07        Branch if not equal

Really thank u very much
Ahmed

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

Any reply??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
+0000054F:   E323        LDI       R18,0x33       Load immediate
+00000550:   E037        LDI       R19,0x07       Load immediate
+00000551:   C00D        RJMP      PC+0x000E      Relative jump
+00000552:   01F9        MOVW      R30,R18        Copy register pair
+00000553:   9731        SBIW      R30,0x01       Subtract immediate from word
+00000554:   F7F1        BRNE      PC-0x01        Branch if not equal

The basic time-wasting is in the SBIW, BRNE loop. The initial loop-counter is in R18:R19.
If you look up the instruction cycle count you will see that SBIW takes 2 and the BRNE take 2 cycles (until the test fails). So the sequence will take 0x0733 * 4 cycles. i.e. 7372 cycles.

You have never said. But my crystal ball says you are using a 7.3728MHz crystal and the sequence takes 999.9 microseconds.

You can do the exact cycle counting and timing in Studio.

If you draw out your Delay() function as a flow chart.

Then draw out the compiled version flow chart.

You will discover that the rearrangement of instructions has saved a few 'redundant' duplicate sequences.

But all this is fairly head twisting. Just forget about what contortions the compiler does. You give it high level instructions, and it is free to do the best that it can. Its only restriction is that it must obey the semantics of the language and be true to your logic.

If I ask you to drive from town A to town B, you can choose the shortest, fastest, longest route that you like. If you arrive in town B you have satisfied my request. If I ask you to go via town C or to stop for tea, then this is a new requirement. You must satisfy the new requirement.

David.

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

Cliff wrote:
Quote:

In this case, turning off optimization is an even worse kludge.

Can I quote you on that? ;-)

(looks like I just did)

Heavens, I've been skewered! :lol:

There's a scene from the movie "The Golden Child" where Eddie Murphy's character has been told by the Buddhist Master to "stay on the path". Of course, Murphy's character ends up having to jump "off the path" to save his life:

Murphy: I thought you said I had to stay on the path!

Master: Aahh, but you must know when to break the rules!

Stu

Edit 1: Besides, don't you get tired of answering and re-answering the question, "Help! The Compiler is broken! It doesn't compile some lines in my code!". If I thought any newbie would read it, I'd make that answer another sticky note. :roll:

Edit 2: Or maybe we can get the compiler optimizer to issue the warning "The following lines are being removed because they are stupid". :twisted:

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:

could u please tell me where the function Delay() calls the function _delay_ms()??? or how??

Aren't [at least] one of you gurus going to tell OP that there may not be an actual [R]CALL to another function, as the implementation of the "function call" may be a macro expansion or inlined? And thus put OP out of his misery?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

First, thank you all for your kindly reply's, and your effort to make me learn, I've learned so much from all of you.

Quote:
Aren't [at least] one of you gurus going to tell OP that there may not be an actual [R]CALL to another function, as the implementation of the "function call" may be a macro expansion or inlined? And thus put OP out of his misery?

And I'm so sorry if my questions seems stupid, I'm just a newbie.
Quote:
Edit 2: Or maybe we can get the compiler optimizer to issue the warning "The following lines are being removed because they are stupid".

I think this topic will help many people just like me, a newbie.

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

Quote:

And I'm so sorry if my questions seems stupid, I'm just a newbie.

But Lee's answer was spot on. For one thing GCC will try to inline small functions (perhaps too aggressively?) if it can unless -fnoinline_small_functions is used. So your own Delay() was likely to be inlined. But also, for functions like _deay_us() and _delay_ms() you can read in c:\winavrNNNNNN\avr\include\util\delay.h:

static inline void _delay_us(double __us) __attribute__((always_inline));
static inline void _delay_ms(double __ms) __attribute__((always_inline));

which is about as forceful as it's possibly to get to ensure that the code IS inlined and not geenrated separately and access by a CALL/RET. This is particularly important for something like _delay_us(). Consider it being used on a 1MHz processor where one machine cycle is already 1us. If a loop were generated to delay 10 cycles and THEN the routine itself were access by CALL and returned with RET this could easily add 4 cycles more to the delay time (I can't be bothered to look up those opcodes in the manual but 4 sounds about right).

Also the way _delay_ms()/_delay_us() work is by using floating point to calculate the number of delay loops to iterate but this relies on compile time optimisation to do the calculation so that the FP calculation does not have to be done at run time. If the code of the functions were in a separate file and the routine were actually called rather than being inlined the compiler would have no option but to actually pass the call time parameter rather than optimising it away.

So the bottom line is that you are not going to see specific CALL/RETs being used when you either call to other small functions in the same file or to functions that have specifically been defined as "static inline".

Again this is just another facet of debugging optimised code. Personally I think all C programmers should have at least a rudimentary appreciation or the target MPU/MCU's assembler and should debug in a mixed C/asm view to be able to see the "big picture".

Either that or throw any desire for decent quality code, switch off the optimiser (change -Os to -O0) and don't call library functions that require optimisation (so no use of _delay*() )

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

Quote:

I am looking forward to an experienced Proteus user who can report on whether Proteus actually works.

Quote:

Perhaps we get a tainted view here because no one ever writes to say "I'm using XXX and it's working well" so perhaps we get a mis-leading view of Proteus (and let's face it a lot of the users probably aren't using legal copies and can't call for official help ) but it does seem like the biggest pile of steaming poo from all the evidence presented so far!

I use it (legally!) almost every day at work. We're a university and use it heavily in our EE degree programmes.
Before I go on, I am a user of Proteus, not a member of their staff. My employer buys an update licence annually; we're customers.
It's not a pile of steaming poo, and I can attest to that, having produced many AVR-based circuits which I have designed and coded in either ASM or C within AVR Studio on one display and ISIS on the other display doing the debugging.
If all the ICs in a design are modelled in ISIS, there is a very high chance (nothing's perfect, but bugs in models are usually fixed very quickly) it will reflect real hardware. That's my experience as a long-term AVR and Proteus user.

The screeen grab below is something I did last year to demonstrate some I2C peripherals. The AVR is a Mega48, and I also have a PCF8593 RTC, a TC74 temperature sensor, a virtual terminal (displaying a UART stream - a serial port on the actual hardware) and the I2C protocol analyser.
All the coding was developed through simulation. I made the PCB, programmed it once and... it didn't work.

I'd forgotten to solder the RTC's 32kHz crystal on :-)
Once that was sorted out, everything worked.

We have PCBs at work with a Mega644P and ~20 peripherals on. All developed in Proteus; schematic, debugging and PCB.

I suggest anyone who has questions about the AVR simulation in ISIS visits Labcenter's support forum and ask there. However, most of us that frequent their forums don't respond to people using illegal copies.

It the OP's code, his functions do exist, but they're elswhere in his code. I'd drop a breakpoint at the first line of one of the functions and run the code.

Richard

Attachment(s): 

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

Richard,

Thanks for balancing the opinion here - but also try a thread search for "Proteus" and see how many people were misled by it's inability to simulate accurately (as I said above that's the only view we get of it here). I'd be interested to hear what you think of some of those results? Was it just misguided use in fact?

Cliff

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

clawson wrote:
Richard,

Thanks for balancing the opinion here - but also try a thread search for "Proteus" and see how many people were misled by it's inability to simulate accurately (as I said above that's the only view we get of it here). I'd be interested to hear what you think of some of those results? Was it just misguided use in fact?

Cliff

Cliff,
If I search for 'Proteus', it returns more than 240 threads. Any chance you can post a link to the one you mean?

Thanks,

Richard

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

Quote:

We're a university and use it heavily in our EE degree programmes.
May $DEITY have mercy with the tainted souls of those EEs.

Stealing Proteus doesn't make you an engineer.

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

One example I remember is this thread where it looks like Proteus is not able to properly handle relative jumps if a program counter wrap around takes place:
https://www.avrfreaks.net/index.p...

Stefan Ernst

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

All recent mentions of Proteus are referring to earlier reports on bad simulation. I went back 100 threads in the search result, or just over a full year, in a quick browse. The latest thread with anything like substantial matter on the subject seems to be from May 27, 2009:
https://www.avrfreaks.net/index.p...
but it looks like the matter is resolved, and was the usual "pilot error".

Here's a thread where, upon a quick re-inspection, it seems that Proteus does not handle "jump wraps" correctly:
https://www.avrfreaks.net/index.p...
(or just pilot error again - I didn't re-read it that thoroughly). If it does not handle wraps on jumps "outside of flash" then that is a serious deficiency. If.

This thread might also indicate a problem in Proteus:
https://www.avrfreaks.net/index.p...

In a few threads it is mentioned that Proteus uses the COFF debug format. Statements from people with great insight into these matters claim that COFF is a file format with deficiencies and practically dead, ELF/DWARF2 having been the preferred debug format for several years now.

There where several threads (didn't count'em but I'd say five to ten) where it was claimed that the simulation worked like it should.

But the gist of the last years posts on "Proteus" is that there is little, if any, substantial evidence on bugs. There are a lot of here-we-go again's and are-you-sure-Proteus-works, and it might be that the deficiencies of Proteus is in part a self-propelled rumour.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

What you see on freaks is that Proteus attracts a lot of extremely clueless people, who absolutely don't know what they are doing. Especially students, especially from India, seem to fall into that category.

In many cases I have the impression they use stolen copies and have the impertinence to come here to let us fix their problems with their stolen copies and to do their homework.

Proteus is like horse manure. Maybe nothing wrong with it, but you still don't want to find it in your driveway. And the flies on top of it aren't welcome, too.

Stealing Proteus doesn't make you an engineer.

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

JohanEkdahl wrote:

Here's a thread where, upon a quick re-inspection, it seems that Proteus does not handle "jump wraps" correctly:
https://www.avrfreaks.net/index.p...
(or just pilot error again - I didn't re-read it that thoroughly). If it does not handle wraps on jumps "outside of flash" then that is a serious deficiency. If.

I'll look at that more when I'm awake :-)

Quote:

This thread might also indicate a problem in Proteus:
https://www.avrfreaks.net/index.p...

That code works as expected on my (legal) copy of Proteus.

Quote:

In a few threads it is mentioned that Proteus uses the COFF debug format.

I've been using .elf files in ISIS for a long time.

Actually, it seems as though most of the slating Proteus gets is from people who have either never used it or never learnt how to use it. I'd also bet that most of the "problems" are seen on cracked versions. As I said, Labcenter's support is excellent, so paying users would, I hope, report suspected bugs to Labcenter directly.

Richard

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

ArnoldB wrote:
Quote:

We're a university and use it heavily in our EE degree programmes.
May $DEITY have mercy with the tainted souls of those EEs.

Why's that? What package would you suggest we use?

Richard

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

1. Yes, I forgot to mention after my trawl through the posts that ther cluelessness was abundant. As you note, there is nothing in that pointing to Proteus being bad.

2. Yes, the feeling of theft-ware was also strong.

3. My trawl should not be interpreted as a statement from me on the quality of, usability or "desirability" of Proteus. I don't own Proteus myself. I have never used it. It was just a pastime, and curiosity triggered by the feeling that there are posts repeating that we have seen a lot of reports on Proteus being bad. I don't recall those reports - and for the last year there has been very few, if any, definitive reports on that. (I still might be wrong).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:

That code works as expected on my (legal) copy of Proteus.

That poster >>seemed<< like an experienced user. Legal? Who knows.

But that post certainly contributes to our impression here. With AVR experience and a seemingly simple posted test program, what >>are<< we to think?

In that particular case, what do you think that poster's problem was?

I answered similarly:
https://www.avrfreaks.net/index.p...

An "advanced" timer mode on a relatively new AVR model, where we would have no reason (e.g., errata) to think that the AVR is faulty.

And I referenced back to
https://www.avrfreaks.net/index.p...

Yes, there are new twists in AVR8 timers. But they pretty much act as they have for the past 10 years. Thus when we see post(s) like this, where the Freaks are versy sure the AVR operates OK, what are we to think? Is it all "operator error"--looking at the wrong place, and/or at the wrong time?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

R_Reeves wrote:
What package would you suggest we use?
I am of two minds on that.

My history is in IC Design. There, simulation is the only way to cheaply debug the design. Even when I was doing it (16 years ago :shock:) it could cost as much as $3 Million (for the mask set) and a minimum of 3 weeks to run a chip. Simulation was the only game in town. We simulated at the very high level (register transfer), medium level (logic level), medium low level (special "digital" transistor level) and low level (SPICE). We generated test vectors and ran it against as many levels as we could. You can burn a lot of CPU cycles and engineer time to save $3 Million!

Then I started doing kernel work and embedded. There, the hardware already existed or could be prototyped up cheaply. Scopes, logic analyzers and In-Circuit Emulators became my best friends. After all, simulators could be wrong -- the hardware was what it was. If the hardware didn't work, you knew it was your fault.

Now, at the University level and teaching EEs, I'm stuck. I would like any EE graduate to know the ins and outs of simulation. But I also want the graduate to know that simulators are just that: simulations. They are not reality, but only a facsimile. I want the graduate to understand that there is a decision point when the simulations are over and it's time to get on with the hardware.

So, if Proteus is what your University believes is "best in class" given the competing goals of Cheap, Fast, and Good (and, knowing universities the world over, "cheap" is already chosen), use it. There are also other simulators, some of them free (for example, the one that comes with AVR Studio, with the external peripheral support of the free HAPSIM).

I will finish by emphasizing that learning the simulator is only a part of the complete education. As I said earlier, you have to know when to break the rules.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

theusch wrote:
Quote:

That code works as expected on my (legal) copy of Proteus.

That poster >>seemed<< like an experienced user. Legal? Who knows.

But that post certainly contributes to our impression here. With AVR experience and a seemingly simple posted test program, what >>are<< we to think?

In that particular case, what do you think that poster's problem was?


About 18 months ago, Labcenter rewrote their AVR models. There was a transition period where both the original AVR and the newer (AVR2.dll for anyone with a copy of Proteus) libraries were provided, although this only included, I think, about 20 devices. The Mega16 was one of the newer devices in the older libraries.
I'd also suggest that cracked can also mean broken...

Quote:

I answered similarly:
https://www.avrfreaks.net/index.p...

An "advanced" timer mode on a relatively new AVR model, where we would have no reason (e.g., errata) to think that the AVR is faulty.


I don't have any Tiny85s to play with (I do have a tube of Tiny26s at work though), but I've just thrown some code together and I manage 250kHz on OC1A. The screen capture is below, but I think I should be seeing 500kHz. If this is the case, then the Tiny85 model is stuck in low-speed mode (but not at 1.9kHz seen in the above thread). However, that's nowhere near as bad as not working at all. My numbers may be right though. Anyone?
Quote:

And I referenced back to
https://www.avrfreaks.net/index.p...

I don't have time to plow through that one at the moment.

Again, if people using a legal version of Proteus think they've found a bug, the best place to report it is on Labcenter's forum.

Richard

Attachment(s): 

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

stu_san wrote:
R_Reeves wrote:
What package would you suggest we use?
I am of two minds on that.

So, if Proteus is what your University believes is "best in class" given the competing goals of Cheap, Fast, and Good (and, knowing universities the world over, "cheap" is already chosen), use it. There are also other simulators, some of them free (for example, the one that comes with AVR Studio, with the external peripheral support of the free HAPSIM).


The problem with just AVR Studio is that it doesn't handle Spice models quite as well as Proteus, nor does it manage even rudimentary PCB design. It's CAD-CAM output is dire...

We use Proteus in our foundation-year EE module (teaching basic circuit theory, digital and analogue electronics), our first-year main electronics course (1/3 of the first year, combining analogue, digital, telecomms, PCB design and team-project work), our second-year analogue module (lots of transistor work), our second-year programmable-electronics module (large M644 circuit in both simulation and real life), and many of our final-year project students use AVRs, so Proteus is used there.

Our approach to teaching is to combine simulations and experimental work. For example, they design an active filter, simulate it, then measure the actual bandwidth in hardware.

For digital work, we do a lot of the flip-flop evolution in Proteus as it is much tidier than on breadboard. The breadboard takes over when we use IC flip-flops.

They do meet Spice-based convergence errors, but that's Spice for you.

The annual cost of Proteus is neither expensive (it's not my money :-) ) nor cheap (I'm glad it's not my money :-) ), but we are willing to pay it, as we get a lot for it.

Quote:

I will finish by emphasizing that learning the simulator is only a part of the complete education. As I said earlier, you have to know when to break the rules.

Stu


I'm not new to either electronics or education. Experience is what matters here. Students do seem perplexed when one component is accurately calculated, whist the one next to it is there because it happened to be nearby when a resistor was needed.

Richard
edited to remove typo