Post by thread:[PIC]: Flag auto-allocation macros?

Hi, Has anyone written any MPASM macros that automatically allocate memory for single-bit flag variables? I was going to write some myself (or at least attempt it), but if it's already been done... Thanks. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, spam_OUTphilpemTakeThisOuTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... I am. Therefore, I think. I think.

Philip Pemberton <.....philpemKILLspam@spam@dsl.pipex.com> wrote: > Has anyone written any MPASM macros that automatically allocate memory > for single-bit flag variables? I was going to write some myself (or at > least attempt it), but if it's already been done... It isn't done as pure macros, but Olin's PREPIC processor handles this function very nicely. See: http://www.embedinc.com/pic/ -- Dave Tweed

>Has anyone written any MPASM macros that automatically >allocate memory for single-bit flag variables? I was >going to write some myself (or at least >attempt it), but if it's already been done... Look at Olins development environment. It uses a pre-processor to do this very nicely, and generates macros for each flag. It does it for both flags in memory, and I/O port bits.

In message <E1DfJvH-0000px-00KILLspampop-satin.atl.sa.earthlink.net>> Dave Tweed <.....picKILLspam.....dtweed.com> wrote: > It isn't done as pure macros, but Olin's PREPIC processor handles this > function very nicely. See: > > http://www.embedinc.com/pic/ I've been looking at that. AFAICT, it can't be integrated into MPLAB though, which is a shame. Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, EraseMEphilpemspam_OUTTakeThisOuTphilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... A single fact can spoil a good argument.

Philip Pemberton wrote: > Has anyone written any MPASM macros that automatically allocate memory > for single-bit flag variables? Sortof. This is built into my MPASM preprocessor as the /FLAG directive. I couldn't do this with native MPASM macros due to its inability to take string arguments and merge them together to make new symbols. The preprocessor is called PREPIC, and is available for free at http://www.embedinc.com/pic. I think the documentation file is also available there without having to download and install the whole development environment. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

Philip Pemberton wrote: > I've been looking at that. AFAICT, it can't be integrated into MPLAB > though, which is a shame. I wouldn't know since I always build externally from MPLAB, and use MPLAB only for debugging. Can't you specify an arbitrary command line or script for building source modules in MPLAB? I would expect this from any reasonable build system, but I've never looked at that capability in MPLAB. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

Philip Pemberton <philpemspam_OUTdsl.pipex.com> wrote: > Dave Tweed <@spam@picKILLspamdtweed.com> wrote: > > It isn't done as pure macros, but Olin's PREPIC processor handles this > > function very nicely. See: > > > > http://www.embedinc.com/pic/ > > I've been looking at that. AFAICT, it can't be integrated into MPLAB though, > which is a shame. It integrates just fine with the command-line tools that are part of MPLAB. I use Emacs+Viper for all my editing and "make" for all my building. I've posted my "generic" MPLAB-compatible Makefile before. I only use IDEs for debugging. I've never understood the attraction of using an IDE for editing code and building software. -- Dave Tweed

In message <KILLspamE1DfMjL-0002XV-00KILLspampop-tawny.atl.sa.earthlink.net>> Dave Tweed <RemoveMEpicTakeThisOuTdtweed.com> wrote: > I only use IDEs for > debugging. I've never understood the attraction of using an IDE for editing > code and building software. The big problem is the ICD2 - as far as I can tell, MPLAB is the only software that can drive it. If there was a simple command-line program-only driver (like Xwisp or Easyprog) then I'd hack together a batchfile and use that. The compile/load into mplab/program/hit run/repeat cycle gets rather boring after a while. It's easier just to have everything built into mplab, hit F10 and have the code compiled and linked and the chip programmed, all in one go... "But all I wanted was DBANKIF and /FLAG..." Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, spamBeGonephilpemspamBeGonephilpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... I'm too sceptical to deny the possibility of anything

