Delay PASM
Hello ,
I'm still working on my Lcd driver...
I noticed that my timers are " messed up "
lcd_reset has need almost 2 second to reach ret (??)
for example
http://pastebin.com/pQdy7mgN
any tips ?
Thanks
I'm still working on my Lcd driver...
I noticed that my timers are " messed up "
lcd_reset has need almost 2 second to reach ret (??)
for example
wait100us rdlong delay100us, #5 mov t2, cnt ' setup add t2, delay100us ' first add waitcnt t2,delay100us wait100us_ret retI know #5 is the 5th location as see
delay long 80_000_000 ' 1 second = 12.5ns*80KK loc 0 delay20ms long 1_600_000'............................... ' 1 delay10ms long 800_000'................................. ' 2 delay6ms long 480_000'................................. ' 3 delay200us long 16_000'.................................. ' 4 delay100us long 8_000'................................... ' 5 delay1us long 8'....................................... ' 6 ' or byteso 8000*12.5ns@80Mhz = 100us
http://pastebin.com/pQdy7mgN
any tips ?
Thanks

Comments
There are two values stored in the initialization area that might be of interest to your program:
a long at $0000 contains the initial master clock frequency, in Hertz
(e.g how many cnt you should wait for, to wait 1second)
I don't see any mention of a table in hub that you are referring to.
So I think you gone have to make your own table. (btw it's 80 cnt cycles in a micro second)
Your code already have a hardcoded one, so skip the rdlong #5 etc
And you could change it to:
waitcnt t2,#0
As delay is added to t2 after the wait, so unless you know what value t2
should have for next waitcnt, you just as might add 0 to it.
But it's good idea to not have a hardcoded table, so read hub location 0
Though dividing by 10 and 100 is not that easy in pasm, but by 4, 8 and 16 is
Personally I think you use CALL a little to much in your code.
When something can be done in 3 lines of code I would not use a subroutine.
mov cnt,delay100ms ' leftside cnt is a shadow and can be used as "regular memory".
add cnt,cnt
waitcnt cnt, #0
"rdlong delay100us, #5" reads the contents of HUB address 4 (rdlong ignores lower 2 bits).
Why don't you do this instead ?
When you say rdlong ignores lower 2 bits , you mean that they are step by 4 ( so it is 32) bit) ?
I thought it was already "formatted" , I mean #0 ->0,1,2,3 #1->4,5,6,7 and so on...
thanks again,
start from scratch is not easy but I feel I am near to solution and I have some trouble to feedback my code. PASD doesnt keep the timing right (?) so I just add one led....
I am sure the trouble is the timing and the Register Select......
Thank to all
may I wrong, but I use call to keep code readable ( by my opinion) as write DelayUs (100); or Lcd_dat(0x80); and so on
the code is useless but it works and I learned some stuff .D
Thsnks
Your code does have some "wrong" way of doing things and repeated code like mov dira, port
rdlong will only read from 4n values, reading from 5,6,7 is the same as reading from 4
rdlong and friends read data from a given HUB memory location. The only "formatting" you get is the "data type" width. rdlong get 32 bits, rdword gets 16 bits, rdbyte gets 8 bits. There is nothing automatic about the addresses that rdlong uses other than it will read on a 32 bit boundary.
rdlong value, #0 reads the content of HUB address 0 into value. this is usually the propeller startup clock frequency. If you want to read from HUB address 4, you would say rdlong value, #4, if you want to read from HUB address 12, you would say rdlong value, #12.
rdword value, #14 reads the content of HUB address 14. Address 14 is word 1 of address 12.
if you have this: It will read the content of hub address 0 into value.
If you want to read contiguous longs, do something like this:
If you want to read contiguous words, do something like this:
But where does address come from? Usually it is passed to the COG using a mailbox via the PAR register - that is the best practice. If you need to read the first 512 bytes and know what your doing, you can use the # syntax as described before.
You can set a breakpoint in PASD and run to the break. It will run real-time. If you're unlucky your break point will not get hit, and you'll have to reload the program.
I would not say that. The proper statement would be "The code is not needed now. But I made it work and learned from it." Now that is code with value.
Frank
I agree , I have to improve the code
Thanks for detailed answer . I have to improve my code or/and add new functions
I agree! You're right
It looks easy but
where It doesnt print char 'A' on LCD
Why would "rdlong cmd,#4" let you print 'A' on the LCD?
"mov cmd, prova" might work.
The longs in the dat section are not referenced by #4
try this in start:
cognew(@entry,@prova)
then use "rdlong cmd,par"
that should work if "mov cmd,prova" works.
you could try "rdlong cmd,prova" directly but I'm not sure if that would work or not.
I need to save one or more strings in order to show it on lcd
example :
message1 byte "message 1 test"
message2 byte "message 2 test"
The char 'A' is just an test
Yesterday I read the manual but I forgot to add "msg" to COGNEW
PAR is a pointer ?I dont know like scan the whole string
I am debbuging it
This should not be rdlong. Use mov instead. Par is a pointer already and we want to dereference the pointer, not the contents.
I forgot
Hello,
it works
but manage DAT section is a bit "dungerous"
for example I cant use _delayus here:
If I change my section DAT in
The code works at 90% :
it print "ello World" not "Hello world"
delayms has no problem. It is not a problem timing related because 400us are enought
Some days ago I finished my lcd routine.It helped me to learn a bit of pasm ( delay,string,clr bit,uart,Dat section ecc....)
Im going to make one for Graphic lcd
I know it isn't so good but any feedback greatly appreciated