Re: [uClinux-dev] serial port (RS-232) baudrate issue
Hi Greg, thank you for the accurate response. We use a Coldfire 5234. I have seen on the Coldfire manual and the uClinux code (kernel 2.6.x). Making some computations, we have seen that our 57600 baudrate is changed by our micro to 57165 bps. In fact, the formula to compute the divisor is: Divisor = BusClock / (32 * baudrate) In our case, BusClock = 75 Mhz, baudrate = 57600, so Divisor = 41. Thus, the real baudrate is 7500 / (32 * 41) = 57165 bps. We could try to change divisor to 40 to have a 58594 bps baudrate, but it's not so useful for our purposes. We will try other solutions. Thank you again Regards Salvatore Il 01/06/2011 3.38, Greg Ungerer ha scritto: Hi Salvatore, On 31/05/11 22:29, Salvatore Frizzoli - IMS Italy wrote: I have an issue to the RS232 serial port on a Coldfire board equipped with uClinux. I have set the serial port with a baudrate of 57600 bps, it is connected to a third-party device, but it doesn't work (all charachters are corrupted). If I connect a PC directly to the device with 57600 bps, it works. If the bps is put down to 19200, also the connection by the board works. Yeah, in most cases the ColdFire generated baud rates will not be very accurate. They are a simple division of the CPU clock, so it is easy to work out what exact baud rate you will see for a specific baud setting. And faster baud rates usually have larger errors. If you email your ColdFire CPU type and the clock you are driving it with we could quickly figure it out. (* One caveat is the 5272, which has a fine grained baud rate setting as well) This is due to the fact that the third party device probably has a baudrate lightly different from 57600 bps and the PC serail port can adjust its frequency according to the device one, while Coldfire cannot. My question is: is there a way to configure the serial port by uClinux such that also Coldfire can adjust its frequency? Alternatively, can I configure the serial port with a baudrate slightly different from the standard ones (for example: 57500 in place of 57600)? You could easily modify the clock and divisor code for the serial driver. Have a look at the code (depends on which kernel version where the driver source is linux-2.4.x/drivers/char/mcfserial.c, or linux-2.6.x/drivers/serial/mcf.c or even linux-2.6.x/drivers/tty/serial/mcf.c for the very latest 2.6 kernels). Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com -- Salvatore Frizzoli Software Developer Research& Development Department IMS srl Via Sagittario, 5 Fraz. Pontecchio Marconi 40037 Sasso Marconi (BO) Italy Tel. ++39 051 846851 Fax ++39 051 846856 mail: s f r i z z o l i (at) i m s i t a l y (dot) c o m http://www.imsitaly.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] serial port (RS-232) baudrate issue
Hi Salvatore, On 01/06/11 18:14, Salvatore Frizzoli - IMS Italy wrote: thank you for the accurate response. We use a Coldfire 5234. I have seen on the Coldfire manual and the uClinux code (kernel 2.6.x). Making some computations, we have seen that our 57600 baudrate is changed by our micro to 57165 bps. In fact, the formula to compute the divisor is: Divisor = BusClock / (32 * baudrate) In our case, BusClock = 75 Mhz, baudrate = 57600, so Divisor = 41. Thus, the real baudrate is 7500 / (32 * 41) = 57165 bps. Yep. We could try to change divisor to 40 to have a 58594 bps baudrate, but it's not so useful for our purposes. We will try other solutions. I have seen people use a different speed crystal that gives them more favorable divisors - and so more accurate baud rates. Not a solution that may be practical or useful to you though :-( Regards Greg Il 01/06/2011 3.38, Greg Ungerer ha scritto: Hi Salvatore, On 31/05/11 22:29, Salvatore Frizzoli - IMS Italy wrote: I have an issue to the RS232 serial port on a Coldfire board equipped with uClinux. I have set the serial port with a baudrate of 57600 bps, it is connected to a third-party device, but it doesn't work (all charachters are corrupted). If I connect a PC directly to the device with 57600 bps, it works. If the bps is put down to 19200, also the connection by the board works. Yeah, in most cases the ColdFire generated baud rates will not be very accurate. They are a simple division of the CPU clock, so it is easy to work out what exact baud rate you will see for a specific baud setting. And faster baud rates usually have larger errors. If you email your ColdFire CPU type and the clock you are driving it with we could quickly figure it out. (* One caveat is the 5272, which has a fine grained baud rate setting as well) This is due to the fact that the third party device probably has a baudrate lightly different from 57600 bps and the PC serail port can adjust its frequency according to the device one, while Coldfire cannot. My question is: is there a way to configure the serial port by uClinux such that also Coldfire can adjust its frequency? Alternatively, can I configure the serial port with a baudrate slightly different from the standard ones (for example: 57500 in place of 57600)? You could easily modify the clock and divisor code for the serial driver. Have a look at the code (depends on which kernel version where the driver source is linux-2.4.x/drivers/char/mcfserial.c, or linux-2.6.x/drivers/serial/mcf.c or even linux-2.6.x/drivers/tty/serial/mcf.c for the very latest 2.6 kernels). Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] serial port (RS-232) baudrate issue
On Wed, Jun 01, 2011 at 10:14:19AM +0200, Salvatore Frizzoli - IMS Italy wrote: > thank you for the accurate response. We use a Coldfire 5234. I have > seen on the Coldfire manual and the uClinux code (kernel 2.6.x). > Making some computations, we have seen that our 57600 baudrate is > changed by our micro to 57165 bps. In fact, the formula to compute > the divisor is: > > Divisor = BusClock / (32 * baudrate) > > In our case, BusClock = 75 Mhz, baudrate = 57600, so Divisor = 41. > Thus, the real baudrate is 7500 / (32 * 41) = 57165 bps. > We could try to change divisor to 40 to have a 58594 bps baudrate, > but it's not so useful for our purposes. > We will try other solutions. 57165 should be fine. As long as you are within +/- 2% it should be working. You are 0.7% off. We run a 5270 with a 75MHz bus clock and 57600 has never been an issue. 115200 is a bit flacky. If the other device is really badly designed and expects amazingly accurate baud then it isn't RS232 compliant (not that the standard really applies about 2 anyhow, but still). -- Len Sorensen ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Hi Geert, On 26/05/11 16:38, Geert Uytterhoeven wrote: On Thu, May 26, 2011 at 08:23, Greg Ungerer wrote: On 24/05/11 18:06, Andreas Schwab wrote: Geert Uytterhoeven áwrites: What exactly do you mean by "does not support anything less"? It seems it does restrict instruction generation to 68000 if you ask for it. The point is that Linux/m68k requires 68020+, so compiling for 68000 does not make sense (at least back when the gcc configuration was created). Yeah, used to be true :-) This seems very much to me to be a "broken compiler" issue. Is it worth putting some form of compiler version limits to protect compilation in the m68000 case? á(Probably no need to limit it for the existing 68020+ case). Are there any other gcc defines that we could use instead? We need to check with your old compiler Geert :-) I really don't want to use CONFIG_MMU here (or in bitops.h either). When I work in the ColdFire MMU code this won't be right. I was more thinking along the lines of !CONFIG_M68000&& !CONFIG_M68010 && !CONFIG_. Or in this case (and probably most cases) we could just switch to using the same positive logic. So what I had as: #if defined(__mc68020__) || defined(__mc68030__) || \ defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__) becomes #if defined(CONFIG_M68020) || defined(CONFIG_M68030) || \ defined(CONFIG_M68040) || defined(CONFIG_M68060) || \ defined(CONFIG_MCPU32) There currently isn't a CONFIG_MCPU32, but I could easily add that (we only have one CPU in that class currently supported, the 68360). The compiler setting won't matter, only what we configured. Sam will probably like this better, he suggested using the kernel configs initially, in http://www.spinics.net/lists/linux-m68k/msg03609.html I will prepare some patches that do this and see how they look. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
