Printable View
Hi,
i have don a lot of projects in picbasic but i found that the best langauge is assembely so i want to somebody give me a link for downloading a book(free) or for example a pdf file (free) to learn assembely in adavance?
i work with pic microcontrollers.
Here ... but in French !! ( why not BabelFish it ??? )
http://www.von-info.ch/PIC/bigonoff_01.htm
Alain
Hi, the site you told me is not english. i can't understand anything.
Hi Amindzo,
try http://www.mikroe.com/en/books/picbook/0_Uvod.htm
and you can progressively read-on line and use it. Hope you will love it.
Hi mvs_sarma,
thank you very much.it is very useful!
Hi,
Is there a tutorial (in pdf) from Microchip available?
ken
I'm sure there's a lot of tutorial's around the internet on assembly, just nothing specific to a PIC, and I haven't seen anything lately. There's a few books out there that do assembly fairly well (myke predko springs to mind).Quote:
Originally Posted by lerameur
Once you get into the assembly part of the PIC, you'd be surprised at how close PBP really is to assembly, different names for commands (and a few more variations thereof), but you get the same end results.
Ken, you can also download the French tutorial from Bigonoff. Outdated, but nice to begin.
Many good old assembler tutorial books from Microchip (can't tell if there's still available), also any of Square 1 are nice (PIC'n up the Pace, Easy PIC'n etc etc)
well I have been told that picbasic is a lot slower and have more overhead (memory space) then assembly for sure, but also C. Would C be better to learn if performance is a goal.
k
Look at a PBP's compiled/assembled program, then take a look at that same PBP source code. You'll see that they are very similar in size and function.Quote:
Originally Posted by lerameur
I have found that there is very little overhead when dealing with PBP and as far as speed goes, that goes with overhead. If your functions in PBP are complex, then so will the final assembly code. That goes for any language. Even if you're programming in straight assembly. If you've got something complicated to do, then it's going to take complicated steps to get complicated work done.
Now then, if this person that told you that PBP was slower and bloated with overhead, but this person was actually talking about the BasicStamp (and it's happened many times before), then yes, the BasicStamp is a lot slower, because it is an interpreted language, and does have a lot of memory and CPU cycle overhead because it is interpreted on the fly. PBP is pre-compiled before being burned into the chip.
It's a lot like learning how to do something the first time.
Either you can read a book and memorize each step ahead of time so you can do the task without stopping (PBP)......or you can put the book 20ft away from you on the other side of the room and refer to it for each step of the task (BasicStamp).
And as far as learning C goes....to each their own. I don't see (C :) ) any advantage in using C with the PICs, maybe the larger dsPICs and maybe the 24F series, but not in the 10F/12F/16F/18F range. A program written for PBP and a similar functioning program written in C will most likely compile down to the same functionality, speed, code size (all other things being equal), and probably the exact same code itself.
C is usually better seen in the industry as a 'standard language'. Basic have the bad reputation to be a beginner, sloppy, foo-foo, and/or dead language.
Well, it's what we already heard... but hey! we all know it's pure crap. When you're able to convict those C converted, your half done.
The power of any compiler is down to the guy(girl, human, alien) back to the keyboard. Get the job done, fast and bugfree, and that's it. There's a huge a s s kicking session to do for that in the market.
at the end... it's still in assembler :eek:
I know many business boss refuse to hire people just because they don't know about C, and MPLAB tools (debugger, simulation tools and all these stuff i don't use)... life is cruel. I wouldn't have a job right now. Don't give up and show'em what's your capable of!
Don't give up!
Hi,
whether Basic or C or any other high level language-- you can see later--
i feel better you do some funda in assy language for gaining command over the chip and its intricacies.
after you fiish implementing few projects, you try to go foe bulk programming-- then you can start pacticing whichever HLL you like- cuz whetther apple orange, pineapple, leamon--it is taste for it and for example,
I try to argue in favorof a lanfguage, that i have been practicing and always i try try to put plus points of that-- but natural.
but you better have few projects developed in assy language -- it helps you
Hi, i have done alot of project in picbasic but i found that it has some problem,for example i found that in conditional instruction (if... then..),intrupt doesn't work.
i wrote a program to read the keyboard(4*4) with conditonal instruction but RB0 interrupt didin't work but when i used RB0 interrupt in other programs without conditional instructions it worked ver well.
so i think the best langauge is assembly.it's faster. conversion of the C or Pic basic to assembely or hex file is not optimal. in some project speed is very important so the best choice is assembly.
I admit that I am no expert in these languages, but , to my little knowledge, any program written in HLL has to be compiled and you know what happens if you compile such a file. it looks into a pre wriitten code and uses a judicious part of the code available there. Perhpas over a period these HLLs are revised to cover difficiencies. --that is the reason you find that a particular suppliers Basic otr 'C' is better than others etc,Quote:
Originally Posted by amindzo
thus ifeel there is nothing wrong, ifct it is better to write(be able to write) in assy language. aprogram written by a skilled writer in assy is much better than a compiled Basic or C-- of course my personal feeling.
Whatever the language you're using, just get the job done and that's it.
mvs_sarma, you have many good points which i agree with. Writing in assembler , even if looks monster and painfull, have it's advantages. I wish i could go back and learn Assembler first.. bah too late ;)
At least, someone's beginning programming in assembler will probably learn better how to use, set-up, the internal PIC ressources... as there's nothing already done. Let's say ADCIN, HSEROUT etc etc. Better hardware understanding.
Also it force the programmer to use it's brain a little bit much. Let's say someone want to compute a multicondition IF THEN ELSE like
Obviously, knowing how many assembler instruction you have, and what's available, he will spend more time to write the code than with any compiler.Code:IF (ByteA<300) AND (ByteC>=ByteA) AND (ByteC+ByteD<127) then...
But both will produce the same result, one will be faster to write.
Better because it's written in assembler? no, 'cause both work. Maybe one may need more codespace... but less time to write.
I will stop here and stick on my opinion. Nothing is better, if the final code/product works as expected and bug-free.
Sure i don't reject any language advantages. You just have to trust the compiler you're using.
If ByteA really is a byte then the first condition will always be true :)Quote:
Originally Posted by mister_e
Not having a dig Steve, just posting something to make the "you have not posted for a while" message go away. LOL
This is an extremely inefficient, code space consuming argument.<hr/>Quote:
Originally Posted by keithdoxey
Here's a better approach that will use much less code space and probably be a lot faster too.<hr/>
Willing to bet this is about 20-30 bytes shorter.Code:IF ByteA<300 THEN
IF ByteC>=ByteA THEN
IF (ByteC+ByteD<127 THEN
'do something
ENDIF
ENDIF
ENDIF
<br/>
Using Select Case is by far the very best methodology for implementing well structured decision making procedures. I'm a little uncertain as to just how advantageous it can be in PBP, but in Visual Basic, it's a god sent!
Consider the following:
<hr/>Code:SELECT CASE UserInput
CASE 1
GOSUB Temperature
LOW LED
CASE 2
GOSUB LightLevel
HIGH LED
END SELECT
Much easier to read and much faster. Select Case is a much more efficient, IF statement equivalent. However they can at times be a bit quirky for certain things.
<br/>
Now consider the following:
<hr/>Code:Select Case JoystickDat.dwXpos
'//
'right?
'//
Case Is > 50000
If Boat_ID <> 2 Then 'sound on condition
If Master_SND_EN Then
If AllowRowSND = 0 And Jumping = False And Allow_SND_Effects = True Then
SND = sndPlaySound(App.Path & "\Water.wav", CSNDaSync)
AllowRowSND = 1 'sound effect once only
End If '
End If
'// '
Rowing_Forward = True 'set flag
Rowing_Backward = False 'set flag
'// '
If Jumping Then '
'lmitied control when airborne '
PlayerX = PlayerX + (PlayerX < 375) * -1 'inc 1 pixel
Boat_ID = 4 'ors out img
Else '
'maintain screen limitations and inc boat forward
PlayerX = PlayerX + (PlayerX < 250) * -(1 + Row_Speed)
Row_Speed = Row_Speed + (Row_Speed < 20) * -2
Boat_ID = 2 'row img
End If
'// '
Else '
'// '
If Jumping Then '
Boat_ID = 4 'ors in img
Else '
Boat_ID = 1 'ors out img
End If '
End If
'//
'joystick center?
'//
Case Is > 500 And JoystickDat.dwXpos < 50000
If Jumping = False Then
If Master_SND_EN Then
If Row_Speed = 5 And Allow_SND_Effects = True Then
SND = sndPlaySound(App.Path & "\Water B.wav", CSNDaSync)
End If
End If
'//
Row_Speed = Row_Speed + (Row_Speed > 0) * 1 'grad dec speed '
'// '
If Rowing_Forward Then '
Boat_ID = Boat_ID + (Boat_ID = 2) * 1 'reset image
Rowing_Forward = False 'flag
AllowRowSND = 0 'en sound for next time
Else '
Boat_ID = Boat_ID + (Boat_ID = 0) * -1 'reset image
AllowRowSND = 0 'en sound
Rowing_Backward = False 'flag
End If
End If
'//
'left?
'//
Case Is < 500
If Boat_ID <> 0 Then 'sound on condition
If Master_SND_EN Then
If AllowRowSND = 0 And Jumping = False And Allow_SND_Effects = True Then
SND = sndPlaySound(App.Path & "\Water.wav", CSNDaSync)
AllowRowSND = 1 'en sound
End If '
End If
'//
Rowing_Backward = True 'set action flag
Rowing_Forward = False 'set flag
'// '
If Jumping = False Then '
PlayerX = PlayerX + (PlayerX > 50) * 10 'inc 10 pixel backward
Row_Speed = Row_Speed + (Row_Speed > 0) * 2 'grad dec speed '
Boat_ID = 0 'row back img
Else
'lmitied control when airborne '
PlayerX = PlayerX + (PlayerX > 50) * 1 '
Boat_ID = 4 'ors out
End If
'//
Else
'//
If Jumping Then
Boat_ID = 4 'ors out img
Else '
Boat_ID = 1 'ors in img
End If
End If
End Select
'//---//
'Y-axis
'//---//
Select Case JoystickDat.dwYpos
'//
'up?
'//
Case Is < 500
If Jumping Then
PlayerY = PlayerY + (PlayerY > 375) * 2 'inc 2
Else
PlayerY = PlayerY + (PlayerY > 375) * 5 'inc 5
End If
'//
'down
'//
Case Is > 50000
If Jumping Then
PlayerY = PlayerY + (PlayerY < 475) * -2 'inc 2 pixel
Else '
PlayerY = PlayerY + (PlayerY < 475) * -5 'inc 5
End If
End Select
Now, while Select Case itself isn't used for all decision making, its main role here is for structure. It greatly improves clarity and organization. It clearly separates the algorithm into much more easily manageable parts. It's perhaps not quite that obvious in this example because there's really on 2 parts in each Select Case.
<br/>
<table><tr><td>http://www.pbpgroup.com/files/dejected.gif</td><td>It wasn't meant to be a 'how to create efficient code' tutorial or contest, but just an example.
Who i'm i anyway ?</td></tr></table>
FYI, in PBP Select Case will be a little less code efficient (talking about code size) than multiple IF-THEN-ELSE... as with ALL other language anyway. Select Case is just easier to read, modify, implement. Save your finger nails...
We are really far of the original question...
Last example:
Procedure taken from a calendar program that I made few months back relies totally on Select Case to do the job. Extremely tidy & extremely fast!Code:Select Case X
Case 5 To 20
Col_Loc = 0
Cur_PosX = 5
Str_Day = "Sunday"
Case 28 To 43
Col_Loc = 1
Cur_PosX = 28
Str_Day = "Monday"
Case 51 To 66
Col_Loc = 2
Cur_PosX = 51
Str_Day = "Tuesday"
Case 74 To 89
Col_Loc = 3
Cur_PosX = 74
Str_Day = "Wednesday"
Case 97 To 112
Col_Loc = 4
Cur_PosX = 97
Str_Day = "Thursday"
Case 120 To 135
Col_Loc = 5
Cur_PosX = 120
Str_Day = "Friday"
Case 143 To 166
Col_Loc = 6
Cur_PosX = 143
Str_Day = "Saturday"
End Select
<br/>
Try making a Nintendo Emulator in VB using IF's as opposed to Select Case. There's about a %25 difference in speed.Quote:
Originally Posted by mister_e
(This procedure is not my code, but I wish it was)Code:Select Case instruction(opcode)
Case INS_JMP: ' jmp6502
adrmode opcode
PC = savepc
Case INS_LDA: ' lda6502
adrmode opcode
a = Read6502(savepc)
SetFlags a
Case INS_LDX:
adrmode (opcode)
x = Read6502(savepc)
SetFlags x
Case INS_LDY
adrmode (opcode)
y = Read6502(savepc)
SetFlags y
Case INS_BNE: bne6502
Case INS_CMP: cmp6502
Case INS_STA
adrmode (opcode)
Write6502 savepc, a
Case INS_BIT: bit6502
Case INS_BVC: bvc6502
Case INS_BEQ: beq6502
Case INS_INY: iny6502
Case INS_BPL: bpl6502
Case INS_DEX: dex6502
Case INS_INC: inc6502
Case INS_DEC: dec6502
Case INS_JSR: jsr6502
Case INS_AND: and6502
Case INS_NOP:
Case INS_BRK: brk6502
Case INS_ADC: adc6502
Case INS_EOR: eor6502
Case INS_ASL: asl6502
Case INS_ASLA: asla6502
Case INS_BCC: bcc6502
Case INS_BCS: bcs6502
Case INS_BMI: bmi6502
Case INS_BVS: bvs6502
Case INS_CLC: p = p And &HFE
Case INS_CLD: p = p And &HF7
Case INS_CLI: p = p And &HFB
Case INS_CLV: p = p And &HBF
Case INS_CPX: cpx6502
Case INS_CPY: cpy6502
Case INS_DEA: dea6502
Case INS_DEY: dey6502
Case INS_INA: ina6502
Case INS_INX: inx6502
Case INS_LSR: lsr6502
Case INS_LSRA: lsra6502
Case INS_ORA
adrmode opcode
a = a Or Read6502(savepc)
SetFlags a
Case INS_PHA: pha6502
Case INS_PHX: phx6502
Case INS_PHP: php6502
Case INS_PHY: phy6502
Case INS_PLA: pla6502
Case INS_PLP: plp6502
Case INS_PLX: plx6502
Case INS_PLY: ply6502
Case INS_ROL: rol6502
Case INS_ROLA: rola6502
Case INS_ROR: ror6502
Case INS_RORA: rora6502
Case INS_RTI: rti6502
Case INS_RTS: rts6502
Case INS_SBC: sbc6502
Case INS_SEC: p = p Or &H1
Case INS_SED: p = p Or &H8
Case INS_SEI: p = p Or &H4
Case INS_STX
adrmode (opcode)
Write6502 savepc, x
Case INS_STY
adrmode (opcode)
Write6502 savepc, y
Case INS_TAX: tax6502
Case INS_TAY: tay6502
Case INS_TXA: txa6502
Case INS_TYA: tya6502
Case INS_TXS: txs6502
Case INS_TSX: tsx6502
Case INS_BRA: bra6502
End Select
Main reason why Select Case is faster than using multiple IF's is because not all conditions are checked, only the first true condition in a Select Case argument has its underlying block of code executed.
That's my theory on it anyway.
unless your using a little bit of your brain, it's true.
V2Code:plah plah plah
Avar=Whatever
Gosub StartSelectCase
plah
plah
plah
'
'
'
StartSelectCase:
If AVar=1 then
Dosomething
Return
Endif
If AVar=2 then
Dosomething
Return
Endif
'
'
'
If AVar=x then
Dosomething
Endif
Return
Sort of what's under the SelectCase hood.Code:AVar = Whatever
StartSelectCase:
If AVar=1 then
Dosomething
Goto EndSelectCase
Endif
If AVar=x then
Dosomething
Goto EndSelectCase
Endif
'
'
'
If AVar=y then
Dosomething
Endif
EndSelectCase:
Now depending how the compiler, language interpret/optimise it, one can be faster than the other. It's hard to tell which will ALWAYS be faster so far as there's millions (and more) different possible itteration/conditions.
Both get the job done! One is easier to read, implement debug.
Pretty sure you'll find that for every IF argument, unlike Select Case, the subject variable to compare with is loaded into a working register each time.
However with Select Case it's already there for the next compare. Possibly the closed analogy of Select Case would be ELSEIF. But it's no where near as flexible unfortunately.
<br/>
Back to the original topic. Here's an interesting MicroChip on-line flash tutorial.
http://techtrain.microchip.com/x14/