How to get the serial port number in Makefile? - makefile

Sometimes, you need to know the serial port number when developing MCUs. For example, I plug the USB cable of the board into the USB port of my computer, then one serial port number appeared in the Device Manager, such as COM6. Then I can use the programmer to upload my program (.elf or .hex) to the MCU, the premise is that I specify the serial port number, namely, the 6 in COM6, to the programmer through the command.
For example, in command prompt of CMD.exe, I use "dwdebug.exe com6,l
test.elf,qr" to flash the MCU, the dwdebug.exe is the executable program which used for programming, the com6 is the serial port number, and test.elf is the code to be flashed into the MCU, l means "load", qr means "quit dwdebug.exe after loading, and run mcu".
In addition, I can use the command "dwdebug.exe ls,q" to list all the serial port number available in CMD.exe, for example, after running dwdebug.exe ls,q in CMD.exe, the outputs displayed in the CMD window:
COM5 .Expecting break byte 0x00, but no bytes read.
ATmega328P on COM6 at 62537 baud.
Then I planed to write a Makefile, part of the Makefile is:
COM = 6
PRG = test
MCU_TARGET = atmega328p
CLK = 8000000UL
UPLOADER = dwdebug
flash:
dwdebug ls,q
$(UPLOADER) device com$(COM),l $(PRG).elf,qr
debug:
$(UPLOADER) device com$(COM),l $(PRG).elf
From the Makefile above we can see that the variable COM at the beginning of the Makefile must assigned by the user, the serial port number, namely, the value of COM, is used by dwdebug.exe for flashing and debugging.
So, I think it's better to extract the number "6" behind "ATmega328P on COM", and assigned it to the variable COM:
flash:
dwdebug ls,q
$(UPLOADER) device com$(COM),l $(PRG).elf,qr
debug:
$(UPLOADER) device com$(COM),l $(PRG).elf
The advantage of doing this is that the user no longer need to view the Device Manager, namely, the user will not assign the serial port number (the 6) to COM at the beginning of the Makefile too, let the code finish the work automatically.
After searching many web pages, now I can save the outputs of "dwdebug ls,q" in a .txt file, such as:
flash:
dwdebug ls,q > serial.txt
$(UPLOADER) device com$(COM),l $(PRG).elf,qr
Now, the content of serial.txt is:
COM5 .Expecting break byte 0x00, but no bytes read.
COM6 ................
ATmega328P on COM6 at 61934 baud.
But how to extract the number "6" behind "ATmega328P on COM", and use the "6" in Makefile as the value of variable COM? It is a difficult point that I cannot be overcome, is there anyway to overcome this problem?
Best regards.
P.S.1 "ATmega328P on COM" is not changed.
P.S.2 My OS is Windows 10
Extract the serial port number, and assigned it to a variable in Makefile.

Related

Writing to a peripheral in Vivado and then outputting to a LED

I want to create a basic project in Vivado that takes a value that i input to a client, which is sent to a server I made (in C), and then the server writes that value to a peripheral in Vivado, and then that data in the peripheral is sent to an output pin that assigns to LED's, making the LED light up.
Basically I want to go from client-->server-->peripheral-->LED lights up
For example, in the client (a GUI) I want to give it a value such as 0011, which is received by the server. Then the server writes that value to the peripheral which will then make, in this case, LED0 & LED1 not light, but LED2 & LED3 will light.
I know how to make an AXI4 peripheral in Vivado, and the client-server (TCP/IP) has been made. My question is what code/design block I would need to then take the data written to the peripheral and assign it to the LED's?
Should I make the peripheral a Master or Slave? Overall confused how should i proceed from here. I am using a Red Pitaya (Xilinx Zynq 7010 SoC) connected by an Ethernet cable to my computer.
Also, I thought of running the program on the Red Pitaya by loading the bitstream on to it (using WinSCP) by running the command
cat FILE_NAME.bit > /dev/xdevcfg
in PuTTY (connected to the Pitaya by IP address), then running the server on the pitaya, and then sending the signal from the client for the server to receive. Is that the correct way of approaching it?
If my logic is off in anyway please let me know
I am somewhat thrown by your statements.
First you say "I know how to make an AXI4 peripheral in Vivado"
Next I read: "Should I make the peripheral a Master or Slave?"
Maybe I am wrong but to me it says you don't really know what you are doing.
Simplest is to:
Instance a zynq system.
Add the IP with the name "AXI GPIO". (Which, by the way, is an AXI slave.)
Run the auto connection.
Assign the right I/O pins to the GPIO port. (check your development system manual)
Build the system.
By the way you find the address of the peripheral in the address tab and it normally is 0x0080000000.
You wrote that you made a server (TCP/IP). "All" it has to do is write the received value to a register in the GPIO block. (Here I assume Xilinx has a document which describes how the GPIO block works and has example GPIO drivers.)

