Thank you

no that should not be an issue. and the length is not important as well.
i would prefix a global van with g and a local with l(L)
when you assign a variable in a sub/function the compiler will first check if it is a passed parameter or a local variable. in that case it will assign it.
only when not found it will check to see if it is global.

so there should not be any issue. if there is send me a sample

Hello guys,
teoretical question. I found somwhere on this forum that naming locals same name in different subs or functions can cause problems. Is it really an issue? Since then I started to prefix every local variable after first characters of sub or function name. But it gives sometimes quite long names for that varibles. Does it affect speed of operation with manipulating variables? Thanks for further explanation.


[code:1:a80a025b6e]
function Motor_config_mode() as byte
Local Mcm_tempvar_b As Byte
Local Mcm_tempvar_b2 As Byte
Local Mcm_result As Word
Local Mcm_phase As Byte
'more code here
end function
[/code:1:a80a025b6e]

[b:a80a025b6e][color=red:a80a025b6e](BASCOM-AVR version : 2.0.8.6 )[/b:a80a025b6e][/color:a80a025b6e]

Thank you both for replying. The second solution worked out for me, thanks again.

Hi O-Family

Passing the data is not a real problem. But the operations on the data require an additional register. And if i remember correct, they are used up.
But i will see what is most efficient. Thanks for your thoughts. I will contact you separately later.

The ones from EDC will not work since they are not compatible.
you need to use the EMBUD drivers.
in windows you need to disable driver enforcement so you can install the drivers. look on this forum or google for driver enforcement under win10.

Hi, Mark

I also thought that we needed to make the 2-byte passing compatible, so I looked for a way to do it.

For example, if you could pass 16-bit parameters using word variables such as {___GlcdX1}, {___GlcdX2}, {___GlcdY1}, {___GlcdY2}, , and in addition to the current Y pointer passing, it would be easy to choose whether to use 8-bit Y pointer data on the library side or 16-bit data in the new variable.

It might also be possible to extend the currently used , , , and variables.

, {___lcdrow+1}, {___lcdrow2}, {___lcdrow2+1} --- , {___FGCOLOR+1}, etc.

If I remmember right then EMBUD was such a AVR ISP MKII.
Then, if you don want to download whole Microchip Studio then you need driver-bundle.

After quick search i found it here -> [url=https://www.microchip.com/en-us/search?searchQuery=drivers%20bundle&category=ALL&fq=start%3D0%26rows%3D10]LINK

Download for example "driver ATmel bundle 7.0.888"

After installation sear for program Zadig-2.9 because it is the quickest way to add filter and replace driver to libusbK(3.1.0.0)
Run program with admin rights and go to "Options->List all devices". Now search for AVR ISP and replace driver to libusbK.
Then everything should work wit Bascom.

hello O-Family

As usual a great contribution from you.
Thanks for sharing. I did not see this LCD yet but it is good to know it exists for future projects.

About restriction of byte vs word. Yes that is also still on my todo list. But as you understand it need to do it so the existing libs remain compatible.

Hi.
I came back to Bascom after along time of absence due to a required update to one of my projects. Using the latest version (2.0.8.6) I tried to install the driver for the EMBUD USB-ISP programmer but windows says something about corrupt files or something and does not go thru with the instalaltion. As a result Bascom says "USB programmer not found".
I have Win 10 64 bit installed. Are these drivers suitable for this version ?


[b:188fd77862][color=red:188fd77862](BASCOM-AVR version : 2.0.8.6 )[/b:188fd77862][/color:188fd77862]