Ya, Windoze has the best microcontroller tools. I've done some stuff with Piklab, but I run a windoze box at my electronics table. It does dual-boot Ubuntu, but normally runs Windows.
As for you never trying GCC for PIC, have you used any of Microchip's compilers? They're all GCC based, as far as I know.
I hate to sound like a broken record, but...
Ya,
As for you never trying GCC for PIC, have you used any of Microchip's compilers? They're all GCC based, as far as I know.
but now know that one must be very careful doing this.In general, you will have to use ASM inside C application in many cases when some precision or speed is needed
Engblom said:Using inline assembly is a very efficient way of hampering the compiler's optimizer. Since there is a block of code that the compiler knows nothing about, it cannot optimize across that block. In many cases, variables will be forced to memory and most optimizations turned off.
The output of a function containing inline assembly should be inspected after each compilation run to make sure that the assembly code still works as intended. ....
void delay(unsigned int time)
{
unsigned int i;
for (i=0; i<time; i++)
;
return;
}
void InitHW(void)
{
/* Highly timing - dependent code */
OUT_SIGNAL (0x20);
delay(120);
OUT_SIGNAL (0x21);
delay(121);
OUT_SIGNAL (0x19);
}
void delay(unsigned int time)
{
/* loop removed */
return;
}
futz said:I hate to sound like a broken record, but...
I got PICC for some 20$
Well put.
A good compiler preforms optimizations that will suprise many/most good asm programmers. That has been true for over 20 years.
Yes, optimised C compilers produce truely appallingly bad code
but now know that one must be very careful doing this.
WOW! That was a great deal! Is there a smiley for envy?
I didn't like Mikro at all, and don't understand how anyone who doesn't like windoz would like it. The reasons are that it has no MPLab integration, so I can't just download the program to the chip, as I don't have their propriety programmer... I have no access to thier propriety libraries....
Yes, optimised C compilers produce truely appallingly bad code
Iillogical and very difficult to follow.
That is why one must know his compiler
The "DEV" kit was ~100$ .. 80$ without PICC and 100$ with PICC, only 1 year "update/support" and only pic16F and less (no pic18F support).. the DEV kit was bit "overpriced" but in general, it got me started
I hope I will get some free time in next few weeks to do a small C compiler comparison (the asm output comparison of some "usual" compiler problems)... it might be good article for the next version of junebug
At least you don't advocate writing in hex and hand assembling from the op codes.
Same here on an RCA COSMAC1802.
Well I know Bill is up with the times, I've heard him talk about it.
One day Sir Nigel is going to try out C, and there will be no looking back.
I didn't mind looking up the op codes (6502) too much, or punching them in on the darn keypad, but what I hated was when the power went down.....
well, at least I didn't have to look up the codes again, but if the program was any length, even punching it in again was not fun, especially if it did much of anything useful.
The mnemonics, and a software assembler made things much faster than looking up the hex, didn't they?
It's what was available at the time, initially all I had was hand assembly and 1K of RAM (including video display RAM), next I added an extra board which provided more RAM, space for EPROM, a cassette interface, and a simple single pass assembler. The cassette interface required it's read program typing in as HEX before you could use it- once you're typed the write program in, the first thing you did was save that to tape, so it was only the read part you had to type in every time.
Those were the days!
There was a simple monitor program in EPROM, this allowed you to enter HEX code in memory, run the code, set breakpoints etc.
The tape routines were all typed in initially, but once you'd typed the 'tape write' routines in, you could write it to tape and never need to type it again. The 'tape read' routine though needed typing in before you could read anything.
Once I upgraded to the enhanced monitor, this included an assembler, and the tape routines in EPROM - made life MUCH easier.
Very true. I recently started with MicroChip's C30 compiler for the dsPIC and was curious about dsPIC assembly so I looked at the generated assembly code. What looks efficient in C is not necessarily true of the generated code:That is why one must know his compiler
LATBbits.LATB1 = 1;
LATBbits.LATB2 = 1;
//Compiles into this:
078E A822CC bset.b 0x02cc,#1
0790 A842CC bset.b 0x02cc,#2
LATBbits.LATB2 = LATBbits.LATB1 = 1;
//Which compiles into this mess:
07C2 A822CC bset.b 0x02cc,#1
07C4 BFC2CC mov.b 0x02cc,0x0000
07C6 FB8000 ze 0x0000,0x0000
07C8 D10000 lsr.w 0x0000,0x0000
07CA 604061 and.b 0x0000,#1,0x0000
07CC 604061 and.b 0x0000,#1,0x0000
07CE DD0142 sl 0x0000,#2,0x0004
07D0 202CC1 mov.w #0x2cc,0x0002
07D2 784091 mov.b [0x0002],0x0002
07D4 B3CFB0 mov.b #0xfb,0x0000
07D6 60C000 and.b 0x0002,0x0000,0x0000
07D8 704002 ior.b 0x0000,0x0004,0x0000
07DA B7E2CC mov.b 0x0000,0x02cc
Very true. I recently started with MicroChip's C30 compiler for the dsPIC and was curious about dsPIC assembly so I looked at the generated assembly code. What looks efficient in C is not necessarily true of the generated code:
Which is way more efficient than this:Code:LATBbits.LATB1 = 1; LATBbits.LATB2 = 1; //Compiles into this: 078E A822CC bset.b 0x02cc,#1 0790 A842CC bset.b 0x02cc,#2
Code:LATBbits.LATB2 = LATBbits.LATB1 = 1; ...snip... //Which compiles into this mess:
//Which compiles into this mess:
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?