ttyusb/uart sends 'USB' during transfer

I am using Go for a project and am transmitting data to an embedded device via the serial port (ttyusb). During fast and "large" transfers I've noticed that the transmitted data did not match the values I'd wanted to send.
I've tried various available libraries, in the end they all read and write using syscalls. So I've attached a Logic Analyzer to see what's going on.
Then I noticed that the data mismatch in the output had a clear pattern: Instead of sending my data the serial port would interleave my data with the following values:
0x55, 0x53, 0x42, 0x53, 0x70, 0x02
Followed by zeros (0x00). In total 22 Bytes. The total number of bytes transmitted via the serial line did match the number of bytes I wanted to write > so essentially my data was masked with these 22 Byte-Blocks. The weird thing is that I can translate those bytes to ASCII
0x55, 0x53, 0x42, 0x53, 0x70 = "USBSp"
Now my Question is: Can't I send arbitrary data (HEX values) over the serial port or are there some control characters that I should be aware of that would make the serial port send out Identity information or the like?
[EDIT]: Additional Information:
Host is MacOS running Go v1.10; tried with go.bug.st/serial.v1 and github.com/tarm/serial, various communication settings (bitrate etc.)
Target is nRF52840 preview development kit, using Nordic nRF5 SDK v12.3.0_d7731ad (not the newest, I know, but the only one supporting other boards too). Using app_uart_x API
you have to configure the serial port. the settings for both devices for baud rate, start/stop bits, ... have to match. then there are libraries in go like https://github.com/jacobsa/go-serial that enable standard serial port communication with that you can also use any hex values.
i can not say why the USBSp is sent because you did not post any code and gave no information what libraries you use. very likely this is not generated by the kernel module and instead by higher layer software because the kernel module used is usb-serial and USBSp does not appear in the source code :
https://elixir.bootlin.com/linux/v4.0/source/drivers/usb/serial/usb-serial.c
also not in kernel module ftdi-sio ( if you use ftdi chip )
https://elixir.bootlin.com/linux/v4.0/source/drivers/usb/serial/ftdi_sio.c
and also not in https://elixir.bootlin.com/linux/v3.3/source/drivers/usb/core/urb.c

Test COM port LED custmer display using windows cmd

I buy customer display that customer display has PL-2303HXD chip. The customer display connect to COM1 to my PC.I can send any number using test software come with that customer display. but I can't display any value using cmd in windows.
In the manual ask to try
C: \> MODE COM1 2400, N, 8,1
C: \> TYPE CON> COM1
in cmd but that not work for me. please tell how can i test customer display using cmd in windows.
Instructions for application:
Use the standard RS232 serial port (baud rate= 2400, parity =none, data bits = 8, stop
bit = 1).
Use international ESC / POS Common set of commands, do not need to install any drivers. Both under DOS or WINDOWS platform, just follow the format of the commandset to send data to the serial port to display the content, without handshake.

Spartan 3ADSP device DNA read via JTAG

how to read device DNA for Spartan 3A DSP via JTAG cable using iMPACT tool ? and if any other methods available to cross check the code readead deviceDNA value, whether it is correct deviceDNA value of that device OR not?
There is a Xilinx AR for this:
AR# 40856 iMPACT- How can I read DNA from my FPGA with IMPACT?
For Spartan-3A series devices (Spartan-3A, Spartan-3AN
andSpartan-3ANDSP)
To read if the DNA iMPACT batch mode command is available. ("readDna -p <position>") How to get the Xilinx Device DNA via iMPACT
batch mode?
1. Generate iMPACT batch mode file say ".cmd" (in any ASCII text Editor) with following text commands in it. You can run this in
iMPACT batch mode. In the commands below, "X" denotes the position of
the targeted device.
setMode -bs
setCable -port auto
Identify
identifyMPM
Readdna -p X
exit
2.Run above generated file "readDNA.cmd" (ASCII text file) in IMPACT batch mode command line as:
Impact -batch <filename>.cmd
The above command will display the DNA number on the DOS command console.
Note: If FPGA is configured prior to read Device DNA via JTAG port then the value will be wrong. Please make sure that FPGA is not
configured from external Flash or JTAG device. To achieve this simply
change mode pins or erase the external Flash deviceand powercycle the
board.

I have 2 identical HID USB devices, each one has it's own control program, how can each program know which HID device is theres?

Is there a way to assign one HID device to a program and then another identical HID device to another program without each of them grabbing randomly the first HID device they enumerate? I'd need some kind of unique identifier. Is there such thing? On windows xp/vista/7.
The port is your default enumeration value. Configure your code to allow explicit specification of the port.
Depending on a uuid of a device is probably not going to give you the results you expect in the long run.

Resources