> Sortof. This is built into my MPASM preprocessor as the > /FLAG directive. I > couldn't do this with native MPASM macros due to its inability to take > string arguments and merge them together to make new symbols. I recall that this is possible, though cumbersome. This is snipped from my WISP firmware (the Wisp628 predecessor) ; retrieve what has been defined by port_define #define port_port(x) x#v(0)_port #define port_bit(a_x) a_x#v(0)_bit #define port_polarity(a_x) a_x#v(0)_pol #define port_direction(x) x#v(0)_dir #define port_name(a_port,a_bit) port#v(a_port)bit#v(a_bit)n IIRC the # operator does merge names, but only when followed by a v() construct. Don't take this as an advice to use this, just for the record: it *is* possible. If you want to see some realy unreadable macro stuff you should check this WISP firmware. IIRC I even experimented with macro's that have different expansions during assembly phase one and phase two. juk! Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Philip Pemberton wrote: > The big problem is the ICD2 - as far as I can tell, MPLAB is the only > software that can drive it. If there was a simple command-line > program-only driver (like Xwisp or Easyprog) then I'd hack together a > batchfile and use that. But what would that do for you? You still need to be in MPLAB to debug. That's one of the things an IDE *is* good for. If you just want to program without debugging, why does speed matter that much since you're not going to be doing that every minute. In fact even for debugging, I spend much more of my time in the debugger or in the editor compared to building code and bringing up MPLAB. You just don't find a bug in 10 seconds, fix it in 10 seconds and do that all over again several times in a row. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

I agree with you that most of the people would like to do everything in one IDE even though some power users would like to do editing and building in their preferred environment and do the rest (which can not be done in their preferred tools) in the IDE. MPLAB 6 and later are decent tool for editing and building. MPLAB 5 and old versions are bad enough to justify using other editors. For command line tools to drive ICD2, take a look at LPLAB http://www.landamore.com/pic.html. It is not fully working yet though. Xiaofan {Original Message removed}

> > The big problem is the ICD2 - as far as I can tell, MPLAB > is the only > > software that can drive it. If there was a simple command-line > > program-only driver (like Xwisp or Easyprog) then I'd hack > together a > > batchfile and use that. > > But what would that do for you? You still need to be in > MPLAB to debug. > That's one of the things an IDE *is* good for. If you just > want to program > without debugging, why does speed matter that much since > you're not going to > be doing that every minute. I think you have a too limited view of debugging-or-production. I often do debugging without using ICD-like features, just by observing the target's behaviour, serial feedback etc. OTOH I do small-scale production, in most cases driven by a PC script that also does some checking. For both cases a command-line driver for the ICD2 would be ideal. using the MLAB interface is not a good alternative because it can not be automated. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

>> I only use IDEs for debugging. I've never understood the >> attraction of using an IDE for editing code and building software. > >The big problem is the ICD2 - as far as I can tell, MPLAB is the >only software that can drive it. If there was a simple command-line >program-only driver (like Xwisp or Easyprog) then I'd hack together >a batchfile and use that. The compile/load into mplab/program/hit >run/repeat cycle gets rather boring after a while. It's easier >just to have everything built into mplab, hit F10 and have the code >compiled and linked and the chip programmed, all in one go... > >"But all I wanted was DBANKIF and /FLAG..." <VBG> well DBANKIF can be done, but /FLAG? I guess you could do a /FLAG definition file, run it through Olin's PREPIC once, and use the output of that as an include file inside MPLAB if you really want to do everything inside MPLAB. If you needed to change the definition file then another run with PREPIC would be needed, but I would have thought this would be a pretty small price to pay for the nicety of the definitions. But the project I did using Olin's environment, I used Ultraedit as the editor, had a DOS box open to do the assembly, first run of the day required me to type the batch file name, but subsequent runs it was a case of select the window, and F3 to repeat. Then load the hex file into MPLAB to program/debug. Not that big a deal. On top of that Jan-Erik has instructions on how to initiate the batch file from within Ultraedit, which would save one operation, but I never went that far. This was before the 32 bit version of MPLAB, so Ultraedit with a suitable mark-up file was far better than the MPLAB editor.

