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

Reply via email to