Search results

What purpose does that serve ? (Depending on the nature of the signal on the input pin, you may miss the transition.) In any case, the serout will take just over 3mS to execute. I think that should follow the setint for the same reason.

The Picaxe is a PIC microcontroller that has already been programmed with a Basic Interpreter (and interface software for the AXE027). (The 'raw' PIC microcontroller, obviously has not). Therefore, the answer is "no" :cry:

Maybe something like this or this ❓(I've not tried either of them)

I'm not sure that actually addresses the problem though... The 'Taobao Charging Cable' is an EVSE, and as such, should be advertising that the maximum current available is 10A (assuming that is what it is set to). The actual charger is part of the car and it should draw no more than the EVSE...

I'd be wary of a DS18B20 in this application - for some reason, they seem to be quite poor at surface-temperature sensing. (See my shenanigans with a DS18B20 and central heating radiator!)

Some random thoughts/observations... A "13A" 3 Pin socket is actually rated for a 10A continuous load. You can probably "get away" with up to 13A for long periods, so long as you follow your procedure and keep a close eye on the plug components. I would also ensure that there is nothing close...

Returning to the original question, for a moment ... You may be able to use HSEROUT to avoid having to change frequency in the ISR.

I did some experimenting with this (back in 2015), from which I still have some code :- #picaxe 14m2 #terminal 4800 #no_data #no_end #rem OSCCON reqister address is 099h To convert to Picaxe equivalent, we do the following:- 0 9 9 0000 1001 1001 | |xx| / \ / / / 0011 1001/...

Maybe I'm missing something... Just connect the two parallel wires to a 9V battery. No slug = no current drain. I was surprised to find that the "electrical resistance of slugs is not commonly documented in scientific literature" :)

You may not have quite done what I envisaged - but, hey, if it's working ... :) The association made by ASSOC is just an arbitrary string, rather than a filename. FTYPE takes a filename (in double-quotes if necessary), followed by placeholders for any command line parameters. Some help on the...

Yes, it's all turned into a bit of 'black art' :( You should still be able to do what you want, using the "Command Prompt (Admin)" aka CMD.exe. This still implements the olde-worlde pair of commands "ASSOC" and "FTYPE" (I never did understand why two programs were necessary). The first one...

Two ways... Select a block of code and right-click and choose "Comment -> Comment" or insert #REM before the desired code and #ENDREM after it.

There are some pertinent threads in the forum :- (3) Adafruit Ultimate GPS Breakout | PICAXE Forum and (3) Extracting GPS time with PICAXE | PICAXE Forum and especially (3) GPS Data receiver using X2's background serial data reception | PICAXE Forum I would start by connecting to the...

One slight issue is that drivers have to be native ARM binaries. Our old friend the AXE027, with its old FTDI innards may, or may not, be on the list to be ported :unsure:

I found this (Windows on Arm). Amongst other things it says: This implies that it 'should just work'. There will be an obvious performance overhead, which, I suppose, could affect things like simulation. (I assume that by 'x86', they really mean WIN32 applications (like Picaxe Editor)...)

So to get 20 discrete points, you're dividing by 13, rather than 16 ❓ (given that you can't divide by 12.8)

I think the problem might well turn out to be a 'memory leak' of some description. It seems to use resources far in excess of what you would imagine it capable of :unsure: ...

The "Terminal" will try to store all data that it receives. It continues to do this, regardless of the serious depletion of system resources that can ensue. The solution, is to use something like Putty, (which allows you to set the size of the screen buffer, to some finite size).

Is this the same problem that I had? https://picaxeforum.co.uk/threads/6-0-9-2-resource-usage.29861/ (Logging to terminal eventually consumes all system resources...)

The max. operating temperature for the TEPT4400 is quoted as 85°C and the venerable ORP12 LDR as 75°C; I can't see any restriction on maximum light level. LDRs are commonly used in Oil Boilers to confirm that they're lit, so I've always thought of them as pretty robust. I think you need some...