Are there any soft debuggers for microcontrollers (say PIC24) something like GDB. My platform doesn't run Linux so can’t use GDB. More than a debugger I need to log data, something like what CCP does.
I have a PICKit2 but it does not support runtime watch window update, only on breakpoints my watch variables be updated.
Has anyone tried using MODBUS RTU for runtime data logging ?
Transmit your data over a serial bus and log it at the computer end. Many micros come with a UART so RS-232 messages could be logged by simply directing the serial input to a file (you might need a USB to serial converter, such as the FTDI devices/leads/cable assemblies based on them). Or use CAN bus or any other serial protocol that you can get an interface to your computer with, and possibly write your own logger.
Related
I'm having an issue connecting a serial device to an embedded device I'm writing code for.
The device I am writing has two serial ports, an incoming from my laptop, and an outgoing to an external device.
When I connect both terminals to my laptop and view the data, I get exactly the data I am expecting.
When I connect my laptop to the external device directly, I am getting exactly what I expect, and a response.
When I connect the laptop and the external device to the embedded device I am working on, the laptop sends data to it, it receives it, it passes it on to the external device. This works as expected.
However, the external device doesn't send back the response.
If I send data to the external device from the embedded device, each new message I send allows it to send the original reply.
I know the first message got through correctly because the external device whirrs to live, and I know when it is sending the response by running and logic analyser on the tx/rx comms and viewing the traffic.
I considered that the embedded device is holding the rx line and preventing its transmission, but I don't see how that possible in the code. Also if that is the case it shouldn't work when I plug both lines into my laptop.
I also considered the DTR was not set high, but checked this and it appears to be set high.
Does anyone know a reason which would prevent a device from responding?
Note: When I say Serial Ports I am referring to the UART when referring to the embedded device. All device use a DB9 connector running RS232.
Edit: Operating System on laptop is Windows 10. Embedded device is a Atmega324p.
Edit 2: Did some more testing. It appears that it sometimes work and sometimes doesn't.
I have added an image which show a almost perfect signal of the response.
The blue section is a gap in the signal that shouldn't be there.
Ended up finding a solution.
The RTS line was held via the embedded device at 1.2v, while the Pc was holding it at 5.2v.
Pulling the RTS line up to 5v fixed the issue.
I'm using stm32l151 and I want to use usb peripheral in cdc mode. I used stm32 cubeMx to generate the project. however the function CDC_Transmit_FS() always return USBD_BUSY. can anyone help me?
Here is my code:
while (1)
{
CDC_Transmit_FS(Buffer, 6);
HAL_Delay(2000);
}
I only added the above code to the project created by STM32cubeMX but it didn't work.
STM library is buggy and it stalls when you for example try to send many larger packets of data.
There is a problem with the windows drivers and there are quite long delays between packets. So 12MB is quite difficult to archive - using CubeMx I could only have about 3-4Mb (12MB when packet is sent).
Another problem I had - I needed to send some data to the device bofore I could transmit next packet (max 8kB in my case), otherwise it stalled randomly.
Fortunately, the problem is solved and I can receive data in the PC from the STM32. There was a problem in my terminal software. I used serial port manitor to monitor the received data from the serial port, however this serial monitor software do not open the serial port by itself and if any other software opens the serial port and receives the data, it monitors data receptions. I didn't know that.
Thanks
I have LPC2148 daughter board but I am not able to dump/burn code into it, and it doesn't have any usb connector to dump code.
I read on internet by using FT232RL I can able dump code into LPC2148 but I am not able to do so.
please give me solution
thank you..!
The chip supports In-System Programming (ISP) via an on-chip boot loader ROM.
From the User Manual UM10139:
Programming of the Flash memory may be accomplished in several ways:
over the serial built-in JTAG interface, using In System Programming
(ISP) and UART0, or by means of In Application Programming (IAP)
capabilities.
The function of the FT232RL you mentioned is to act as a USB/UART bridge and is necessary primarily because modern PCs lack legacy RS-232 serial ports. You can in fact purchase a USB-Serial cable or adapter which will contain a bridge chip such as the FT232RL. Most of these use RS-232 line level signals, so you would still need an RS-232 line driver/receiver to connect then to your board (if your board has a serial port, it probably already has a line transceiver and you can connect directly to that). It is possible from specialist suppliers including FTDI themselves to get a USB cable with integrated FT232 and bare TTL level connections to connect directly to LPC2148 UART0 Rx/Tx lines.
If your board does not already expose a UART0 serial port and the necessart control to start the boot loader, a Serial Port Bootloader Interface board is available. For that you may then also need a USB/Serial adapter or a PC with a legacy serial ports.
Once you have a suitable serial connection, you will need the LPC2000 Flash Utility software to run on the PC.
The JTAG option is however faster, and more powerful since the JTAG is both a programming and debugging port. With a suitable toolchain and JTAG adapter it is possible to program and execute code with source-level PC hosted debugging including break pointing, data watching and single stepping of the code.
I wish to read the EUI64 address from an AT24MAC602 memory chip interfaced to an Atmega128rfa1 MCU over the Two wire interface. I tried to modify the I2C master drivers which are available for other platforms to suit my need. However, I wasn't able to carry out these modifications successfully as the program stopped responding as soon as the slave address was written to the twi bus with Write flag set. I failed to uncover the underlying reasons for the same.
As Contiki OS is quite popular, i thought someone might have already come up with contiki specific libraries for reading writing over TWI interface for Atmega128rfa1 MCU. If so, please provide pointers to the twi drivers or documentation for the same, or suggest factors that should be considered for developing such drivers. Thank you.
If you don't have any luck finding/creating a driver for the TWI peripheral, you might consider emulating it by configuring the SDA/SCL pins as general I/O and then implementing the TWI protocol yourself. If you're just doing a one-time read of a chip ID then speed probably isn't a big concern, so this could work if you get desperate. Google should throw up a few examples of emulated TWI.
I am doing IO programming in C in Ubuntu. And I need the base address of the port to write data.
My laptop dont have a parallel port. So I bought a USB to Parallel port connector. I plugged in the device and its getting detected in /dev/usb/lp0
I ran "lsusb" to see the list of devices and I can see the ID also. But how can I get the base address ? For the usual hardware parallel devices, the base address is 0x0378. this address is not getting detected while using USB to Parallel device.
Please help.
A USB parallel port doesn't have a base address - it's not a meaningful concept for USB. I'm afraid the days of doing I/O on PC hardware via in and out instructions ended a few years ago, though lots of old tutorials still survive on the web.
You can write bytes to the parallel port as a character device, and these will appear on the printer port pins. The USB adapter will expect the other end to handshake data exactly like a printer. If you want to do general I/O prototyping, you're probably better off with a simple USB microcontroller like an Arduino.
Further discussion here.
If you are still interested to use this USB-to-parallel-printer device for your own bit-banging, it's important to know that their built-in firmware always allows controlling of D0..D7, INIT (as outputs), /ERR, ONL, PE (as inputs), but never for /ACK, BUSY (inputs), /STB, /AF, /SEL (outputs) pins.
And you need an 8-bit latch (e.g. 74HCT574) for catching data while strobing.
See here (https://www-user.tu-chemnitz.de/~ygu/bastelecke/PC/USB2LPT/faq#DIY)
especially for possible data rates.
Accessing from software side is a bit complicated but possible, and you may have to re-structure your software and hardware for making such adapters useable. I don't know for Linux case how to access, but IMHO you don't need to write a kernel-mode driver.