RoboEmu & RoboGUI

[Raven_Writer]

Would anyone like to see these two programs re-wrote to work with the new PIC-C language?

If so, I'd be glad to re-write them.

Please post your thoughts, opinions, etc....

[djcapelis]

If you could please try and keep the cross platform (or at least dual-platform) nature of these applications it'd be much appreciated, I'll run code on linux for you if you don't have an installation free to test upon. Might end up helping fix a few things too, assuming it's open-source? (if you're using rob's code as a base open-source is not optional.)

[Raven_Writer]

Originally posted by djcapelis
If you could please try and keep the cross platform (or at least dual-platform) nature of these applications it'd be much appreciated, I'll run code on linux for you if you don't have an installation free to test upon. Might end up helping fix a few things too, assuming it's open-source? (if you're using rob's code as a base open-source is not optional.)
Keeping it cross platform is something I doubt I can do....I've looked through the code, and if both (or even if one) runs on linux right now, I highly doubt it'll matter when/if I re-write the code.

Both will be off of Rob's code, I'm just going to make the necessary changes for the language. This way, people that are used to how it was will still be able to use it....unless I end up having to re-do everything (dreads that).

Thanks for help, I'll keep in touch with you as soon as I get more info on the language.

[miketwalker]

I'd be more than glad to try to help as well if you need it.

[Rickertsen2]

YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! YES!! ...............

I was going to post this myself, but you beat me 2 it. I wish there were some way i could help.

[Raven_Writer]

Mike & Rick: You both can help with cross-platform stuff, and I'm sure I'll IM you both about the code ;)

Thanks for all the help, and I'm glad many people really do like these programs.

[Sorry if I sound like Rob, I'm just really suprised honestly that these tools have helped out a lot of people]

/ponders what Rob would post if he read this thread

[rbayer]

Originally posted by Raven_Writer

/ponders what Rob would post if he read this thread [/B]

Don't worry, I'm here.

As of right now, I am planning on updating at least RoboEmu (RoboGUI is a mess right now, and I don't think it's anywhere near as popular). As for cross-platform compatibility, that's definately in the plans.

A few problems:
a) RoboEmu will basically need to be gutted and re-written from the ground up.
b) I'm not on a team and have no controller to test things with.
c) I haven't seen a formal spec for the language yet. (Please don't say implement all of C. That's about the same as writing a C compiler, which is a HUGE project and one that I doubt anyone here has the time to take on).


So, that said, here's what I need from you guys:
1. can somebody find me the language spec?
2. are you all willing to test code for me?
3. please be patient. I love working on RoboEmu, but this a gigantic change. Luckily, version 2.0, which I almost finished this summer, should be easier to adapt to the new controller and will be much easier to keep cross-platform compatible.
4. even though RoboEmu is GPL, so you are technically free to do whatever you want with it, I think it would be benneficial to coordinate everything through me so that somebody doesn't end up duplicating work I've already done.

Remember, competition doesn't start until January. I will definately try to have something done significantly before that.

-Rob

[Raven_Writer]

Originally posted by rbayer
...So, that said, here's what I need from you guys:
1. can somebody find me the language spec?
2. are you all willing to test code for me?
3. please be patient. I love working on RoboEmu, but this a gigantic change. Luckily, version 2.0, which I almost finished this summer, should be easier to adapt to the new controller and will be much easier to keep cross-platform compatible.
4. even though RoboEmu is GPL, so you are technically free to do whatever you want with it, I think it would be benneficial to coordinate everything through me so that somebody doesn't end up duplicating work I've already done. ...
1. I've been looking through the website for a while, w/ no luck, but I'll still try
2. I would be more than willing to test it

Thanks Rob for the great work.

[miketwalker]

Yea, I haven't found out about the code either, I hope that something comes with the new edubot controller that will give us just the basics if anything.

I'll definitly help beta test as well

[FotoPlasma]

Originally posted by rbayer
1. can somebody find me the language spec?

