PICAXE-18M2 microcontroller

Product Details

A compact but powerful, PICAXE-18M2+ microcontroller. Very popular in education due to its low cost and small size, but also very popular in a wide range of hobbyist projects.

This chip supports up to 16 inputs/outputs with 10 analogue/touch sensor channels.  

All M2 series parts support enhanced features such as configurable i/o pins, parallel tasks, ring tone music and touch sensor inputs.

Click here for more M2 series information.

For more details see the What is PICAXE and PICAXE Pinout pages.

The PICAXE-18M2+ replaces the older PICAXE-18, 18A, 18M and 18X chips.

Specification

Pack size 40x10x15mm
Pack weight 2.8g

The following table gives a brief summary of the various PICAXE chips.
For a more detailed comparison please see the PICAXE manuals and pinout diagrams.

Feature 08M2 14M2 18M2 20M2 20X2 28X2 40X2
Memory Capacity (bytes) 2048 2048 2048 2048 4096 4096 4096
RAM (bytes) 128 512 512 512 256 1280 1280
Byte Variables (bytes) 28 28 28 28 56 56 56
Input/Outputs Pins 6 12 16 18 18 22 33
ADC/Touch Pins 3 7 10 11 11 16 27
Max. Freq. (MHz) 32 32 32 32 64 64 64
Serial In/Out Yes Yes Yes Yes Yes Yes Yes
Infrared In/Out Yes Yes Yes Yes Yes Yes Yes
I2C Yes Yes Yes Yes Yes Yes Yes
Tune (ring tones) Yes Yes Yes Yes Yes Yes Yes
Parallel Tasks 4 8 8 8 1 1 1
Program Slots 1 2 2 2 1 4 4

The same software, BASIC language and USB download cable is shared between all the PICAXE chips.

 

Resources

PICAXE-18M2 Microcontroller Datasheet PDF Datasheet
M2 Series Product Summary PDF Datasheet
PICAXE-18M2+ Release Notes PDF Datasheet

Video

Revision History

Current 18M2+ production firmware is version D.A Known issues: ISSUE - NAP 1 CAUSES RESET At K31 CLOCK FREQUENCY To workaround this issue do not use 'nap 1' after 'setfreq k31' All other values (e.g. 'nap 2') work correctly. ISSUE - CALIBADC IS UNSTABLE AT M32 CLOCK FREQUENCY To workaround this issue use two consecutive 'calibadc' commands to give time for the Vref to settle. Previously resolved issues (18M2): ISSUE - USE OF THE CALIBADC COMMAND SETS PIN C.7 TO INPUT (IF CURRENTLY OUTPUT) A 'calibadc command' will incorrectly make the pin C.7 an input. To workaround this issue use pin C.7 as an input, or issue a 'output C.7' as the next command. Fixed in vD.A ISSUE - USE OF THE READDAC COMMAND SETS PIN C.6 TO INPUT (IF CURRENTLY OUTPUT) A 'readdac command' will incorrectly make the pin C.6 an input. To workaround this issue use pin C.6 as an input, or issue a 'output C.6' as the next command. Fixed in vD.A ISSUE - PAUSE DOES NOT WORK CORRECTLY DURING INTERRUPT ON A MULTI-TASK PROGRAM To workaround this issue use the command 'pause_int' instead of 'pause' within an interrupt in a multi (parallel) task program Fixed in v2.D ISSUE - LOW, HIGH, TOGGLE DO NOT STOP SERVO PULSES ON THAT PIN To workaround this issue use 'SERVOPOS PIN,0FF' after the HIGH/LOW/TOGGLE command Fixed in v2.D ISSUE - USE OF THE COUNT COMMAND STOPS BACKGROUND SERVO AND TIME OPERATING The count command does not restore the internal interrupt system, so that 'servo pulses' and 'time' both stop. To workaround this issue use 'Let time = time' after the COUNT command. This will reset the internal interrupts, so time and servo start working again. Fixed in v2.D ISSUE - VERY FIRST LINE OF INTERRUPT: ROUTINE SHOULD NOT USE VARIABLES (LET, INC, DEC, IF VAR = etc.) A 'inc' or 'dec' or certain expressions may not work correctly if it is used as the very first line in the 'interrupt:' subprocedure. To workaround this issue add another command, such as 'pause 1', before the let/if command is used within 'interrupt:' Fixed in v2.D ISSUE - CORRECTED ISSUE WITH WRITE TO OUTPINSC CORRUPTING DIRSB Corrected issue where writing a value to outpinsC corrupts dirsB value. Reading outpinsC works as expected. To workaround this issue use 'let pinsC =' rather than 'let outpinsC = '. This gives the same result. Fixed in v2.B ISSUE - CORRECTED ISSUE WITH 'WORD' MODE IN I2C COMMUNICATION Word mode for i2c EEPROM addressing does not work correctly in v2.A Byte mode works correctly. Therefore to workaround this issue emulate word mode manually by use of bytes only. This is possible because all word addresses are always transmitted as two separate bytes on the i2c bus anyway. Therefore the i2c bus wll see exactly the same byte sequence as would be generated automatically in word mode. To do this follow these 3 steps: a) Change 'i2cword' to 'i2cbyte' in the hi2csetup command b) Change hi2cout commands from this hi2cout word_address, (data1, data2, etc) to hi2cout (msb_byte_of_word, lsb_byte_of_word, data1, data2, etc) e.g. hi2cout w0, (b10, b11, b12) to hi2cout (b1, b0, b10, b11, b12) ; (as word w0 is made up of the two bytes b1:b0) e.g. hi2cout 100, (b10, b11, b12) to hi2cout (0, 100, b10, b11, b12) ; (as 100 = 0x256 + 100) e.g. hi2cout 300, (b10, b11, b12) to hi2cout (1, 44, b10, b11, b12) ; (as 300 = 1x256 + 44) c) Change hi2cin commands from this hi2cin word_address, (data1, data2, etc) to hi2cout (msb_byte_of_word, lsb_byte_of_word) hi2cin (data1, data2, etc) e.g. hi2cin w0, (b10, b11, b12) to hi2cout (b1, b0) ; (as word w0 is made up of the two bytes b1:b0) hi2cin (b10, b11, b12) e.g. hi2in 600, (b10, b11, b12) to hi2cout (2, 88) ; (as 600 = 2x256 + 88) hi2cin (b10, b11, b12) Fixed in v2.B

Related Products