Alan B. Pearce wrote : > But the project I did using Olin's environment, I used > Ultraedit as the editor, had a DOS box open to do the > assembly, first run of the day required me to type the > batch file name, but subsequent runs it was a case of > select the window, and F3 to repeat. Then load the hex > file into MPLAB to program/debug. Not that big a deal. > On top of that Jan-Erik has instructions on how to initiate > the batch file from within Ultraedit,... To be true, that isn't anything fancy at all. Just used the built-in feature in UE32 to define "custom buttons". I usualy made three button, "build", "build-n-flash" and "flash". The "flash" part made a call to Xwisp2 to run Wisp628. > which would save one operation, but I never went that far... It actualy saves you the "save" or "save all" operation in UE also, since that is an option when defining the buttons. So a single click on a button would save all buffers, run MPASM/MPLINK and finaly run XWisp2/Wisp628. B.t.w, the info is here : http://www.jescab.se/embedinc.htm. Enjoy ! Jan-Erik.

Chen Xiao Fan wrote: > For command line tools to drive ICD2, take a look > at LPLAB http://www.landamore.com/pic.html. It is > not fully working yet though. Or you can have your build script automatically run MPLAB with the right project if the build was successful. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

Wouter van Ooijen wrote: > I think you have a too limited view of debugging-or-production. I often > do debugging without using ICD-like features, just by observing the > target's behaviour, serial feedback etc. OTOH I do small-scale > production, in most cases driven by a PC script that also does some > checking. For both cases a command-line driver for the ICD2 would be > ideal. using the MLAB interface is not a good alternative because it can > not be automated. I also sometimes debug by watching symptoms. Most of the time when making small changes to existing working code, it either works or has an obvious symptom that tells me where to look in the code. In those cases I have the build script automatically run PIC_PROG if the build was successful. With the ProProg I can even start it running right from the script depending on how the target hardware power works. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

Do you mean you can call MPLAB from the build script and let ICD2 program the chip (an then possibly exit, like what your build script calls MPLABWin)? How to do that? Xiaofan -----Original Message----- From: TakeThisOuTolin_piclistEraseMEspam_OUTembedinc.com [RemoveMEolin_piclistTakeThisOuTembedinc.com] Sent: Tuesday, June 07, 2005 7:34 PM To: Microcontroller discussion list - Public. Subject: Re: [PIC]: Flag auto-allocation macros? > For command line tools to drive ICD2, take a look > at LPLAB http://www.landamore.com/pic.html. It is > not fully working yet though. Or you can have your build script automatically run MPLAB with the right project if the build was successful.

Please look at the following directory and you will roughly know what is required to be integrated into MPLAB. I think it will be a plus to do that. C:\Program Files\Microchip\MPLAB IDE\Core\MTC Suites There may be more things. Take a look at Gputils as well. They have the gputils-mplab in the Sourceforge website. It seems there are still some glitches to integrate gputils into MPLAB. Xiaofan {Original Message removed}

Looks like we will need some files for the integration. Or maybe it is more complicated than I thought. 1) TLEMBEDINC.ini 2) prepic.mtc 3) aspic.mtc 4) linkpic.mtc The first file will look like this // Microchip Language Tools Configuration File // EmbedInc PIC Development Suite // By [Language_Suite] LanguageSuite=EmbedInc PIC Development Preprocessor, Assembler and Linker DefaultFilename=default.em Object=O Target=HEX Library=A Source=ASPIC (??) Header=INS.ASPIC (??) LkrScripts=LINKPIC (??) Output=LST;MAP;HEX;O Debug=COF;COD MTC_Files=prepic;aspic;linkpic {Original Message removed}

Chen Xiao Fan wrote: >> Or you can have your build script automatically run MPLAB >> with the right project if the build was successful. > > Do you mean you can call MPLAB from the build script If you mean "run" MPLAB, then yes. > and let ICD2 program the chip Not that I know of. This would be a nice feature though. Normally I use an ICE or the simulator, so this isn't an issue. Both those come up with the newly built version automatically since the external part doesn't have to be programmed. > an then possibly exit, like what your build script calls MPLABWin)? Not that I know of. When I just want to program the target without debugging I a ProProg. The software is scriptable, so you can have it program the chip, then have it let the target run and exit. You can even have it supply target power and exit the program. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com