CJMCU-232H is a very popular module based on the FT232H that can be used as JTAG, SWD, ICSP/ISP interface to flash most of microcontrollers (for example ESP32, STM32 and AVR).
AVRDUDE stands for “AVR Downloader Uploader” and is a software tool for downloading and uploading the on-chip memories of Microchip’s AVR microcontrollers (like ATMega).
The CJMCU-232H presents itself to the OS as “idVendor=0403, idProduct=6014”, so we can use the default “UM232H” programmer type of AVRDUDE like:
avrdude -c UM232H -p m328pb -v
UM232H programmer should already be defined in the “/etc/avrdude.conf” so we don’t need to modify/patch any files.
For completeness I report the configuration:
programmer
id = "UM232H";
desc = "FT232H based module from FTDI and Glyn.com.au";
type = "avrftdi";
usbvid = 0x0403;
usbpid = 0x6014;
usbdev = "A";
usbvendor = "";
usbproduct = "";
usbsn = "";
sck = 0;
mosi = 1;
miso = 2;
reset = 3;
;
Dopo i primi test del servizio “IT-alert” i complottari incalliti hanno un nuovo nemico.
Nel loro fantastico mondo dove la terra è piatta, lo sbarco sulla luna è un film di Kubrick, dove ti iniettano i chip con i vaccini e si provocano disastri meteorologici con le scie chimiche, poteva mai mancare il telecontrollo via IT-alert?
Tristezza
Non è mia intenzione debunkare questa follia, sarebbe dispendioso come ci insegna anche la “teoria della montagna di merda“:
“Per produrre una montagna di merda ci vuole poca fatica, mentre per pulirla ci vuole una fatica immensa e comunque l’odore ti rimane addosso. Questa è l’asimmetria fondamentale del cospirazionismo.”
Ne approfitto per scrivere due righe su cosa c’è sotto. Intendo realmente, non nel triste mondo dei tristi complottari.
Il servizio IT-alert sfrutta la tecnologia chiamata “Cell Broadcast” la cui architettura è descritta nello standard 3GPP 23.041 e che esiste da praticamente sempre nella storia del GSM, tant’è vero che è supportata su tutte le reti: 2G, 3G, LTE, 5G.
Stralcio della specifica V3.0.0 del 1999
Probabilmente i complottari, da adolescenti, hanno già utilizzato questa tecnologia sui loro primi telefonini senza neanche rendersene conto. Ma, all’epoca non c’era ancora il ragazzino su TikTok che scopriva i segretissimi piani della NASA e del Nuovo Ordine Mondiale.
Se vi ricordate, sui primi telefoni GSM (parlo ai tempi del Motorola 8700, StarTAC, ecc), sul display vi appariva il nome della rete dell’operatore: “I-TIM”, “I-OMNITEL”, ecc.
Nel menu potevate scegliere un “canale” proprio nella voce “CELL-BROADCAST” e, inserendo 50, appariva il nome della vostra città accanto al nome operatore: “I-TIM NAPOLI“. Ecco, questo era un servizio della tecnologia “Cell Broadcast” che doveva servire agli operatori ad applicare tariffe scontate quando la chiamata era destinata allo stesso distretto in cui il telefono era registrato.
Questo, fino ad IT-alert, è stato l’unico servizio attivo in Italia sulla tecnologia “Cell Broadcast” e probabilmente neanche mai sfruttato dagli operatori del tempo.
Il Cell Broadcast è definito dall’Istituto europeo per gli standard di telecomunicazione (ETSI) ed è incluso negli standard GSM 3GPP. Si tratta di un servizio di rete mobile basato sulla localizzazione che invia in massa messaggi di testo o binari ai telefoni cellulari nel raggio d’azione di una singola cella, di un gruppo di celle, o all’intera rete.
I messaggi Cell Broadcast subiscono una serie di passaggi che coinvolgono i seguenti componenti:
CBE (Cell Broadcast Entity): è il luogo di origine del messaggio Cell Broadcast.
CBC (Cell Broadcast Center): riceve i messaggi dal CBE e si collega alla rete dell’operatore mobile instradandoli alle celle di destinazione attraverso i controllori RAN.
RAN (Radio Access Network): distribuisce il messaggio di trasmissione delle celle alle celle di destinazione. BSC, RNC, MME e AMF sono i controller RAN rispettivamente per 2G, 3G, 4G/LTE e 5G.
BTS: La cella ovvero il ripetitore.
Dispositivo dell’utente finale: il telefono. Il messaggio può essere visualizzato in modi diversi, a seconda del protocollo specifico e del dispositivo specifico.
I messaggi di tipo broadcast hanno una priorità maggiore rispetto al resto del traffico e quindi passano anche in caso di rete congestionata.
In definitiva, è quasi come la ricezione di un SMS, nessuno vi sta spiando. Dormite sonni tranquilli e siate più sereni. Anzi, se il servizio possa servire un giorno a salvare qualche vita dovreste essere solamente contenti.
Se il servizio sarà utile o no lo scopriremo. In diversi paesi è già attivo da anni.
The PySerial documentation says that if you pass the parity parameters to the __init__(), the “parity checking” feature is enabled. Easy, but it doesn’t work!
The hack is to manually set the right termios flags importing the termios library in addition to the serial lib.
I have three USB-UART adapters, the first is a PL2303 from “Prolific Technology”, the second one is a CH340 from “QinHeng Electronics” and the other is a CP2102 from “Silicon Labs” and I tried to use them in a project involving non-standard baud-rate (1600 bps) on the serial bus.
The PL2303 and the CH340 are capable of non-standard baud-rate talking as long as a fixed parity setting (ODD, EVEN, NONE, MARK or SPACE) is used.
The CP2102 is not capable of non-standard baud-rate communication at all.
I checked with a logic analyzer and some python lines, here are the results.
The test code
import time
import serial
ser = serial.Serial(
port='/dev/ttyUSB0',
baudrate=1200, # 1200 or 1600
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS,
timeout=None
)
while True:
ser.write(b'\x01\x02\x03\x04\x05\xFF\x00')
time.sleep(2)
Silicon Labs CP2102 test restults
CP2102 @ 1200 bps (standard) – OKCP2102 @ 1600 bps (non-standard) – BAD DATA
How about 9-Bit framing also know as Multi-Drop Bus (MDB)?
Neither device is capable of talking on a Multi-Drop Bus.
Serial communication with 9-Bit framing (9-Bit protocol, 9 bit mode) is mainly used to identify the address byte within messages running on a RS-485/RS-232 multi-drop network.
On this type of network one “master” controls one or many “slaves”, the 9th bit is used to distinguish the address from the data.
This type of protocol is not a POSIX-standard, but some devices supports the Mark/Space Parity (CMSPAR) and can use the “Parity Bit” to emulate the 9th data bit.
Acting as TX device, the UART parity settings needs to be set accordly with the type of byte to send: sending an address the parity needs to be set to “MARK” (logic 1), for the data parts the parity needs to be set to “SPACE” (logic 0).
Changing MARK to SPACE parity settings on the fly (reconfigure the UART without closing and reopening the port) is supported by PySerial, but my devices are not behaving as expected.
Acting as RX device, the value of the 9th bit can be recovered observing the parity-error. For example: settings the UART with SPACE parity, we should receive a parity-error when an “address” is received.
Unfortunately, this does not work with any of my devices via PySerial library.
