Messages

This is excellent news. I didn't have the guts to take a soldering iron to my only working 003 board. While you had the IC out did you hook it up to an MCU to read out the content?

Thanks for reporting this, I promise I'll investigate and fix any problem. It may take a couple of weeks though as I'm very busy with something else.

You can pass around the whole type as a reference if you want. Typedefs make that less clunky to look at:

Code Select Expand


typedef  Usart6<Usart6InterruptFeature> MyUsart;
MyUsart usart6;

MyUsart _usart=usart6;


Is that all you need? If you were looking to write a class that's more generic and doesn't need to know that it's operating specifically on Usart6 then consider making it a template that takes your Usart type as a template parameter.

Hi Pete, your board looks great. 4 layers huh? If you've got a continuous ground plane below the top then your signal integrity should certainly benefit from that.

When i took home the Z800 had active adaptive cooling depending on load, now first thing i did was putting in my SSD and reinstall Win7Prox64.

Since then i've also got a hot-headed graphics card and after realised the chassis fans are not adaptive anymore, i decided to take off the side and use it like that for a while. Does anyone know what driver/program i have to install in order to have adaptive cooling active again?

Do you have access to any more Z800s at your place of work? If so you could perhaps compare installed drivers to see if there's anything HP specific in there that looks interesting.

If you don't manage to find out what it is then you can always use the SpeedFan utility to set up a link between the CPU temperature and the case fans. There's a good tutorial here.

You'll need to find out which controller is responsible for your fans by selecting "Configure" then the "Advanced" tab. For example, the two CPU fans are on the "ADT7490" controller with properties "PWM 1 mode" and "PWM 2 mode". You can verify that by changing their values from "Auto on PECI0/1" to "Always on full" and listening for the obvious change in noise level.

My case fans are controlled by sliders on the front of the case so I don't know which controller they would appear on if they were plugged into the motherboard.

I wasn't particularly happy with the development boards available for ST's F042 MCU. I really wanted one that supported USB device development on the highly cost effective TSSOP20 package and so I created my own.



As usual schematics, gerbers and a bill of materials is provided for you to create your own.

I just fixed an annoying caching bug on the server side that would appear to log you out as you browsed around. Hopefully that's gone for good now.

Hi,

Using the LSE on the F4 RTC should be as simple as changing this...

Code Select Expand


      Rtc<
        RtcLsiClockFeature<RtcMeasuredLsiFrequencyProvider>,  // we'll clock it from the LSI clock and calibrate the LSI using a timer
        RtcSecondInterruptFeature,                            // we want per-second interrupts
        RtcAlarmAInterruptFeature                             // we also want the alarm A interrupt
      > rtc;


to this...

Code Select Expand


      Rtc<
        RtcLseClockFeature,             // we'll clock it from the LSE clock
        RtcSecondInterruptFeature,      // we want per-second interrupts
        RtcAlarmAInterruptFeature       // we also want the alarm A interrupt
      > rtc;


Please try it and let me know how you get on.

- Andy

It's been a while since the last release so I thought it about time to release 4.0.3. The features and fixes are detailed in the github release.

[Set all pins high in a group using just the iterator:]

A request came in to the github issues tracker asking for an iterator feature for GPIO pins that could function like an STL iterator and therefore take advantage of the utilities provided in the <algorithm> header.

I've now added this feature to the master branch to be released with version 4.0.3. You will need to include <algorithm> for most of the STL algorithms and "util/StdExt.h" for the algorithms that I've imported from the C++11 release of the STL (all_of, any_of, none_of, find_if_not).

Here's some examples of possible usage:

Set all pins high in a group using just the iterator:

Code Select Expand


GpioC<DefaultDigitalOutputFeature<1,7,9,12,14>> pc;

for(auto it=pc.begin();it!=pc.end();it++) {
  it->set();
}


Set all pins high in a group using a C++11 lambda:

Code Select Expand


GpioC<DefaultDigitalOutputFeature<1,7,9,12,14>> pc;

std::for_each(pc.begin(),pc.end(),[](GpioPinRef &g) { g.set(); });


Check if all pins are high in a group using a C++11 lambda:

Code Select Expand


GpioC<DefaultDigitalInputFeature<0,1,2,7,12>> pc;

if(std::all_of(pc.begin(),pc.end(),[](GpioPinRef& g){ return g.read(); }) ) {
  // all pins are high
}


