Hi JBG
this should really go in its own thread...... suggest move it there, since this will generate alot of responses ....
-----------------------------------------------------------
I've never encountered badness in ye-olde AVR (1999-2008 stuff) and given the value, it's likely a cock up in the avr library,.
I''ve only ever used peripherals directly, never used arduino for anything more than a doorbell.
Might be a good time to manipulate the port directly. The AVR timers are quite simple.
For what you're doing, I'd make everything signed so you can never have a rollover F.U.
and watch out for non-monotonic sensors !...
I assume you are using the PWM library https://github.com/atmelino/Arduino/blob/master/libraries/PWM/utility/ATimerDefs.cpp
watch out there is void pwmWrite(uint8_t pin, uint8_t val) and also there is void pwmWriteHR(uint8_t pin, uint16_t val)
in pwmWriteHR(), somehow verify that
if(td.Is16Bit)
is being executed correctly.
, anyway, suggest another thread. cheers
I plan to make a new thread describing my temperature stabilised and barometrically compensated LPRO 101 based Rubidium Frequency standard one of these days when I've finally completed this project.
Now, at last, I really am close to the finish merely requiring that I "Dot the eyes and cross the tees" so to speak before embarking on a MK II version based on an SA.22C I'd purchased just over two years ago now.
I want to put all the lessons I'd learned during the previous three years to good use to create an even better RFS.
However, I first have to resume my ZED-9T based MK III GPSDO project to provide a more phase stable GNSS based frequency standard than the NEO -M8T based MK II standard I'm having to rely on for syntonising my Rubidium based frequency standards to. The long term (days to decades) frequency stability with a PLL based GPSDO is never in doubt but since the only effective way to syntonise a rubidium based frequency standard to such high precision frequency references is to compare phase drift over hours to days long runs, it helps to minimise the effect of the minute to minute variations in electron density in the ionosphere (space weather) - the whole point of blowing 250 quid on that Sparkfun ZED-9T module.
In short, I don't have any idea on when I'll get around to creating such a topic thread.
TBH, I was so astonished by discovering such a gremlin in Robert Brown's simple to implement 10 bit PWM code snippets, I felt impelled to find a topic thread where it wouldn't be unreasonable to announce 'My Discovery' and perhaps elicit more considered responses as to what the actual cause was likely to be. After all, this was an ideal example case where debugging and logic analyser tools would not be able to retrieve the situation.
Manipulating AVR timers might be simple for those who can peruse the whole 200 odd pages of the "Datasheet" without their eyes glazing over but for me that's a bit beyond my pay grade.
When I'm searching for solutions, that meet my less ambitious requirements, ready made solutions like Robert Brown's easy to implement 10 bit PWM code snippets easily satisfied my demand to gain just the extra two bit's worth of fan drive resolution improvement I had craved.
Regarding the use of signed integers, that's the default for int anyway. Besides which, it's very rare for me to feel the need to use unsigned integers even for loop counters (I've not had to use counts beyond the 64K mark thus far). I guess this advice is more useful when programming down to the 'bare metal' which is something I've managed to avoid thus far.
I've been very mindful of 'divide by zero' errors and other 'close call' situations and used the constrain instruction where such possibilities exist. I've been well aware the monotonicity issues in ready made sensors so have steered clear of those which offer "10mV/deg C" and similar such claims. There's nothing more monotonic by way of a temperature sensor comprised of a bead NTC with its "other" resistor located in the same drilling in a quarter inch thick heat spreader plate paired up with an ADS1115 16 bit delta sigma ADC. As for the BMP280 I'm using to gather plenum temperature and barometric compensation data, that seems to be as good as it gets in this regard.
As for your assuming I'm using that PWM library, in view of its 16 bit timer support, I don't think so. Since I don't have an #include reference to any PWM library files, I assume I must just be using the bog standard built in PWM support for the analogWrite commands.
By and large, when it comes to such "simple" (anything but!) temperature control software projects like this, I tend to take a pragmatic approach and steer clear of bare metal programming that requires an understanding of register functions in excruciating detail, preferring to make good use of others' published ready made solutions.
Anyway, thank you for taking the time to respond to my post. It's not as if this mix of software and hardware is new to me (I did this sort of stuff with a Z80 based Transam Tuscan S100 bus kit computer and a set of bare Philips solenoid operated data cassette drives some 4 decades back). Sadly, I'm just a little too long in the tooth for my worn out brain cells to get a grip on any bare metal programming of the Atmel AVR. KISS (in my case, Keeping It Stupidly Simple) had been the only viable way I could get this project done and dusted.
Home
Help
Search
Login
Register
