And you tell me this is easy to follow.Yes, the input could be t[3]={"3",0x00,0x00}
On the LCD I want the format XX:XX:XX
So t[]={"3",0x00,0x00} needs to become {"0","3",0x00}
If t[]={"3","0",0x00} already, nothings needs to be done!
It is nothing in C, neither an array nor a string!
I simply treat it as pointer to 8-bit char.
And that can be indexed, incremented, all that!
If I wanted to, I would change it to INT pointer, and all would change to 16bit. Well almost, some minor changes required.
In assembler, I would have to rewrite everything!
The fact is that C is caring about the datatype!
But if it is a string, or array, is not much relevant. Indeed simple strings are largely the same as 8-bit element arrays.
Example yes, I simply pass the start address of my string buffer,
and run the function over it. The result is the string will always have 2 digits.
Yes you guess it all right. I thought it would be a rather trivial program.It's simple enough, but I was confused. I just can't imagine why you would program yourself into a situation where you have a string variable with a left justified single digit number. Is that how the itoa() function returns a string (left justified)?
BTW, has anyone figured out what the code in post #1 is supposed to do? It looks like it's trying to update a time display of some sort but the absence of any comments makes it difficult to understand. For example, what does the lcd_str() function do? I would assume it's printing the one or two ASCII digits contained in the time_buf variable. Also, what is returned from the l = lcd_str(time_buf) assignment operation? Is it the length of the time_buf string? If so, then is it possible that routine might actually print something like "0 :2 :4 " onto the LCD screen?
Yes in assembler you sometimes hope it would work by itself, and do nothing.And you tell me this is easy to follow.
In asm I need to do nothing. So which is better?
Yes it will produce rather lengthy assembler code. And what? 16K FLASH available, and it's not time critical at all. All perfectly fine!Oh my! That's all it does? I put it in a BoostC program for a 16F1828 and the output was 53 words of program memory (ouch!).
Anyway, thank you for taking time to explain the function. It explains a lot (lol)...
Cheerful regards, Mike
SO you are admitting that there is a place for asm.Using assembler for time critical parts of the program is the last resort.
5 stars!SO you are admitting that there is a place for asm.
We just dropped it from our curriculum.
consider the following code example:
Rich (BB code):while(1) { if(prg_status&c_prg_status_500msec) { LC7=led_0&0x01; time_1sec(); lcd_cmd(0b1010,10); lcd_cmd(0b1000,10); itoa(&time_buf,hours,10); l=lcd_str(time_buf); for(i=0;i<(2-l);i++)lcd_char(" "); lcd_char(":"); itoa(&time_buf,minutes,10); l=lcd_str(time_buf); for(i=0;i<(2-l);i++)lcd_char(" "); lcd_char(":"); itoa(&time_buf,seconds,10); l=lcd_str(time_buf); for(i=0;i<(2-l);i++)lcd_char(" "); prg_status&=(0xff-c_prg_status_500msec); } }
It took an hour or so to decipher the function, due to lack of any meaningful comments, and about five minutes to write an equivalent assembly language function (with the output corrections you wanted).How much time would it take to write this in assembler?
The equivalent assembly language function, minus supporting library functions (just like your code), might look like this;How much space would it take?
;******************************************************************
; main loop *
;******************************************************************
loop
btfss t500ms ; 500 msecs? yes, skip, else
goto loop ; loop (wait for 500 ms interval)
;
; print time as HH:MM:SS on right half of first line on the LCD
;
putcmd (line1+8) ; lcd line 1, tab 9
puthex (hours) ; print hours digits
putdat (':') ; print ':' colon character
puthex (minutes) ; print minutes digits
putdat (':') ; print ':' colon character
puthex (seconds) ; print seconds digits
bcf t500ms ; clear 500 msec flag
goto loop ;
I would need some hard data to agree the penalty for C is that high.Using C, developement is 10x to 15x faster, at the cost of 2x to 3x memory footprint, and it is slower as well.
It may be the same, it ain't gonna be faster unless your compiler optimizes away large segments of your code.If you write good C code, it won't be much slower, it even can be faster in some instances.
Assembler can do anything that C can do.You can use addressing schemes that are too complex for assembler to use!
Thank you for your input and the work involved.Would anyone mind if I take a quick stab at addressing the first couple questions from the first post?
It took an hour or so to decipher the function, due to lack of any meaningful comments, and about five minutes to write an equivalent assembly language function (with the output corrections you wanted).
The equivalent assembly language function, minus supporting library functions (just like your code), might look like this;
Your other comments and questions are difficult to address. I apologize.Rich (BB code):;****************************************************************** ; main loop * ;****************************************************************** loop btfss t500ms ; 500 msecs? yes, skip, else goto loop ; loop (wait for 500 ms interval) ; ; print time as HH:MM:SS on right half of first line on the LCD ; putcmd (line1+8) ; lcd line 1, tab 9 puthex (hours) ; print hours digits putdat (':') ; print ':' colon character puthex (minutes) ; print minutes digits putdat (':') ; print ':' colon character puthex (seconds) ; print seconds digits bcf t500ms ; clear 500 msec flag goto loop ;
Good luck on your projects and discussion.
Cheerful regards, Mike
Yes it can. One time I used a technique similar to relocation tables in MSDOS .EXE files. It was totally efficient actually.I would need some hard data to agree the penalty for C is that high.
It may be the same, it ain't gonna be faster unless your compiler optimizes away large segments of your code.
I had one C program needed to fit inside 1K where I found it helpful to use assignment operators (x += y as opposed to i = i + x) as it saved a few bytes here and there. I also wrote my own multiplication and division routines, those from the built in functions were just too large to fit.
Assembler can do anything that C can do.
Sorry, I don't understand your comment.Thank you for your input and the work involved.
Assembler has known non-encapsulation issue.
Sorry, again, I don't understand your comment. Forgive me for asking but is English your first language?If my code takes you one hour to decipher than I may evealute your professional mileage.
Actually, I'm not too bad at analyzing code and writing assembly language and C programs. It probably took the better part of an hour to realize you really coded something that would produce that flakey output. If your other programs are of the same quality, I really don't want to see them (LOL).I am doing things like Huffman compression, JPEG in C, and that's a bit more non-trivial. Given that above code would take you one hour to decipher, how would you get along with said codes? Or 3D programming books? Assembler?
I've done LCD clock routines etc in both ASM and C for years, and to my thinking it looks like you are trying to patch up a problem that should not have been there in the first place.Yes, the input could be t[3]={"3",0x00,0x00}
On the LCD I want the format XX:XX:XX
So t[]={"3",0x00,0x00} needs to become {"0","3",0x00}
...
You are simply not benevolent towards me and/or my topic.Sorry, I don't understand your comment.
Sorry, again, I don't understand your comment. Forgive me for asking but is English your first language?
Actually, I'm not too bad at analyzing code and writing assembly language and C programs. It probably took the better part of an hour to realize you really coded something that would produce that flakey output. If your other programs are of the same quality, I really don't want to see them (LOL).
Once again, good luck with your projects and your discussion.
Cheerful regards, Mike
I would like, on this occassion, to return the benefit of doubt, and to express a good-luck wish for using any kind of assembler.Once again, good luck with your projects and your discussion.
That depends on who writes it. I've did "encapsulated assembly" when I was developing methods to write COM objects in pure assembly.Assembler has known non-encapsulation issue.
Yes I follow your explanation and would like to thank you.I've done LCD clock routines etc in both ASM and C for years, and to my thinking it looks like you are trying to patch up a problem that should not have been there in the first place.
In an embedded C clock I would have used;
ByteToStr(hours,t); // get a 3char right justified string
if(t[1]==' ') t[1]='0'; // convert leading blank to leading zero
and then just displayed the string starting from t+1 which eliminates the other leading blank.
In ASM I probably would have kept hours in 2 variables; hoursH and hours so they were already stored in 2 single chars ready to display.
If I was forced to use a single var for hours, it is very fast converting to 2 digits using a subtraction algorithm even in ASM is only a few instructions;
while(hours>=10) then hoursH++ and hours-=10
I think you were making the argument that a big chunk of C is hard to write in ASM, but I think your premise is wrong. You don't take a chunk of C and re-write it in ASM, any more than you would take say a 7805 regulator and reconstruct it using 52 transistors like NatSemi used. You would design a transistor based regulator from scratch using maybe 4 transistors and a zener diode.
Please tell us why you feel "buggered"? That was not my/our intention. And I apologize because I really am having trouble understanding your use of language.You are simply not benevolent towards me and/or my topic.
Language skills, as said encapsulation and all this can be subjects of esoteric elaboration.
I have come accross some larger assembler sources, some good ones, as well many bad one's.
Most I have seen were bad.
Maybe I could encourage you, after reading the thread, to consider to stop using assembler where possible? There are many misguided people who still put a lot of efforts into it.
It causes a lot of fallacious thinking as well.
In C I am mainly interested to get the job done, how it works is secondary in most cases.
Assembler will among other things cause considerable arrogance and ideas of being omnipotent (which don't correlate much to reality, control even over the chip is rather poor).
It will cause a lot of useless efforts to optimize, downto a few bytes level.
I would like, on this occassion, to return the benefit of doubt, and to express a good-luck wish for using any kind of assembler.
For the desire to see sources codes that I wrote, isn't it rather a question if you are into the thing they are designed for?
If you want to do...this or that...then you will look at source codes which do...this and that.
Strings handling is quite a commonplace and trivial many people deal with it. If my stuff does not work out for you, well why deal with it at all? I tend not to reply to threads when there is something that buggers me.
by Jake Hertz
by Jake Hertz
by Jake Hertz
by Don Wilcher