In a configuration where some port pins are output and some are input, do something if at least one of the input pins is set:

Code Select Expand


GpioC<DefaultDigitalInputFeature<1,7>,DefaultDigitalOutputFeature<8,9>> pc;

if(std::any_of(pc.begin(),pc.end(),[](GpioPinRef& g){ return g.getMode()==Gpio::INPUT && g.read(); }) ) {
  // at least one pin is set
}


Looks nice. Did you cut it from metal and stick on a paper overlay afterwards?

The TE signal triggers at the beginning of the vertical blanking period and should be used as a trigger to redraw the display free from the possibility of crossing the refresh signal and causing the 'tearing effect' where the previous frame's data overlaps with the next frame's data. To do this successfully there are two conditions:

• You must complete your redraw faster than the refresh time (usually about 62Hz).


• You must redraw in the same direction as the refresh. That is, if the refresh runs from top left to bottom right then you must redraw in that direction too. Note that on the Vivaz U5 display the refresh always runs in 'portrait' mode even when you set the logical orientation to 'landscape'.

In practice that means that you can only really write out complete frames of data. If you try to issue commands that move the drawing window around the screen and then draw geometric figures then it's very likely that the refresh will catch up with you and you'll get tearing. Full-frame redraw with TE synchronisation is what I do in the FPGA graphics accelerator project and it frees up the MCU on that board to perform logic operations while the FPGA is pushing out data at full speed to the display.

1) The HC-06 module that I bought did not name itself "HC-06" but "IDTech\r". This causes the Android app to fail to link.
The solution I used was to change the string"HC-06" to "IDTech\r" in the java source code and to rebuild the app.
ReFlowApplication.java
protected static final String OVEN_DEVICE_NAME = "IDTech\r";

Ah, I mistakenly assumed that all those clones out there would be using the same firmware as each other. I guess not. It's an easy change for me to add the bluetooth device name to the app settings and I will do that because not everyone will be comfortable setting up an Android development environment.

2) The Nokia display that I purchased had a different arrangement for the LED backlight. Mine had the LEDs wired to Gnd, so required current to be injected into the "LED" pin (pin 7).
Solution I used was to remove Q3, R12 and R13. Fit a 100R resistor between PWM and P8.7 ( the pads for R12 and R13 can be used)

Thanks for documenting this workaround. It'd be slightly more complicated to add a high-side PNP switching circuit to control this arrangement but I could probably fit the component footprints on the board so people could choose whichever one suits their LCD.

3) I suspect that the values documented for the AVR fuses are incorrect.
avrdude -c usbasp -p m8 -e -U lfuse:w:0xD2:m -U lfuse:w:0xff:m -U hfuse:w:0xd9:m
My analysis of 0xD2 for the low byte decodes as an 2MHz RC oscillator, whereas we have an 8MHz crystal fitted.
Solution I used was to use 0xFF for the low fuses.

You're right. There's a bug in my programming script:

Code Select Expand


fuse_cmd="avrdude -c usbasp -p m8 -e -U lfuse:w:0xD2:m -U lfuse:w:0xff:m -U hfuse:w:0xd9:m"


As you can see I'm mistakenly repeating the value for lfuse but luckily the second value takes precedence and so the value I actually program is correct.

4) The layout of P6 is not the same as the 6 way ISP connector on the ATMEL dragon, or the ATMEL AVRISP mkII so do not use a ribbon cable with 6 way headers with these programmers.
Solution I used was ribbon cable with 6way header at one end but individual headers at the other.

There's always one thing you wish you'd done differently after you've submitted the PCB design for manufacturing and this was the one. If I do a rev.2 of the board then I will certainly be re-arranging those pins.

5) Be aware that there is no solder resist between the pads for the transistors, It is much easier to get solder bridges on these devices, Inspect carefully after soldering.

I mentioned this in the video. The pads are surprisingly close together considering this is a standard TO-92 footprint in Altium Designer. It's OK though as long as you're careful with the iron.

All I need to do now is persuade the Financial controller that we NEED a new toaster Then I can start cooking.

I highly recommend the halogen ovens that you can get for £30 on ebay. I can't believe that a traditional toaster oven would get anywhere close to the performance of the halogen ovens.

I just pushed a commit that fixes these issues. Please let me know of any further problems.

They come from the selected access mode template. stm32plus can drive an LCD through the 8 or 16 bit FSMC peripheral or using a number of optimised GPIO modes. You can find them all in this directory.