Assembler eller C++?

[henkebenke]

Det förutsätter samma mnemonics (svenska?), samma operandordning, samma typ av indirekt adressering osv.
Det enda som får skilja då är väl registren?

[DragonOrb]

Ja, det har du rätt i. EQU listan är till för register.

[sodjan]

EQU har inte ett smack med några "register" att göra !!
Det enda EQU kan göra, är att definiera numeriska *konstanter*.

Tyvärr har många helt missförstått vad EQU faktiskt gör.

(Samma sak gäller CBLOCK, för övrigt).

RES är för att allokera RAM utrymme för register/variabler.

Att använda EQU for att definiera konstanter som sedan
*används* som adresser till register/variabler, är bara klumpigt
och ger kod som är svårare att flytta mellan PIC modeller.
Det blir också väldigt klumpigt att ha generella rutiner som
man använder i flera olika applikationer.

[Greensilver]

Nå, hur _ska_ man göra då? Jag gör nämligen precis så som du skrev att man inte skall göra...

Kod: Markera allt

; Driver settings.
.equ d_RS     	 = 6				; Register select set to pin 6  
.equ d_EN     	 = 7				; Enable set to pin 7   
.equ d_DATA   	 = PORTB			; Display output port set to PORTB
.equ d_CTRL   	 = PORTC			; Display control port set to PORTC
.equ d_CLOCK     = $7F				; Delay setting depending on clock frequency, (8MHz=$FF, 7MHz=$7F)
.equ k_DATA   	 = PORTC			; Keyboard input data set to PORTC (lower nibble)
.equ _BIOS_      = $0060
.equ k_BUFFER 	 = _BIOS_+0			; Keyboard buffer adress in RAM.
.equ PV_H	 	 = _BIOS_+1			; H Process value.
.equ PV_L		 = _BIOS_+2			; L
.equ SV_H		 = _BIOS_+3			; H Setpoint value.
.equ SV_L		 = _BIOS_+4			; L
.equ ER_H		 = _BIOS_+5			; H Error.
.equ ER_L		 = _BIOS_+6			; L
.equ REGCTRL	 = _BIOS_+7			; Regulation control (0 - direction)

.equ P_H		 = _BIOS_+8			; H P gain
.equ P_L		 = _BIOS_+9			; L P gain
.equ P_D		 = _BIOS_+11		; Divisor

.equ I_H		 = _BIOS_+12		; H I gain
.equ I_L		 = _BIOS_+13		; L I gain
.equ I_D		 = _BIOS_+14		; Divisor

.equ D_H		 = _BIOS_+15		; H D gain
.equ D_L		 = _BIOS_+16		; L D gain
.equ D_D		 = _BIOS_+17		; Divisor

.equ INT_H		 = _BIOS_+18		; H Integrator
.equ INT_L		 = _BIOS_+19		; L Integrator

.equ DER_H		 = _BIOS_+20		; H Derivate
.equ DER_L		 = _BIOS_+21		; L Derivate

.equ RESULT		 = _BIOS_+22		; Start location for result (four bytes)

.equ REG		 = _BIOS_+26		; Regulation power (ABS)			 

.equ p_STACKBASE = $0100			; Base adress for data stack (incrementing).

.equ REG_BOOST   = 50

.def WH          = r25
.def WL          = r24
.def CTRL        = r23              ; !!! Dedicated register for flow control. !!!

; Include needed drivers.
.include "D:\Elektronik\Assembler\Drivers\driver_m_maths.asm"
.include "D:\Elektronik\Assembler\Drivers\driver_p_program.asm"
.include "D:\Elektronik\Assembler\Drivers\driver_d_display.asm"
.include "D:\Elektronik\Assembler\Drivers\driver_k_keyboard.asm"

[sodjan]

Det där ser inte ut som MPASM kod, mer som AVR (tror jag)...

[Greensilver]

Jo, visst är det AVR, men principen är väl den samma?

[sodjan]

Personligen har jag ingen aning om det finns en "relocatable mode"
i AVR assembler, så jag kan inte svara på det...

[JJ]

Det där ser inte ut som MPASM kod, mer som AVR (tror jag)...

Tydligare än så kanske inte den nyss diskuterade fördelen med C/C++ visas

[Greensilver]

Ja, men det är ju lite elakt att låta någon som programmerat assembler i två veckor få representera hur värdelös assembler är. (om det var min kod du syftade på)

Det finns visst något sätt att dedikera minne åt variabler men jag har inte fattat hur ännu.

[sodjan]

> Det finns visst något sätt att dedikera minne åt variabler men jag har inte fattat hur ännu.

Som jag skrev förrut, med MPASM direktivet RES, vilket allokerar
RAM minne från den aktuella PIC'en.

[JJ]

Ja, men det är ju lite elakt att låta någon som programmerat assembler i två veckor få representera hur värdelös assembler är. (om det var min kod du syftade på)

Nejnej, vad jag syftade på var att om alla alltid hade använt C så hade det inte spelat någon roll för vilken processor som koden var skriven. (Givet att koden är skriven "portabelt" etc etc för att vara petnoga.)

[sodjan]

Och alla vet ju att det i praktiken knappast går, utom för de
allra enklaste applikationerna, kanske...

EDIT:
Angående EQU vs. RES, se även : http://www.jescab.se/Rellocmode.html

[Icecap]

C- kod som utför icke-hårdvarunära grejor fungerar oberoende på målsystem. Jag har gjort olika beräkningsrutiner (veckodag, veckonummer, skottår, mjukvara IIC) som, utan ändring, fungerar när jag programmerar MikroC (PIC), Softune (Fujitsu) samt HEW (Renesas).

Men det sekund man ska pilla med hårtvaran blir det knasigt, vissa rutiner är skapligt enkla att porta medan andra kan vara svårare pga hårdvaruskillnaderna.

Detta förutsätter såklart att man INTE använder några spacialrutiner som bara finns i ett viss språk, t.ex. PIC-specifika rutiner, man måste helt enkelt hålla sig till ANSI C rakt igenom.

[cykze]

Det behöver inte vara en enkel applikation, tvärtom så ökar fördelarna med att skriva koden i t ex C ju mer kod man har. Ta t ex IP-stacken uIP. Den består av ca 1500 rader C-kod. Det är kod som fungerar att kompilera direkt mot den arkitektur man använder (AVR, PIC, x86 osv.). Därefter hakar man på den arkitekturspecifika kod som alltid behövs för att åstakomma något. Totalt sett blir delen arkitekturspecifik kod försumbar i jämförelse med den totala koden.

Så visst går det att skriva portabel kod. Det går naturligtvis inte att skriva en hel applikation så att den blir portabel, men man kan iaf skriva stora (och små) delar kod så att det blir det.