MIPS gcc for windows prebuilt

 Hard to find it via google. Here's MIPS-gcc for windows. 

I can do no better than give this link, which works as of 2021 and will do so until mentor take it down, although it's been up since 2013..

https://sourcery.mentor.com/public/gnu_toolchain/mips-sde-elf/mips-2013.11-37-mips-sde-elf.exe

If this link is dead, look for 'mips-2013.11-37-mips-sde-elf.exe'

Running Pi-Hole on an Orange Pi Zero (256MB RAM) without crashing

Default setting for Pi-Hole causes it to run out of ram on a 256MB system such as the ultra-cheap Orange Pi Zero,

Suggested changes:
edit fastcgi-php to run less cgi processes e.g.
nano /etc/lighttpd/conf-enabled/15-fastcgi-php.conf
and change
 "PHP_FCGI_CHILDREN" => "2",

(from 4 child processes)

also change 

nano /etc/php/7.3/cgi/php.ini

and set

memory_limit = 64M

(instead of 128M)

That should do it

VMWare guest suddenly can't ping host (but can reach LAN/WAN) - SOLVED! (Linux VM on Windows 7 host)

Scenario:

1. Laptop running VMWare, single Gig-E port on laptop onto LAN/WAN. The usual.
2. VMWare setup working fine since forever, VMs bridged to LAN and hence work like an independent network interface with their own MAC/IP etc. Yay.
3. Suddenly one day out of the blue the fecking thing only half-works; 
1. the VM can reach the LAN and internet 
2. Other boxes on the  LAN can reach the VM just fine
3. ...but the VM can't ping/etc the host machine, or vice versa.
4. W.T.F!? Has worked since forever!

SOLUTION:

Running Wireshark (or similar network sniffer) switches the gig-e interface into promiscuous (i.e. not MAC-filtered) mode, which is all fine and dandy, and when capture stops, as you'd expect, Wireshark switches it off again...

If you run arping from the VM to the host, it fails, but it starts working as soon as you begin packet capture in wireshark - and stops as soon as you stop..

It appears (which is somewhat logical) that VMWare lan bridge stuff requires the i/f in promiscuous mode and Wireshark turning it off at the end of a capture breaks the connectivity from VM to host somehow.

Solution: After using wireshark, in the Windows network adapter panel, disable and re-enable the interface. This resets it back to a fully working (with VMWare) condition.

If that stopped you screaming at your computer - you're welcome!

DFPlayer MP3 module - high quiescent power consumption and clicks when power applied and removed - FIX!

The DFPlayer is a great little MP3 player module at a fantastic price, but there's a really odd design choice; it has a high quiescent current of about 25ma, requiring you to cut the power to it with a PFET when not in use, and, worse, it suffers from power on/off clicks when you do that.

