----- Original Message -----
From: timbox2005 <>
To: <>
Sent: Thursday, November 18, 2004 9:07 AM
Subject: [piclist] Re: Proton Development Suite
>
>
> As the other reply said the Spice model is free but limited to the 6
> development boards included. I have the full system of Labcenters ISIS
> you can do really neat stuff. Like modelling 2 or more pics talking to
> each other and veiwing the timing of the interactions by sending a pin
> high/low on each PIC and then viewing it all on a VSM logic analyser.
>
> When you need to single step all the source on the screen at once,
> (screen does get a little cluttered)
XCSIM allows you to simulate multiple PICs talking to each other and using
XEBOT you can design and build virtual hardware to interact with the PICs
you are simulating. You can embed high level simulation directives directly
into the executable from either XCSB or XCASM and control the simulation
without adding code to your executable (your debug version does not need to
be different to your release version)
>
> I have read with interest the talk about HLL on the list recently. A
> lot of people think that if you have a HLL with procedures and
> functions it is the ultimate system. To me it imposes too many
> restrictions. Below is copy of a post on the forum who agrees with me.
>
> Lastly Proton is highly optimised.
>
> Print "hello" will produce
>
> Movlw 104
> Call Print
> Movlw 101
> Call Print
> Movlw 108
> Call Print
> Call Print
> Movlw 111
> Call Print
>
> Note the repeated call without loading W for the second L
Superficially this looks like a good optimisation but what happens when the
subroutine "Print" is in a different code page to the calling code?
I
downloaded Proton+ lite last night to have a look at the docs. It was
interesting to see that many string functions are not available for the 16
series PICs but only for the 18 series - not a good sign.
The mark of good optimisation is not how few machine code instructions one
high level instruction can be converted into, but how big a sequence of
high level instructions can be reduced to just one machine code instruction.
I have shown on many occations how complex sequences of XCSB statements can
be converted to just one machine code instruction by the XCSB compiler so I
wont waste bandwidth here.
>
> Then Like C if you go over a certain string length it will turn the
> string into a DB file like this:-
> F1_000014 equ $ ; in [OPTERMISATION.BAS] Print "hello great big
world
> out there"
> Movlw high str@lb1
> Movwf TBLPTRLH
> Movlw low str@lb1
> Movwf TBLPTRL
> F@Call print@mstr
> F1_EOF equ $ ; OPTERMISATION.BAS
> ;---------
> ; Null Terminated Strings
>
> ; String hello great big world out there
> str@lb1
> DB
>
104,101,108,108,111,32,103,114,101,97,116,32,98,105,103,32,119,111,114,108
> DB 100,32,111,117,116,32,116,104,101,114,101,0
> ;---------
>
> >From the proton forum
>
> There is an example of why structured languages & systems, which
allow
> for parameter passing, have advantages and disadvantages.
>
> I used to use the BasicX system, which uses an
> almost-VisualBasic-compatible language, i.e. you define Subs and
> Functions, which can receive parameters by value or reference, and
> return results, etc. It is very practical in some ways, but extremely
> cumbersome in others.
Respectfully, I have seen all kinds of rubish produced by people that did
not know what they were doing and who then pointed at it as an example of
"how complex things really are". If you really want to understand the
power
of a programming language you should look at the work of a competant user
with a view to modifying it. The reason so many professionals frown on
(unstructred) BASIC is because many of the programs produced using it end up
being so incredibly difficult to maintain.
>
> Since discovering Proton+, I can say I won't be going back,
specially
> with PDS which now eases navigation through large projects a LOT.
>
> For starters, take a look at this:
>
> Code:
>
> Serin GPS_RX, 16572, 2000, No_SendPos, [Wait("$GPRMC"), Skip 8,
Valid,
> Skip 1, STR Lat\8, Skip 1, LatDir, Skip 2, STR Lon\8, Skip 1, LonDir]
>
> It's a simple GPS NMEA reading operation. The translation into
> structured BasicX code would be something like:
> Code:
>
> Call OpenQueue(InBuffer, 49)
> Call OpenQueue(OutBuffer, 29)
>
> Call DefineCom3(InPin, OutPin, bx0000_1000) ' n,8,1
> Call OpenCom(3, BaudRate, InBuffer, OutBuffer)
>
> Wait_RX:
>
> If StatusQueue(InBuffer) Then
> Call GetQueue(InBuffer, InChar, 1)
> If InChar = 36 Then
> For i = 1 to 4
> Jump
> Next
> Call GetQueue(InBuffer, InChar, 1)
> If InChar <> 67 Then
> Goto Wait_RX
> Else
> Jump
> For i = 1 to 4
> Call GetQueue(InBuffer, InChar, 1)
> Time = Time & Chr(InChar)
> Next
> For i = 1 to 7
> Jump
> Next
> Call GetQueue(InBuffer, InChar, 1)
> If InChar <> 65 Then
> Debug.Print "Invalid"
> Goto Off
> End If
> Jump
> For i = 1 to 9
> Call GetQueue(InBuffer, InChar, 1)
> Lat = Lat & Chr(InChar)
> Next
> Jump
> Call GetQueue(InBuffer, InChar, 1)
> LatDir = Chr(InChar)
> Jump
> Jump
> For i = 1 to 9
> Call GetQueue(InBuffer, InChar, 1)
> Lon = Lon & Chr(InChar)
> Next
> Jump
> Call GetQueue(InBuffer, InChar, 1)
> LonDir = Chr(InChar)
> Jump
> InChar = 0
> sVel = ""
> Do While InChar <> 44
> Call GetQueue(InBuffer, InChar, 1)
> If InChar <> 44 Then
> sVel = sVel & Chr(InChar)
> End If
> Loop
> Call ValueS(sVel, Vel, Dummy)
> Vel = Vel * 1.85
> sVel = CStr(Vel)
> InChar = 0
> Do While InChar <> 46
> Call GetQueue(InBuffer, InChar, 1)
> If InChar <> 46 Then
> Hdg = Hdg & Chr(InChar)
> End If
> Loop
> End If
> Else
> Goto Esperar_RX
> End If
> Else
> Goto Esperar_RX
> End If
>
> Note that this does not include a timeout routine, which is also
> implemented, involving another few lines of code. In this example,
> Jump is a subroutine that pulls n characters from the serial buffer.
> Nice to have a large serial buffer too, but I've learned to live
> without it.
>
> The worst problem with this environment is that you run out of stack
> space very fast, and so you end up writing the same long routines over
> all your code rather than calling them nested, because when you bust
> the stack the uC hangs.
So because you have trouble with one structured language you conclude that
they all have the same limitations?
XCSB has no such stack restrictions. Within it you can call functions to any
depth you like limited only by the amount of available RAM. You can create
many small well behaved well documented functions with meaningful names and
stitch them together in a meaningful easy to follow program without incuring
the overheads of many function calls - you don't need to repeat code you
let
the compiler do all the hard work for you.
Yes you may be able to do things more simply in an unstructured way for
small trivial programs but given that you can do all this using a structured
programming language if you really wanted to, would you not feel more
comfortable knowing that when things get complicated you can simply import
complex sections of code (written by others) WITHOUT impacting on what you
have already written? No worrying about variable name clashes or special
parameter / result passing protocols or RAM or code use. With a programming
language such as Proton+ if you want to control specific hardware in an
efficient optimised way you are either dependent on the compiler writer
adding support for it or you have to write it yourself in assembler. On the
other hard XCSB recently aquired 1-Wire functionality because a user (Colin
Barnard) with no connection to the compiler writer wrote the library to
provide the functionality. And because of the optimisation built into the
compiler, the 1-Wire library is as efficient as if it had been implemented
by the compiler writer!
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
|