Is it possible to use a baud rate of 4mb (B4000000) with Apple's FTDI driver? Or is FTDI's VCP driver better?
Speeds up to B230400 are defined in termios.h (*), with each speed being defined as the integer matching its speed (unlike Linux). However, the simple hack #define B4000000 4000000 does not work.
I remember being able to use 4mb with FTDI around 5 years ago (before Apple provided a driver) using FTDI's VCP driver and hacking FTDIUSBSerialDriver.kext/Contents/Info.plist to make one of the "allowed" speeds (like B2400) be aliased to 4mb by the driver. Is this still the recommended method? (I suppose this would require disabling kext security, with sudo nvram kext-dev-mode=1.)
I am using the baud rate like this, where serBaudRate is something like B2400 or (ideally) B4000000.
if ((fd = open(serPortName, O_RDWR)) < 0) { perror("aborting"); return; }
tcgetattr(fd, &tty); /* get attributes */
cfsetospeed(&tty, (speed_t) serBaudRate); /* output speed */
cfsetispeed(&tty, (speed_t) serBaudRate); /* input speed */
tcsetattr(fd, TCSANOW, &tty); /* set attributes */
(*) the full path is /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/sys/termios.h
I remember being able to use 4mb with FTDI around 5 years ago (before
Apple provided a driver) using FTDI's VCP driver and hacking
FTDIUSBSerialDriver.kext/Contents/Info.plist to make one of the
"allowed" speeds (like B2400) be aliased to 4mb by the driver. Is this
still the recommended method? (I suppose this would require disabling
kext security, with sudo nvram kext-dev-mode=1.)
I suspect this is the only way to do it. The Apple driver is pretty basic (as of a few years ago it didn't even support CTS/RTS signals) and I don't see any way to specify a non-standard baud rate. Looks like the FTDI Info.plist still supports those baud rate config options too.
Related
I'm working on communicating embedded device via serial port for debug. The device supports only 1843200 bps for baud rate.
But, my usual terminal softwares (minicom, Teraterm) don't look like supporting such high baud rate as they are.
What I want to do using such terminal software is:
sending command string interactively
transporting file to the device
Thank you.
As I commented, I solved the problem myself and post it again.
Teraterm ... high baudrate can be set from CUI (command line), not GUI (926100, max).
teratermpro.exe /BAUD=1843200 /C=1
PuTTy ... Using "plink.exe" works with options like below:
plink.exe -serial \.\COM1 -sercfg 1843200,8,n,1,N
But, you could have to stop "plink" once by Ctrl-c and type like below:
plink.exe -serial com1 -sercfg 1843200,8,n,1,N < [file path]
Regarding Linux, I didn't find the way. It could be that the proper driver should be installed.
#thebusybee Thank you for your kind advice!
What baudrate that is supported by a certain UART device depends on hardware:
How high the clock source for the UART clock go.
What prescalers/divisors the UART hardware support when translating the clock source to it's own hardware peripheral clock.
Some general rule of thumb is that divisors should not give more than 3% inaccuracy from the requested baudrate. More than that and you risk spurious data corruption, framing errors and similar.
Therefore software might limit the number of supported baudrates, not to correct higher ones that will be wildly inaccurate anyway.
Needless to say your embedded device also needs good clock accuracy, so if you are clocking it from something like an internal RC oscillator while running UART at 1.8MHz, you are very likely doing it wrong.
In ttermpro you can manually set the desired baudrate even if it does not show up in the drop-down list. Just type it into the field.
I just started with microchip world.
I'm about to buy a PicKit3 and i've seen it can outputs from 1.8V to 14V MCLR.
The pic i will use is the PIC16F1829 and it should work with MCLR # 5V.
In the datasheet it seems i would need a zener/shunt to limit the voltage.
First of all isn't there a board ready to play with?
Can i use LVP? If so using MPLab 8 IDE how do i change in LVP?
Is the pin connection the same?
Since i haven't bought it yet i would rather avoid burning a pic
Regards,
Notes at the bottom of page 345 in the PIC16F1829 data sheet (DS40001440E) recommends using a voltage limit circuit when using the ICD2 device programmer.
According to Microchip this is "not required" when using the PICkit3.
Get a few extra PIC16F1829 just in case.
You ask about boards ready to use, take a look at the Curisotiy Nano boards
https://www.microforum.cc/topic/9-microchip-xpress-evaluation-boards
These are ready to use and do not need any programmer. You can simply send a file to these devices over USB. They are also have debugging capability.
In terms of the 14V on MCLR, the device is designed to handle whatever pulse will be generated by the PICkit3, so you do not need any protection for the PIC against that. In fact limiting the voltage on that pin will prevent the device from programming so you definitely do not want to do that. If you are however using this pin to connect to other parts on your board the other parts probably will need protection.
You can most definitely use LVP, just be careful, it is possible to use LVP to disable LVP, and then the only way to get it back on is to use HVP!
Lastly in the IDE under programming options you can change the mode there (Use low voltage programming mode entry)
In the IDE i've set the voltage appropriately and everything went ok on its own.
I didn't have to enable anything fancy
Coming form this question yesterday, I decided to port this library to my board. I was aware that I needed to change something, so I compiled the library, call it on a small program and see what happens. The 1st problem is here:
// Check for GPIO and peripheral addresses from device tree.
// Adapted from code in the RPi.GPIO library at:
// http://sourceforge.net/p/raspberry-gpio-python/
FILE *fp = fopen("/proc/device-tree/soc/ranges", "rb");
if (fp == NULL) {
return MMIO_ERROR_OFFSET;
}
This lib is aimed for Rpi, os the structure of the system on my board is not the same. So I was wondering if somebody could tell me where I could find this file or how it looks like so I can find it by my self in order to proceed the job.
Thanks.
You don't necessarily want that "file" (or more precisely /proc node).
The code this is found in is setting up to do direct memory mapped I/O using what appears to be a pi-specific gpio-flavored version of the /dev/mem type of device driver for exposing hardware special function registers to userspace.
To port this to your board, you would need to first determine if there is a /dev/mem or similar capability in your kernel which you can activate. Then you would need to determine the appropriate I/O registers for GPIO pins. The pi-specific code is reading the Device Tree to figure this out, but there are other ways, for example you can manually read the programmer's manual of the SoC on which you are running.
Another approach you can consider is adding some small microcontroller (or yes, barebones ***duino) to the system, and using that to collect information from various sensors and peripherals. This can then be forwarded to the SoC over a UART link, or queried out via I2C or similar - add a small amount of cost and some degree of bottleneck, but also means that the software on the SoC then becomes very portable - to a different comparable chip, or perhaps even to run on a desktop PC during development.
On old iMX.6 BSP without DT (Device Tree), GPIO is controlled by following code:
#define SABRESD_SHUTDOWN IMX_GPIO_NR(4, 15)
gpio_request(SABRESD_SHUTDOWN, "shutdown");
gpio_direction_output(SABRESD_SHUTDOWN, 1);
gpio_set_value(SABRESD_SHUTDOWN, 0);
gpio_free(SABRESD_SHUTDOWN);
However on new BSP, I cannot use IMX_GPIO_NR anymore. Instead, of_get_named_gpio provides access to GPIO defined in DT. But it is a little complicated because our product never changes the GPIO ports.
My question is, is it possible to control GPIOs without DT definition (just using the old method)?
First of all, if you are using newer kernel, I would recommend you to port your code to support the latest features. Otherwise - why bothering upgrading the kernel if you are not willing to adapt to it?
Second, never say never.
And finally:
#define IMX_GPIO_NR(bank, nr) (((bank) - 1) * 32 + (nr))
I am using Arduino Leonardo to transmit an string to a wifi module. The format of command that wifi module can recognize is:
AT60,1,content to a server
I am using an virtual server(TCP/IP Builder) to test the content I can received.
Here is the content I want to send:
smart/device/deviceCmd?userId=1010002003&deviceId=A00019999990002&cmd=ON
Since I try to send it again and again, I use a loop to send it. In the virtual server side, the content I got is:
smart/device/deviceCmd?userId=1010002003&devceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&devceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&eviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&devieId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003deviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&deiceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
This is the QUESTION: There exist one terrible mistake in the content I received, which is the deviceId part never correct. It's so weird.
Here is part of related code:
//In Uart.cpp
//These three lines can sent a formatted string as "AT60,1,content"
Serial1.write("AT60,");
Serial1.write(channelID); //channel ID = 1 here
Serial1.write(reportIsFire, 76);
//In Uart.h
//Definition of the string I need to send, which has 76 characters.
char reportIsFire[76] = ",smart/device/deviceCmd?userId=1010002003&deviceId=A00019999990002&cmd=ON \n";
Here is few background of this application:
I am using Arduino 1.5.8 IDE with VisualStudio
Since the serial buffer of Arduino is only 64 Bytes, I have already
change the buffer size to 128 Bytes in "HardwareSerial.h" to send
out this large string.
The baud rate is 115200 and I am using Serial 1. I have used Serial 1
to transmit few other characters and it works fine.
I will appreciate that If you have any idea about this question.
I am betting that the serial baud rate of the Arduino is not 100% correct. Increasing the buffer size will not matter if the data is being lost due to a timing issue in the physical link.
I'd recommend double-checking the code that initializes the serial baud rate generator. It may be possible to get a closer rate to 115,200 by either adjusting the available settings, altering the main clock speed (if possible), implementing some form of flow control, or all of the above.
In extreme cases, you may consider using a special-frequency oscillator. Many Microchip PICs use an internal or external 4MHz or 8MHz crystal, but this can produce far too much timing error for lengthy serial transmissions at high speed. In that case, something special, like a 7.3728MHz crystal can be used, bringing the accuracy to exactly 100% (at least on some PIC devices.)
Lastly, another consideration is if any pre-emptive code is running on the device, such as interrupts or timers which could inadvertently interfere with the serial output.
I don't have an answer, but I suspect the most likely problem is that the Wifi card can't read characters at a sustained 115200 baud rate. If possible, set the Wifi baud rate and the Arduino Serial.begin() to a lower rate, such as 57600 or 19200.
If the Arduino baud rate was simply inaccurate, I'd expect to see the problem appearing at random locations in the string, rather than about 40 characters in.