can this tool effective identification cpu of firmware for routers and cameras?

[zer0-1s]

emba@emba:~/Desktop/cpu_rec$ python3 cpu_rec.py RV110W_FW_1.2.2.5.bin 
RV110W_FW_1.2.2.5.bin                                                           full(0x2542d)  None                               chunk(0x400;2)      STM8      
emba@emba:~/Desktop/cpu_rec$ python3 cpu_rec.py DIR-320A1_FW121WWb03.bin 
DIR-320A1_FW121WWb03.bin                                                        full(0x383080) None                               chunk(0x2d1800;1443)6502      
emba@emba:~/Desktop/cpu_rec$ python3 cpu_rec.py DIR-868L_fw_revB_2-05b02_eu_multi_20161117.zip 
DIR-868L_fw_revB_2-05b02_eu_multi_20161117.zip                                  full(0xcf3dc3) 6502                         chunk(0x57e800;2813)6502

It seems failed

[LRGH]

A detailed analysis of each firmware would be needed to understand why the results are not good.

I suppose that for example the DIR-320A1_FW121WWb03.bin file that you mention is the one that can be downloaded at https://files.dlink.com.au/products/DIR-320/REV_A/Firmware/Firmware_v1.21b03/ because I get the same results.
According to https://wikidevi.wi-cat.ru/D-Link_DIR-320 the CPU is a Broadcom BCM5354 at 240 MHz, which according to https://www.insidegadgets.com/wp-content/uploads/2015/04/BCM5354.pdf is a MIPS32 architecture, which is supposed to be known by cpu_rec.
But when using binwalk (the old python variant) on this file, I get the following output:

--------------------------------------------------------------------------------
48            0x30            Unix path: /dev/mtdblock/2
96            0x60            LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2240512 bytes
720992        0xB0060         PackImg section delimiter tag, little endian size: 3157248 bytes; big endian size: 2961408 bytes
721024        0xB0080         Squashfs filesystem, little endian, version 2.0, size: 2960636 bytes, 984 inodes, blocksize: 65536 bytes, created: 2010-11-23 09:18:41

It seems similar to what has been analyzed about another similar product: https://openwrt.org/toh/d-link/d-link_dir-845l_rev._a1
My assumption is that cpu_rec fails for this example because the relevant part of the firmware is compressed.

[zer0-1s]

I think so too. Maybe I need to test a specific executable file for decompression. Below are the results of my analysis using cpu_rec and rabin2, respectively.

cpu_rec result:

emba@emba:~/Desktop/cpu_rec$ python3 cpu_rec.py  /home/emba/Desktop/_DIR868L_B1_FW205WWb02.bin.extracted/squashfs-root/htdocs/cgibin
/home/emba/Desktop/_DIR868L_B1_FW205WWb02.bin.extracted/squashfs-root/htdocs/cgibinfull(0x268e8)  ARMel                              chunk(0x20000;64)   ARMel   

rabin2 result:

emba@emba:~/Desktop/_DIR868L_B1_FW205WWb02.bin.extracted/squashfs-root/htdocs$ rabin2 -I cgibin 
arch     arm
baddr    0x8000
binsz    157006
bintype  elf
bits     32
canary   false
injprot  false
class    ELF32
compiler GCC: (GNU) 3.3.2 20031005 (Debian prerelease) GCC: (Buildroot 2012.02) 4.5.3
flags    0x5000002
abi      eabi5
crypto   false
endian   little
havecode true
intrp    /lib/ld-uClibc.so.0
laddr    0x0
lang     c
linenum  false
lsyms    false
machine  ARM
nx       true
os       linux
pic      false
relocs   false
relro    no
rpath    NONE
sanitize false
static   false
stripped true
subsys   linux
va       true

[LRGH]

For this specific file, I don't think that cpu_rec is the best tool, because all information found by cpu_rec (ARM & Little-Endian) is directly visible in the ELF header.