-Rob
If we're to be using MPLAB to program a PIC18F8520 in C, I'm almost 100% sure we'll be using C18 (http://www.microchip.com/1010/pline/tools/picmicro/code/mplab18/index.htm). The User's Guide (http://www.microchip.com/download/tools/picmicro/code/mplab18/51288b.pdf) document on that page contains a lot of the spec of the language (I'm not sure if it's 100% complete, but it seems to be very comprehensive), and the Libraries (http://www.microchip.com/download/tools/picmicro/code/mplab18/51297b.pdf) document explains Microchip's libraries for common processor functions (ADC, Timers, PWM, USART, etc.).

Hope this helps, some. I'm not sure what, if anything, I'll be able to do concerning the actual development of the software, though. Sorry.

[Dave Flowerday]

Originally posted by rbayer
c) I haven't seen a formal spec for the language yet. (Please don't say implement all of C. That's about the same as writing a C compiler, which is a HUGE project and one that I doubt anyone here has the time to take on).
Rob,
Why try to interpret the C code as it runs? As you say, implementing all of the language constructs would be a lot of work. It would be much more efficient to just compile the user's RC code into a native library on the host's workstation and then link it in at runtime... I would think that would simplify the porting of your application quite a bit. Most likely IFI will provide some sort of library for the RC that will have some standard functions for reading inputs, writing outputs, setting PWMs, etc., so all you'd have to do is provide the same interface for the user's code to work with.

Besides, it'll be much harder to interpret programs written for the new processor and maintain real-time speed than it was with the pokey BASIC Stamp.

[Rickertsen2]

Originally posted by Dave Flowerday
Rob,
Why try to interpret the C code as it runs? As you say, implementing all of the language constructs would be a lot of work. It would be much more efficient to just compile the user's RC code into a native library on the host's workstation and then link it in at runtime... I would think that would simplify the porting of your application quite a bit. Most likely IFI will provide some sort of library for the RC that will have some standard functions for reading inputs, writing outputs, setting PWMs, etc., so all you'd have to do is provide the same interface for the user's code to work with.

Besides, it'll be much harder to interpret programs written for the new processor and maintain real-time speed than it was with the pokey BASIC Stamp.

Hmm if that can be done, then all you would need to write would be an assembly interpreter. The PIC instruction set is very small.

And rob, don't worry about testing. I think people are quite eager to test. The full details im guessing will be out around the 10th.

[Dave Flowerday]

Originally posted by Rickertsen2
Hmm if that can be done, then all you would need to write would be an assembly interpreter. The PIC instruction set is very small.
No, you wouldn't. The point is that you compile and run it natively on the [Windows|Linux|MacOS] platform. No interpretation of C, assembly, or anything else.

[djcapelis]

Sweet... if IFI releases said library... we'll have to see a bit before anything can really happen.

I need to learn to be more patient.

[Raven_Writer]

Originally posted by djcapelis
Sweet... if IFI releases said library... we'll have to see a bit before anything can really happen.

I need to learn to be more patient.
lol.

If I get enough info., I might be able to re-write my FIRST Editor to use the PIC-C language.

[Rickertsen2]

Originally posted by Dave Flowerday
No, you wouldn't. The point is that you compile and run it natively on the [Windows|Linux|MacOS] platform. No interpretation of C, assembly, or anything else.

OOO i get you now.... That would be even better, but has more inherent difficulties than you may think.
IMHO it would probably be better to write an interpreter for .asm files that have already been compiled. Let me just say no matter how it is done, this will be no easy feat.

[djcapelis]

Eh, an ASM intepreter doesn't seem all that bad... only 26 instructions to implement and you've got the entire capabilities of the mc pretty much dealt with.

[Rickertsen2]

Originally posted by djcapelis
Eh, an ASM intepreter doesn't seem all that bad... only 26 instructions to implement and you've got the entire capabilities of the mc pretty much dealt with.

i guess. But you also have model the effects of all the registers. Still a far less daunting task then a C interpreter.

