API for serial functions
is there a document that outlines the exact expected behavior of the serial functions ? specifically, i'm looking to see if the serial_putc() function is supposed to wait until the character it is given has been fully transmitted over the wire, or if it is simply required to queue the character up into the hardware fifo and then return ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071001/09b125ed/attachment.pgp
Dear Mike,
Quoted 3 lines · in message <[email protected]> you wrote:
is there a document that outlines the exact expected behavior of the serial functions ? specifically, i'm looking to see if the
serial_putc()function
There is no such document...
Quoted 3 lines
is supposed to wait until the character it is given has been fully transmitted over the wire, or if it is simply required to queue the character up into the hardware fifo and then return ...
While it's not a strict requirement, I would expect that you wait until the charatcer has been sent. You have toi add some wait anway - either at the start or at the end of the function, and from the debugging point of view it makes more sense to wait for completion before continuing. Performancewise there will be no difference, I think.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise."
- Larry Wall in <[email protected]>Quoted 8 lines · Wolfgang Denk
Dear Mike,
Quoted 3 lines · in message <[email protected]> you wrote:
is there a document that outlines the exact expected behavior of the serial functions ? specifically, i'm looking to see if the
serial_putc()functionThere is no such document...
oh well :/
Quoted 10 lines
Quoted 3 lines
is supposed to wait until the character it is given has been fully transmitted over the wire, or if it is simply required to queue the character up into the hardware fifo and then return ...
While it's not a strict requirement, I would expect that you wait until the charatcer has been sent. You have toi add some wait anway - either at the start or at the end of the function, and from the debugging point of view it makes more sense to wait for completion before continuing. Performancewise there will be no difference, I think.
the optimal performance method would be at the start of serial_putc(), spin until a byte has opened up in the hardware fifo, and then queue it up and return ... in the normal path, the leading spin would probably not execute even once as the hardware can go faster than people can type :)
then in the serial_setbrg() function (what does "brg" stand for anyways?), spin until both the fifo and the transmit register are empty so that you dont go changing the baud rate while a character is in the middle of transmission ...
the current Blackfin serial driver posts a character into the fifo and then spins until both the fifo and the transmit register is empty ... if there is no higher level API dictacting the requirement (and my quick tests here seem to back that up), then i'll just scrub the code and gain a little bit of speed and lose a few bytes in code size :)
thanks !
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071001/cf11448a/attachment.pgp
Hi Mike,
Quoted 17 lines · Mike Frysinger
Quoted 6 lines
While it's not a strict requirement, I would expect that you wait until the charatcer has been sent. You have toi add some wait anway - either at the start or at the end of the function, and from the debugging point of view it makes more sense to wait for completion before continuing. Performancewise there will be no difference, I think.
the optimal performance method would be at the start of
serial_putc(), spin until a byte has opened up in the hardware fifo, and then queue it up and return ... in the normal path, the leading spin would probably not execute even once as the hardware can go faster than people can type :)then in the
serial_setbrg()function (what does "brg" stand for anyways?), spin until both the fifo and the transmit register are empty so that you dont go changing the baud rate while a character is in the middle of transmission ...
Quoted 5 lines
the current Blackfin serial driver posts a character into the fifo and then spins until both the fifo and the transmit register is empty ... if there is no higher level API dictacting the requirement (and my quick tests here seem to back that up), then i'll just scrub the code and gain a little bit of speed and lose a few bytes in code size :)
I doubt that you will increase the "performance" notably by removing this check in the serial_putc routine. Please keep in mind that U-Boot is a bootloader, and while executing "printf" the CPU has nothing else to do.
But you will loose some debug functionality when removing this check, since you can't use printf anymore for debugging and really be sure, that the received output in your terminal program matches the CPU state.
So I vote for not removing this transmitter empty check.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
Quoted 26 lines · Stefan Roese
Hi Mike,
Quoted 17 lines · Mike Frysinger
Quoted 6 lines
While it's not a strict requirement, I would expect that you wait until the charatcer has been sent. You have toi add some wait anway - either at the start or at the end of the function, and from the debugging point of view it makes more sense to wait for completion before continuing. Performancewise there will be no difference, I think.
the optimal performance method would be at the start of
serial_putc(), spin until a byte has opened up in the hardware fifo, and then queue it up and return ... in the normal path, the leading spin would probably not execute even once as the hardware can go faster than people can type :)then in the
serial_setbrg()function (what does "brg" stand for anyways?), spin until both the fifo and the transmit register are empty so that you dont go changing the baud rate while a character is in the middle of transmission ...Quoted 5 lines
the current Blackfin serial driver posts a character into the fifo and then spins until both the fifo and the transmit register is empty ... if there is no higher level API dictacting the requirement (and my quick tests here seem to back that up), then i'll just scrub the code and gain a little bit of speed and lose a few bytes in code size :)
Quoted 3 lines
I doubt that you will increase the "performance" notably by removing this check in the
serial_putcroutine. Please keep in mind that U-Boot is a bootloader, and while executing "printf" the CPU has nothing else to do.
i'm not claiming this is going to turn a 100mhz proc into 1000mhz proc or something, but in the tail end of writing to the UART, you would free up the CPU to continue ... and the processor tends to be a lot faster than the speed of a UART, so it could chew through a sizable chunk of code before the UART finishes shifting out a single byte ... and depending on the hardware, you could be talking about 1 byte, 5 bytes, or more
Quoted 3 lines
But you will loose some debug functionality when removing this check, since you can't use printf anymore for debugging and really be sure, that the received output in your terminal program matches the CPU state.
maybe ... you'd have to mess up the processor pretty bad such that it breaks the peripherals ... the UART in a Blackfin acts independently of the core
Quoted 1 line
So I vote for not removing this transmitter empty check.
i'd note that this is pretty inconsistent across different ports ...
so when do you return ? after making sure the byte has moved from the core to the peripheral hardware ? after making sure the byte has started to be shifted out from the peripheral onto the line ? after making sure the byte has been completed shifted onto the line ? the current Blackfin serial driver exhibits the last -- it waits until the whole byte has gone through the whole process, from core through the line
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071001/29ad1fbc/attachment.pgp
Quoted 7 lines · In message <[email protected]> you wrote:
i'm not claiming this is going to turn a 100mhz proc into 1000mhz proc or something, but in the tail end of writing to the UART, you would free up the CPU to continue ... and the processor tends to be a lot faster than the speed of a UART, so it could chew through a sizable chunk of code before the UART finishes shifting out a single byte ... and depending on the hardware, you could be talking about 1 byte, 5 bytes, or more
So you might end up saving 1 or 5 or a few more milliseconds.
Quoted 6 lines
maybe ... you'd have to mess up the processor pretty bad such that it breaks the peripherals ... the UART in a Blackfin acts independently of the core
Quoted 1 line
So I vote for not removing this transmitter empty check.
i'd note that this is pretty inconsistent across different ports ...
I agree with Stefan. Please don't change this. The current implemen- tation (wait until trasmit has completed) is what I prefer.
Quoted 6 lines
so when do you return ? after making sure the byte has moved from the core to the peripheral hardware ? after making sure the byte has started to be shifted out from the peripheral onto the line ? after making sure the byte has been completed shifted onto the line ? the current Blackfin serial driver exhibits the last -- it waits until the whole byte has gone through the whole process, from core through the line
If that's how it was implemented, then leave it that way. It's OK.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Half of the people in the world are below average.
Quoted 7 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
Quoted 1 line
So I vote for not removing this transmitter empty check.
i'd note that this is pretty inconsistent across different ports ...
I agree with Stefan. Please don't change this. The current implemen- tation (wait until trasmit has completed) is what I prefer.
np ... as for non-Blackfin ports, it isnt my code so i dont care ;)
Quoted 8 lines
Quoted 6 lines
so when do you return ? after making sure the byte has moved from the core to the peripheral hardware ? after making sure the byte has started to be shifted out from the peripheral onto the line ? after making sure the byte has been completed shifted onto the line ? the current Blackfin serial driver exhibits the last -- it waits until the whole byte has gone through the whole process, from core through the line
If that's how it was implemented, then leave it that way. It's OK.
there is plenty of code (on the Blackfin side) that was thrown together and left that way because "it just worked" rather than being correct ... so i dont buy the "this is how it was, so just leave it" argument
but if the behavior we want is "drain the byte completely across the line before returning", that's easy enough
thanks :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071001/c97516f8/attachment.pgp
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 7 lines
While it's not a strict requirement, I would expect that you wait until the charatcer has been sent. You have toi add some wait anway - either at the start or at the end of the function, and from the debugging point of view it makes more sense to wait for completion before continuing. Performancewise there will be no difference, I think.
the optimal performance method would be at the start of
serial_putc(), spin until a byte has opened up in the hardware fifo, and then queue it up and
Maybe. But in reality, you won;t be able to see a differecne in performance.
But the code will be more complicated and have a higher footprint, which both is a con.
Quoted 1 line
then in the
serial_setbrg()function (what does "brg" stand for anyways?),
Baud Rate Generator. This origins from the initial implementation on MPC8xx systems...
Quoted 2 lines
the current Blackfin serial driver posts a character into the fifo and then spins until both the fifo and the transmit register is empty ... if there is
I like this implementation. It's simple and straightforward, and you can rely on that the user has seen the caratcer on the line before the function returns. That's a good thing for initial debugging (board bring up).
Quoted 2 lines
no higher level API dictacting the requirement (and my quick tests here seem to back that up), then i'll just scrub the code and gain a little bit of
Please don't.
Quoted 1 line
speed and lose a few bytes in code size :)
Reduce code size? To me it seems the changes you described above would take more code.
Best regards,
Wolfgang Denk
Signature · 7 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The games have always strengthened us. Death becomes a familiar pattern. We don't fear it as you do. -- Proconsul Marcus Claudius, "Bread and Circuses", stardate 4041.2
Quoted 5 lines · Wolfgang Denk
Quoted 1 line · In message <[email protected]> you wrote:
speed and lose a few bytes in code size :)
Reduce code size? To me it seems the changes you described above would take more code.
the current code checks the hardware before sending the byte to the uart and then waits for it to drain ... i was looking at having just one check. but i guess you could argue that in theory, no byte should get into the uart that didnt come through serial_putc(), so the initial check is over kill and can be dropped
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20071001/a6eb82ff/attachment.pgp