On Fri, 11 Jan 2013 08:26:25 +0100 al_bin <al_...@vp.pl> wrote: > On 10. 01. 2013 18:09, Raphael Neider wrote: > ... > > So code generation is ready (and a lot of things actually just fall > > into place -- its magic :-D). > > Did you also already use overlapping SFR definitions (TMR1 and TMR1L above)? > ... > > As /sdcc/device/non-free/lib/pic14/libdev/* is created in sdcc build stage, > and source files didn't contain sfr16 keyword, this work as without patch. > Next in install stage we can change extern declaration __sfr TMR1 to __sfr16 > TMR1 > without touching TMR1L and TMR1H in device include files. > Effects you see in example from previous post. And yes, user can use TMR1, > TMR1L and TMR1H together. > > If we want exclude libdev and define SFR in user programs (want we?) > TMR1 conflicts with TMR1H ( if use __sfr16 for TMR1) > To avoid this we can patch file sdcc/src/pic14/glue.c (comment out > instruction for size > increment, line 210). But i'm not sure for all side effects now. > And this is not necessary in my opinion. > > Albert
Something left out of the calculation. In the case of TMRx, differ the read and write sequence. write: first TMRxH, second TMRxL read: first TMRxL, second TMRxH The sdcc can handle this exceptional case? Károly ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user