[jmcglash]

If you realy want to simulate the pic you should take a look at gpsim from the gnupic project.

http://www.dattalo.com/gnupic/gpsim.html

It should make Rob's job a lot easier.

[Rickertsen2]

oh yea i forgot all about gpsim.

[Dave Flowerday]

Originally posted by Rickertsen2
That would be even better, but has more inherent difficulties than you may think.
Please elaborate on what you believe these difficulties may be.

This sort of thing is done all the time in the embedded software world. It is essentially the equivalent of porting code from one processor/board to another, which is one of the advantages of using a higher-level language like C.

[Rickertsen2]

I am no expert on the subject, so correct me if i am wron but it is my understanding that it would be quite hard to make PIC asm run on an x86 protected mode architecture while running windows/linux at the same time. The x86 architecture is soo entirely different from PICs. How would that work? It just seems alot easier t ome to emulate a pic just like rob did with the Basic Stamp. I can uinderstand maybie porting from for examply HC11 to PIC but to x86? Maybie im misunderstandin or missing something here but thats my $.02 Besides when you already have something like gpsim to work off of why bother?


[edit] Wait scratch all of that.... I see what you are saying now. Compile the C code to run on x86. I for some reason thought that you meant try to convert PIC asm to x86 asm. I see now. (feels liek idiot) {/edit}:eek:

[Dave Flowerday]

Originally posted by Rickertsen2
I am no expert on the subject, so correct me if i am wron but it is my understanding that it would be quite hard to make PIC asm run on an x86 protected mode architecture while running windows/linux at the same time.
You're missing the point. The idea is you would take the C code you wrote for your robot, and compile it with an x86 compiler. The result would be x86 assembly, which would be assembled into an x86 binary. This binary would be linked in (.dll or whatever) to RoboEmu at runtime. There is no PIC assembly involved here at all. No simulator to write or anything. All RoboEmu would have to do is provide the necessary symbols (functions and variables) for your RC code to link against that would otherwise be provided by the (theoretical) IFI libraries.

[Rickertsen2]

Originally posted by Dave Flowerday
You're missing the point. The idea is you would take the C code you wrote for your robot, and compile it with an x86 compiler. The result would be x86 assembly, which would be assembled into an x86 binary. This binary would be linked in (.dll or whatever) to RoboEmu at runtime. There is no PIC assembly involved here at all. No simulator to write or anything. All RoboEmu would have to do is provide the necessary symbols (functions and variables) for your RC code to link against that would otherwise be provided by the (theoretical) IFI libraries.

If you read the end of my post you would have realized that i finally figured that out.:)
or maybie you just replied bofore i added the "edit"

[Dave Flowerday]

Originally posted by Rickertsen2
[edit] Wait scratch all of that.... I see what you are saying now. Compile the C code to run on x86. I for some reason thought that you meant try to convert PIC asm to x86 asm. I see now. (feels liek idiot) {/edit}:eek:
No problem... it's easy to overlook the fact that C code should be able to be compiled and run on any target, as long as all the necessary functions are provided.

[Adam Y.]

I thought MPLAB allowed for limited simulation of codes. I guess I really should reinstall it.

[rbayer]

As a quick fix, I have definately already considered doing the compile for x86 thing. It would make life SO easy. However, this would imply that people would have a C compiler on hand and that they would be able to re-compile every time they want to test new code. Personally, this sounds tedious to me. On the other hand, it's probably the easiest solution.

[miketwalker]

Originally posted by rbayer
As a quick fix, I have definately already considered doing the compile for x86 thing. It would make life SO easy. However, this would imply that people would have a C compiler on hand and that they would be able to re-compile every time they want to test new code. Personally, this sounds tedious to me. On the other hand, it's probably the easiest solution.

Well, I think that would be the best thing to do... just cause of the time you will save, and January isn't too awful far away. I think you could just write up a simple tutorial, and package it all together. It shouldn't take too much longer either though. So I say go with it to save time. Just my $.02