The schematic of the module is basically the reference design from here (the mp3 player chip vendor's page)

http://www.yxin18.com/kp/2015102450.html

and they're using a bog-standard no-name 8-pin 8002 audio amplifier chip (in this case a class AB one, not a PAM8002 which is class D, but hey, the whole board costs about a buck), anyway it's a BTL amplifier, so + and - are both floating at VCC/2 when no sound is playing.

This requires the amp to put a little care into avoiding pops/clicks when power is applied and removed, and the 8002 designers kinda did this already; here's a generic 8002 amp datasheet;

http://thaieasyelec.com/downloads/EFDV308/HXJ8002_Miniature_Audio_Amplifier_Datasheet.pdf

They have both a SHUTDOWN pin and a bias cap so that the speaker ramps up and down subsonically... 

Anyway looking at the DFPlayer board I see they just have the SHUTDOWN pin (pin 1) wired to GND, i.e. always-on, via a 0-ohm resistor (if you look next to pin 1 on the 8-pin chip on a generic DFPlayer module, there's a "000" resistor next to it).

What's totally bizarre is that the MP3 player chip is set up to output a "BUSY/IDLE" signal (comes out on pin 1 of the DFPlayer module) which is the right polarity and basically ideal to drive the SHUTDOWN on the 8002 amplifer.

..and lo and behold, if you pull off the 0-ohm resistor and wire pin 1 of the 8002 straight to the BUSY output pin of the module - you get a double win - no more power on/off clicks at all (now totally silent) AND halves the quiescent power consumption of the module (takes about 10mA off it).

WTF? No idea why they didn't do this... Anyway, there's your easy fix...  now you can gate the power to the entire module (still necessary, it sucks down >10ma even when not doing anything) but at least it doesn't click when you do it....

EDIT: Aaaaahhh.. they did, it's an option. Looking at the underside of the board there's  unpopulated pads opposite the 0R resistor; remove the 0R and put it on the other pads and it connects SHUTDOWN to BUSY :-)

DFPlayer MP3 module - high quiescent power consumption and clicks when power applied and removed - FIX!

The DFPlayer is a great little MP3 player module at a fantastic price, but there's a really odd design choice; it has a high quiescent current of about 25ma, requiring you to cut the power to it with a PFET when not in use, and, worse, it suffers from power on/off clicks when you do that.

The schematic of the module is basically the reference design from here (the mp3 player chip vendor's page)

http://www.yxin18.com/kp/2015102450.html

and they're using a bog-standard no-name 8-pin 8002 audio amplifier chip (in this case a class AB one, not a PAM8002 which is class D, but hey, the whole board costs about a buck), anyway it's a BTL amplifier, so + and - are both floating at VCC/2 when no sound is playing.

This requires the amp to put a little care into avoiding pops/clicks when power is applied and removed, and the 8002 designers kinda did this already; here's a generic 8002 amp datasheet;

http://thaieasyelec.com/downloads/EFDV308/HXJ8002_Miniature_Audio_Amplifier_Datasheet.pdf

They have both a SHUTDOWN pin and a bias cap so that the speaker ramps up and down subsonically... 

Anyway looking at the DFPlayer board I see they just have the SHUTDOWN pin (pin 1) wired to GND, i.e. always-on, via a 0-ohm resistor (if you look next to pin 1 on the 8-pin chip on a generic DFPlayer module, there's a "000" resistor next to it).

What's totally bizarre is that the MP3 player chip is set up to output a "BUSY/IDLE" signal (comes out on pin 1 of the DFPlayer module) which is the right polarity and basically ideal to drive the SHUTDOWN on the 8002 amplifer.

..and lo and behold, if you pull off the 0-ohm resistor and wire pin 1 of the 8002 straight to the BUSY output pin of the module - you get a double win - no more power on/off clicks at all (now totally silent) AND halves the quiescent power consumption of the module (takes about 10mA off it).

WTF? No idea why they didn't do this... Anyway, there's your easy fix...  now you can gate the power to the entire module (still necessary, it sucks down >10ma even when not doing anything) but at least it doesn't click when you do it....

Seriously optimizing power consumption on a STM8F103F3P6 "minimum system board"

You know, these things, they're all over EBay

Anyway, when running off 3.3v (not using the USB connector) and putting them into the lowest power mode I could find (ACTIVE-HALT using the AWU to wake it up once a second) I was still seeing several milliamps power consumption; was expecting a hundred microamps or thereabouts;

To achieve this;
a) (Obviously) Remove the "PWR" led (or take off the resistor on the underside) to save a few mA
b) Remove the 3.3v regulator(!!) this was the main problem; was leaking about 2.2mA when back-powered with 3.3v

Down to about 178uA now (with internal main voltage regulator (MVR) on) running off internal LSI clock, which is nicely just under the datasheet's quoted 200uA.

With the MVR off in halt and the flash powered down (and again waiting up with AWU at 1hz to do practically nothing), i.e.
FLASH_SetLowPowerMode(FLASH_LPMODE_POWERDOWN);
CLK_SlowActiveHaltWakeUpCmd(ENABLE);

we're down to 38uA!!! Sweeeet!

Found: bug in Tinysidplay V0.94 playing Martin Galway music (and others probably)

Bug in TinySidPlay 0.94

The linux source for this version comes with a .CPP version and a separate .C version (the latter is what the makefile uses). There's a couple of glaring bugs in the 6510 emu which means it can't play several bits of music, e.g. Martin Galway's stuff.  This is fixed in the CPP version but it's hard to spot;
the error is in the "CPX" and "CPY" instruction emulations in sidengine.c;

at both "case cpx:" and " case cpy:" (around line 950ish) the "setflags(FLAG_C, a >= bval);" is setting the carry flag based on comparing with A not X, so change it to
setflags(FLAG_C, x >= bval);
..same with "cpy" just below it, change to
setflags(FLAG_C, y >= bval);

and workie!