Hi, actually, just 10 minutes ago, (partially) solved the issue.
To get some more debug info, I tried to find out how come my printf/uart had become unfonctional. After stripping down the code, function by function towards what I knew was the last working configuration, I found out that I was using too much memory. When I delete some global vars the printf started to work and also the unsigne long calculation. Almost. I have a main loop that drives my stepper motors back an forth and it runs beatifully for about one minute or exactly nine times and then the calculation below gives a wrong answer. The printing still keeps working and the stepper keeps running but the speed is wrong because this calculation fails (I can see it from the continuous printout). So I'm most like having a memory issue or stack collision. What I'm wondering why I get no compile time warnings? How are the parameters passed to functions? I know they are passed in globals, but are the globals reused so that I' not using as much memory as all my functionas take parameters? How about function local vars? Does the compiler do a call depth analyzis and determine what can be safely overlayed regards the globals vars? br Kusti >>> rich...@reallyrathergood.com 18.1.2009 16:33 >>> I am guessing a bit, but try:- STEPPER.brakeDistance = (unsigned long) ((STEPPER.maxSpeed+STEPPER.minSpeed)*(STEPPER.maxSpeed-STEPPER.minSpeed))/(2*STEPPER.acceleration); Of course, you could declare all the relevant variables unsigned longs and not bother with the cast. FWIW, I have had trouble with code like this because the libraries are not reentrant and when interrupts are involved things went quite weird, but that was Z80 code...? I'm not familiar with the PIC in question, but are you sure a long is as 'long' as you think it is!? On Sunday 18 January 2009 10:49:45 Kustaa Nyholm wrote: > Hi, > > a bit early to ask this but it may take a few hours before I can > actually see what values I'm getting > (my usart/serial port is not functioning at the moment) so I might as > well ask here. > > Is there something to I need to do to enable support for 32 bit arithm > ops? > > It appears that the following statement: > > STEPPER.brakeDistance = ((unsigned > long)(STEPPER.maxSpeed+STEPPER.minSpeed))*(STEPPER.maxSpeed-STEPPER.minSpee >d)/(2*STEPPER.acceleration); > > does not produce what I would expect. > > With the following values > maspeed = 5000 > minspeed = 300 > acceleration = 10000 > > this should give > > breakDistance = 1245 > > but judgin from the behavior of the motors this is not happening. If I > manuallu put in the correct breakDistance then this works. > > Yeah, would be better if I had some actual faulty values to show, but > that will take some hours..or days. > > Meanwhile, anything obvious in my code? > > Do I need to recompile SDCC libraries or some such? > > br Kusti > <snip> -- Richard. PGP Key-id: 0x5AB3D350 George Orwell was an optimist. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