[Dave Flowerday]

Originally posted by rbayer
As a quick fix, I have definately already considered doing the compile for x86 thing. It would make life SO easy. However, this would imply that people would have a C compiler on hand and that they would be able to re-compile every time they want to test new code. Personally, this sounds tedious to me. On the other hand, it's probably the easiest solution.
If it's possible, maybe you could use gcc. That way you could include the compiler as part of the package. And as far as having to recompile it every time, you could probably have your GUI do it automatically, so when someone opens their C file it automatically compiles it into a library. The RC code should be simple enough that it should compile in a matter of seconds.

[Raven_Writer]

Originally posted by Dave Flowerday
If it's possible, maybe you could use gcc. That way you could include the compiler as part of the package. And as far as having to recompile it every time, you could probably have your GUI do it automatically, so when someone opens their C file it automatically compiles it into a library. The RC code should be simple enough that it should compile in a matter of seconds.
The thing is that you'll need a linker, and a compiler at least. But that is a good idea. I'm sure there's a way to pass parameters to the program through calls or some sort like that.

[rbayer]

Originally posted by Dave Flowerday
If it's possible, maybe you could use gcc. That way you could include the compiler as part of the package. And as far as having to recompile it every time, you could probably have your GUI do it automatically, so when someone opens their C file it automatically compiles it into a library. The RC code should be simple enough that it should compile in a matter of seconds.

Hmmm... intriguing. I definately like the idea, and it would be really easy to do as just a .bat file. The only issue I have is that gcc is freaking HUGE and its availability for Windows is sketchy at best (Cygwin can be a complete pain). Anyone know of any smaller compilers?

[Dave Flowerday]

Originally posted by rbayer
The only issue I have is that gcc is freaking HUGE and its availability for Windows is sketchy at best (Cygwin can be a complete pain). Anyone know of any smaller compilers?
I'm not sure of all the libraries that you'd need to accompany gcc, but:

gcc.exe 86k
cygwin1.dll 948k
libc.a (stripped) 416k
libm.a (stripped) 113k

Depending on how much else would be needed for a functional gcc environment, that's about 1.5M, which isn't too bad...

[FotoPlasma]

