Hey guys i will be trying to help out and post code snippets now and then. Here
is my code for controlling a 2x16 LCD, 4-Bit mode using a LPC2148:
http://atomsofttech.info/code/LCD.rar
LPC2148 Olimex 2x16 LCD Code
Started by ●October 19, 2009
Reply by ●October 19, 20092009-10-19
Not bad. Why don't you set up your delay to be a timer instead of for
loop? So I give you a B+. :)
--- In l..., "Jason" wrote:
>
> Hey guys i will be trying to help out and post code snippets now and then. Here is my code for controlling a 2x16 LCD, 4-Bit mode using a LPC2148:
>
> http://atomsofttech.info/code/LCD.rar
>
--- In l..., "Jason" wrote:
>
> Hey guys i will be trying to help out and post code snippets now and then. Here is my code for controlling a 2x16 LCD, 4-Bit mode using a LPC2148:
>
> http://atomsofttech.info/code/LCD.rar
>
Reply by ●October 20, 20092009-10-20
heh, will do! I just moved some PIC code i made to ARM. I Will create the code
for timer delays later on today.
--- In l..., "redwire85" wrote:
>
> Not bad. Why don't you set up your delay to be a timer instead of for loop? So I give you a B+. :)
>
> --- In l..., "Jason" wrote:
> >
> > Hey guys i will be trying to help out and post code snippets now and then. Here is my code for controlling a 2x16 LCD, 4-Bit mode using a LPC2148:
> >
> > http://atomsofttech.info/code/LCD.rar
>
--- In l..., "redwire85" wrote:
>
> Not bad. Why don't you set up your delay to be a timer instead of for loop? So I give you a B+. :)
>
> --- In l..., "Jason" wrote:
> >
> > Hey guys i will be trying to help out and post code snippets now and then. Here is my code for controlling a 2x16 LCD, 4-Bit mode using a LPC2148:
> >
> > http://atomsofttech.info/code/LCD.rar
>
Reply by ●October 21, 20092009-10-21
> Not bad. Why don't you set up your delay to be
a timer instead of for
> loop? So I give you a B+. :)
B+ is not Good. I too prefer loop delay, when micro has little to do in
between. And more over LCD delay are mostly a few microsecs only.
Warm Regards,
Mukund Deshmukh,
Beta Computronics Pvt Ltd,
10/1 IT Park, Parsodi,
Nagpur -440022.
> loop? So I give you a B+. :)
B+ is not Good. I too prefer loop delay, when micro has little to do in
between. And more over LCD delay are mostly a few microsecs only.
Warm Regards,
Mukund Deshmukh,
Beta Computronics Pvt Ltd,
10/1 IT Park, Parsodi,
Nagpur -440022.
Reply by ●October 21, 20092009-10-21
On 21 Oct 2009, at 05:19, Mukund Deshmukh wrote:
> B+ is not Good. I too prefer loop delay, when micro has little to do
> in
> between. And more over LCD delay are mostly a few microsecs only.
Do you work alone, by any chance? Trying to debug the kind of random
error you get when you change clock frequencies or compiler settings
with spinning delays is a nightmare. Especially when you weren't
aware of the loop!
It also needlessly complicates porting to a different architecture,
requiring a whole new set of measurements to be made. Even something
as trivial as a new point-release of the compiler will probably screw
up your code.
Pete
> B+ is not Good. I too prefer loop delay, when micro has little to do
> in
> between. And more over LCD delay are mostly a few microsecs only.
Do you work alone, by any chance? Trying to debug the kind of random
error you get when you change clock frequencies or compiler settings
with spinning delays is a nightmare. Especially when you weren't
aware of the loop!
It also needlessly complicates porting to a different architecture,
requiring a whole new set of measurements to be made. Even something
as trivial as a new point-release of the compiler will probably screw
up your code.
Pete
Reply by ●October 21, 20092009-10-21
> Do you work alone, by any chance?
You guessed it right!!
> error you get when you change clock frequencies or compiler settings
> with spinning delays is a nightmare. Especially when you weren't
> aware of the loop!
Changing frequency will screw up timers too.
>
> It also needlessly complicates porting to a different architecture,
> requiring a whole new set of measurements to be made. Even something
> as trivial as a new point-release of the compiler will probably screw
> up your code.
My refrence was to character LCD code only and Larger delays definately
need timers.
Warm Regards,
Mukund Deshmukh,
Beta Computronics Pvt Ltd,
10/1 IT Park, Parsodi,
Nagpur -440022.
You guessed it right!!
> error you get when you change clock frequencies or compiler settings
> with spinning delays is a nightmare. Especially when you weren't
> aware of the loop!
Changing frequency will screw up timers too.
>
> It also needlessly complicates porting to a different architecture,
> requiring a whole new set of measurements to be made. Even something
> as trivial as a new point-release of the compiler will probably screw
> up your code.
My refrence was to character LCD code only and Larger delays definately
need timers.
Warm Regards,
Mukund Deshmukh,
Beta Computronics Pvt Ltd,
10/1 IT Park, Parsodi,
Nagpur -440022.
Reply by ●October 21, 20092009-10-21
And most people create timers just to spin-wait on the result! I see this
on ADC's too! If you're not going away to do something else -- then coming
back later -- using a timer is a waste. In any event, you can service
interrupts during the LCD delay. My preferred method is generally to write
to a virtual LCD buffer and then send that to the LCD as a low priority
task.
GB
>> Not bad. Why don't you set up your delay to be a timer instead of for
>> loop? So I give you a B+. :)
>
> B+ is not Good. I too prefer loop delay, when micro has little to do in
> between. And more over LCD delay are mostly a few microsecs only.
on ADC's too! If you're not going away to do something else -- then coming
back later -- using a timer is a waste. In any event, you can service
interrupts during the LCD delay. My preferred method is generally to write
to a virtual LCD buffer and then send that to the LCD as a low priority
task.
GB
>> Not bad. Why don't you set up your delay to be a timer instead of for
>> loop? So I give you a B+. :)
>
> B+ is not Good. I too prefer loop delay, when micro has little to do in
> between. And more over LCD delay are mostly a few microsecs only.
Reply by ●October 21, 20092009-10-21
Thanks to all for the comments. I do feel like the loops are easiest to do but
timers are more accurate and as stated on can accomplish something while they
wait. But also like someone else said... if im not doing anything while waiting
then why use a timer. So my answer is... no timer for me :D
Ill be sure to use a timer for something else once i fully learn it all.. (well as much as i can.)
I am a hobbyist. I do this for fun and learning and self awareness of electronics.
I plan on creating a full home automation system one day. When i move from my current residence :D
ARM will definitely be my choice. .. . once i start making my own boards tho :D
Ill be sure to use a timer for something else once i fully learn it all.. (well as much as i can.)
I am a hobbyist. I do this for fun and learning and self awareness of electronics.
I plan on creating a full home automation system one day. When i move from my current residence :D
ARM will definitely be my choice. .. . once i start making my own boards tho :D
Reply by ●October 21, 20092009-10-21
--- In l..., "Jason" wrote:
> But also like someone else said... if im
> not doing anything while waiting then why use a timer. So my answer
> is... no timer for me :D
>
The greatest danger of NOT using a timer when implementing delays with most C development systems is that optimisation settings are volatile. They can often be changed without even changing the source code! It is not just a case of accuracy - your delay could be optimised away to nothing without you realising it.
> Ill be sure to use a timer for something else once i fully learn it all.. (well as much as i can.)
>
That's OK, but think twice about any examples that you publish before you have some confidence that you have 'fully learnt it'. There is always more than one way of doing things and rarely is one way clearly the best. A good approach is to implement a solution to a problem in three different ways and then identify the advantages and disadvantages of each.
--
Chris Burrows
CFB Software
Armaide: LPC2xxx Oberon-07 Development System
http://www.cfbsoftware.com/armaide
> But also like someone else said... if im
> not doing anything while waiting then why use a timer. So my answer
> is... no timer for me :D
>
The greatest danger of NOT using a timer when implementing delays with most C development systems is that optimisation settings are volatile. They can often be changed without even changing the source code! It is not just a case of accuracy - your delay could be optimised away to nothing without you realising it.
> Ill be sure to use a timer for something else once i fully learn it all.. (well as much as i can.)
>
That's OK, but think twice about any examples that you publish before you have some confidence that you have 'fully learnt it'. There is always more than one way of doing things and rarely is one way clearly the best. A good approach is to implement a solution to a problem in three different ways and then identify the advantages and disadvantages of each.
--
Chris Burrows
CFB Software
Armaide: LPC2xxx Oberon-07 Development System
http://www.cfbsoftware.com/armaide
