PIC12F683 a way to load Dword to an array

[JackB]

Hello everyone,

a simple question, about array in general using a 12F683 since this Pic is not supported for string.

is it possible to load a byte array with a DWord value "4294967295"

array element   0   1   2   3   4   5   6   7   8   9 

value           4   2   9   4   9   6   7   2   9   5


Thanks for any comments.

[Frizie]

If a WORD array (not DWORD) works in a 12F683, then you could split the DWORD first in two WORDS with Variable.LOWWORD and Variable.HIGHWORD.

[trastikata]

Hi Frizie,

I think he meant loading a Byte array with the ASCII values for each digit index in the Dword.

Code Select Expand

Device 12F683     
Declare Xtal = 4

Dim dwTemp As Dword         'Temporary Dword variable
Dim baString[10] As Byte    'Byte array to hold the output string

Main:
    Clear                   'Reset
    dwTemp = 4294967295     'Load some value to dwTemp
    DwordToString(dwTemp)   'Convert dwTemp to string and place it into baString array
End


Proc DwordToString(dwData As dwTemp)
    Dim bCounter As Byte 
    Dim bTemp As Byte
   
    Clear baString                      'Reset baString
    For bCounter = 0 To 9               'Loop through dwData
        bTemp = Dig dwData,bCounter     'Get digit indexed by bCounter
        baString[bCounter] = bTemp + 48 'Load digit value as ASCII code
    Next
EndProc


[trastikata]

If you want to extract only the relevant digits in a umber without running through all 9 array elements, this code could be faster when working with smaller numbers because it will exit the loop when no more relevant digits were to extract.

Code Select Expand

Device 12F683     
Declare Xtal = 4

Dim dwTemp As Dword         'Temporary Dword variable
Dim baString[10] As Byte    'Byte array to hold the output string

Main:
    Clear                   'Reset
    dwTemp = 4294967295     'Load some value to dwTemp
    DwordToString(dwTemp)   'Convert dwTemp to string and place it into baString array
End


Proc DwordToString(dwData As dwTemp)
    Dim bCounter As Byte
    Dim bTemp As Byte
   
    Clear baString                      'Reset baString
    bCounter = 0                        'Reset bCounter
    While dwData > 0                    'Extract only relevant digits
        bTemp = dwData // 10
        baString[bCounter] = bTemp + 48
        dwData = dwData / 10
        Inc bCounter 
    Wend
EndProc


[JackB]

Hello trastikata,

you realy help me with this function, I read about function about 35 years ago
with VB and did not catch the real potential.

I understand somehow the effect/result of it.

with time on my side I'll start learning about function.

I recal with VB, it had Sub Private & Sub Public function, I guess with Positron it use Private for now.

Many thanks

[Stephen Moss]

I recal with VB, it had Sub Private & Sub Public function, I guess with Positron it use Private for now.

Technically, there is no method within Positorn to declare either a Subroutine or a Proceedure as being either Public or Private. However, if you wanted to draw and equivalence to VB's Public and Private subs then...

Proceedures = VB Private Sub:
This is becuse generally any constant or variable declared within a Proceedure is only Locally (Private) accessible to that proceedure.
That said, it is possible to declare Global (Public) variables and constants within a proceedure if you remember to preceed it with the Global keyword, i.e...

Dim X as byte         'Declare a Local (Private) variable within a proceedure
Global Dim Y as Byte  'Declare a Global (Public) variable within a proceedure

but as that is something you could easily forget it is best to think of a Proceedure a being like a VB Private Sub.

Standard Subroutine = VB Public Sub:
This is bacause to my knowledge (and I may be wrong here) variables/constants declared within them would be Global (Public) regardless of whether or not you use the old school version of defining a subroutine (LableName: - Return) or the more Proceedure like Sub - EndSub.

[JackB]

Thanks Stephen, for your knowledge
I'll set a schedule to practice with theses.

[John Drew]

Local variables declared in a sub routine are both private to a subroutine and public if you are aware of their naming methodology.

When used as intended they should always be treated as local.

To understand what's going on you need to see the naming strategy.
When you declare a local variable e.g "dim Jack as byte" in a procedure called "Fred" the name becomes "Fred.Jack"

While inside the procedure the "Fred" is assumed. I.e it appears to be private. And you can use "dim Fred as byte" elsewhere in the program either as a global or as a local in another procedure when a different procedure name can be subtended.

I don't know but suspect the global command in e.g. Dim  Jack as a global prevents the addition of the procedure name.

However if you use "Fred.Jack" from outside the procedure. It is public.

So in large computers with large amounts of stack, local variables can be created on the stack and the stack re-used on exit from the procedure. This is not good use of the stack in a PIC where there is very limited space.

Les has worked a solution dictated by the limitations of the hardware and the needs of we users. Very clever.

I'm working off memory so the dot separator as suggested above may be incorrect but the principle is right. I have tested it in the past.

I hope this helps in our understanding of what's under the hood of our favourite compiler.
John