Two other free win32 C compilers are lcc (http://www.cs.virginia.edu/~lcc-win32/) and djgpp (http://www.delorie.com/djgpp/).

Hope this helps a little.

[Dave...]

Sounds great; let me know when its ready.

[WizardOfAz]

Originally posted by Adam Y.
I thought MPLAB allowed for limited simulation of codes. I guess I really should reinstall it.

I have been unable to find much interaction about the MPLAB simulation features but I'm starting to try to grokk it. Anybody know much about it? Anybody care to contrast it with RoboEmu?

For the record, RoboEmu was a fantastic tool for our team last year. We were a budget constrained first year team, so without RoboEmu we would have had only one way to run programs.

THANK YOU ROB!

[Mercutio]

that would make me VERY HAPPY!!!!!

The other programmer on my team decided to take the Edu controller home until he knows C -- which could take a while, since he seems to program entirely by trial and error. :rolleyes: So, I have no way to get used to the new chip except writing a bunch of test programs, giving them to him, and hoping he runs them and gives me back the results. Talk about tedious.

Even if the new RoboEmu can't simulate the EduBot, it will still be very useful. Thank you so much!!!!! :D

~Aaron

P.S. Another nice C++ compiler is MinGW (http://www.mingw.org/index.shtml). I don't know if it fits your needs, but I got it with Dev C++ and I like it a lot!

[Anthony Kesich]

Yes, minGW is quite nice. It works very well with Dev C++, which i would also recomend to anyone who wants a C/C++ compiler. Its free, open-source, colorcoded, and looks good. Plus it has power to boot.

P.S.Doesn't it also come with GCC for C compiling?

[Raven_Writer]

Yes, minGW is quite nice. It works very well with Dev C++, which i would also recomend to anyone who wants a C/C++ compiler. Its free, open-source, colorcoded, and looks good. Plus it has power to boot.

P.S.Doesn't it also come with GCC for C compiling?Yes, GCC comes with it. But there's some trouble w/ both of them (I forgot what it was though).

Almost (I THINK) every (C/++) compiler out there has syntax highlighting (color corded).

[Mercutio]

Almost (I THINK) every (C/++) compiler out there has syntax highlighting (color corded).

Most IDEs have syntax highlighting. Most compilers don't. ;)

[Raven_Writer]

Most IDEs have syntax highlighting. Most compilers don't. ;)Woops..sorry :) I was really sick yesterday, so I wasn't really sure what I was really saying.

[LBK Rules]

Ok, I think I am lost. If you are talking about recompiling the emu for each program, I think that would be a little overkill. (If that's the case, please use Dev-C++ (http://www.bloodshed.net/))

How hard would it be to creat an emulator for the HEX files that are downloaded to the RC?

[Raven_Writer]

Ok, I think I am lost. If you are talking about recompiling the emu for each program, I think that would be a little overkill. (If that's the case, please use Dev-C++ (http://www.bloodshed.net/))

How hard would it be to creat an emulator for the HEX files that are downloaded to the RC?That was my point...but since Rob is already working on it, I decided to drop the project idea.

As for the emulation for HEX files, it might be difficult. You'd need the file specs I think. Anywho, the specs for .hex files aren't out, I don't think. If anyone can prove me wrong, please...because I'd love to see the specs for the format.

[Jay Lundy]

That was my point...but since Rob is already working on it, I decided to drop the project idea.

As for the emulation for HEX files, it might be difficult. You'd need the file specs I think. Anywho, the specs for .hex files aren't out, I don't think. If anyone can prove me wrong, please...because I'd love to see the specs for the format. Here is a document on the HEX format:

http://www.microchip.com/download/appnote/devspec/16cxx/91026a.pdf

It's for the C16 but it should still apply to the C18.

Also try searching google for "INHX32" or "INHX8M."

[Raven_Writer]

Here is a document on the HEX format:

http://www.microchip.com/download/appnote/devspec/16cxx/91026a.pdf

It's for the C16 but it should still apply to the C18.

Also try searching google for "INHX32" or "INHX8M." Thank you. That is pretty useful for it.

Wouldn't Robo* have to have an emulator for the HEX file anyways though?

[randomperson]

Hmm... a emulator for the new PIC controller... now that would be awesome.

[rbayer]

Wouldn't Robo* have to have an emulator for the HEX file anyways though?

Nope. As of right now, the plan is to use gcc to compile the user's C code into a DLL (or .o for linux) which RoboEmu will load at runtime. The vast majority of the default code isn't needed for RoboEmu, and trying to sort it out of the hex file would be rather difficult and overly complex.

[mtrawls]

I don't want to seem impatient on ungrateful ... but might I inquire as to how the progress is going on RoboEmu? It's an invaluable piece of software, so if there is anything you need help on (coding, or more likely testing), I'd be willing to contribute. Seeing as the season is about to start, it would be nice to have this.

*crosses fingers that it is done already:)*

[rbayer]

Well.... ummmm... not so well. I've been REALLY busy lately and really haven't had any time to work on it. Also, just thinking about doing interrupts scares the living daylights out of me.

[rwaliany]

I'm not sure I understand why you would compile it then load it in RoboEDU. If, I was doing it in Linux, I would copy the new modified source code to the directory, send a make command, have the Makefile use a different file than main.c to load it's own void main, then compile, the ACTUAL RoboEDU GUI program would be in that source code. Then, when it's done compiling, I would run an exec command to reload the application on the fly with the new source code embedded into the RoboEDU GUI. From int main, I would send it sample runs. You can pass all the window parameters etc via command line, execl("filename", "para1", "para2", "para3", etc..., (char *)null); I do this for my online C server game, so I never have to kick players off during reboots. Also for windows, you could use freecommandlinetools.exe for the compiler, search google, but I'm not sure if you can reload applications on the fly while their running reload the executable.

[Skabana159]

I don't blame you, Rob, interrupts are scary in and of themselves, much less emulating them on an x86.

[rbayer]

Alright, I started working on it a bit last night and made a lot of progress. I still need to finish doctoring up the default code (#ifdefs like whoa), but everything's coming together quite nicely. Over the summer, in anticipation of a possible change of language, I spent several weeks putting all the PBASIC-specific stuff into a DLL. Thus, all that really needs to be done is finish up creating the new, C-specific DLL. The changes to the UI code should be truly minimal. Also, since the UI code hasn't really changed since version 1.07, a Linux port should follow shortly after the Windows version is done.

For those interested, here's the basic "zen" of RE2:

-The same familiar, clunky, bright green interface is back. Unless something is drastically different about the new controller, don't expect this to change any time soon. I hate writing UI-code, and right now functionality is much more important than visual appeal. Eventually, I'm going to sit down and learn Qt so I can unify the Windows and Linux source code, but that's a project for farther down the road.

-The default code from InnovationFirst is currently in the process of being doctored up with more #ifdefs than I care to count. Basically, if RoboEmu is the one compiling it, it will use RoboEmu's versions of GetData, PutData, EEPROM functions, etc. If it's the normal C18 compiler, it will compile as if it's the original file from InnovationFirst.

-A makefile (for now, only for VC++, gcc version coming soon) will be provided that will compile your custom code (from user_routines.c) along with some RoboEmu specific code into a DLL that exports various symbols, such as Process_Data_From_Master_uP(), etc

-The DLL will be loaded by RoboEmu at runtime and will be used to actually emulate your code.


Stuff for the future:
Interrupts(hopefully). I have some ideas, but their untested, and as of right now, they're fairly low-priority (no pun intended).


Anyways, I'm not even going to try to guess at a possible initial release date, but it should be sometime soon, hopefully before kickoff.

-Rob

[jerry w]

very glad to see that work is continuing on the emulator.
it was indispensible to team-79 last year.
i like the clunky green color.
i will do any beta testing or other tasks that i can do. (C is not my favorite language)
put me on the list of ones who want to help.

Jerry Waechter

[rwaliany]

Wait...what's the point of this. MPLAB comes with a pretty HEFTY debugger which you can simulate the PIC with.

To enable the debugger, compile your code. Then click Debugger -> Select Tool -> MPLAB SIM -> Then you will now be able to run your code under the MPLAB Simulator... Why recreate what is already there? If you're going to make RoboEDU for the PIC, why not use MPLAB SIM. That should make it a lot easier.

To view variables, etc... go to view disassembly, hardware stack, program memory, EEPROM, watch, special function registers, etc...stop and run as you want, pause the program, whatever you want.

It's really nice, I was using it for our autonomous blimp project using another PIC. I just tested it and it works with our current robot controller.

Thanks,
Ryan Waliany

[Vladimir]

Wait...what's the point of this. MPLAB comes with a pretty HEFTY debugger which you can simulate the PIC with.
.....


Correct me if I am missing something, but the MPLAB sim does not simulate radio communication with our code, so RoboEMU allows us to simulate the program running as it would in a "real" environment, attached to controls and motors, so we can test inputs/output. It's also graphical and easy.

Rob: Your RoboEMU was invaluable to me last year. I doubt my team would like me taking the $1200 RC/OI home to work on programming, RoboEMU let me develop a lot of things and come in next day with a magic disk and make everyone happy :D I am fluent in C and am willing to help develop/test the new version in any way I can, just let me know.

-Sean

[rwaliany]

It should, you can "inject" all variables and set them. I think you can just set the radio control variables, I'm not sure. I stopped using Windows to program when I got the IFI Loader for Linux working. It takes some getting use to. The variables you want to set/access just have to be global.