#timvideos

Title: Snippet | IRCCloud (at www.irccloud.com)

shenki: https://github.com/timvideos/flterm/blob/master...

Title: flterm/flterm.c at master · timvideos/flterm · GitHub (at github.com)

mithro: https://github.com/timvideos/flterm/pull/4

Title: Fix parsing of line-ending option by shenki · Pull Request #4 · timvideos/flterm · GitHub (at github.com)

cr1901_modern: ping?

shenki: https://github.com/enjoy-digital/litex/blob/mas...

Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)

mithro: Pong. Sorry, I saw your message almost immediately, but didn't want to respond till I had some good news. First the bad news:

I didn't get much done the past week. libmodem still miscompiles and crashes at the tip of my HDMI2USB-litex-firmware tree.

Good news: I know for a fact that I introduced a compile option somewhere by accident that's causing the crash- idk what. In the interim, I forced using a known-to-work version of libmodem on the Opsis, otherwise compiling using the tip of my HDMI2USB-litex-firmware tree

Opsis firmware upload works!! Dual/Quad SPI bitbang works

So all I have to do is fix the miscompilation error (and add working timer to qemu) and we're good to go!

tumbleweed: ping?

mithro: pong

tumbleweed: So regarding, your new line pull request

yeah?

tumbleweed: I'm pretty sure the change to firmware/stdio_wrap.c is wrong?

tumbleweed: Either we should change firmware/stdio_wrap to do "\n" to "\r\n" replacement and remove "\r\n" from all the strings - or firmware/stdio_wrap shouldn't touch the strings and we should use "\r\n" everywhere?

oh, LF,CR?

tumbleweed: Hrm?

tumbleweed: I'm talking about this pull request -> https://github.com/timvideos/HDMI2USB-litex-fir...

Title: Use CRLF line-endings by stefanor · Pull Request #341 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com)

I'm asking what you think about that change is wrong

and I'm guessing it does LFCR

to answer your more general questino: yeah, there's no reason to use CRLF internally, if there's some kind of io driver for network or serial termianls that translates to CRLF

tumbleweed: Either we should change firmware/stdio_wrap to do "\n" to "\r\n" replacement always (and remove "\r\n" from all the strings) -- **or** we should use "\r\n" everywhere and firmware/stdio_wrap shouldn't touch the strings.

yes, I agree about that

but that does need coordination with the submodules

because there are prints all over the place

tumbleweed: I like the idea of firmware/stdio_wrap doing the translation because of the prints all over the place

yeah

tumbleweed: So, do you want to change that pull request to do that?

that is pretty much what it's doing

just not very elegantly

it changes all the (non-wrapped) printfs

if it did a little more inspection and translated '\r?\n' -> '\n' in the wrapper, then I could drop the changes to mdio.c

tumbleweed: Hrm? If you are doing the translation in stdio_wrap, we should remove all the other \r\n right?

no, because not everything uses the wrappers

the wrappers provide wprintf, but there are some printfs scattered around

tumbleweed: Where wprintf isn't used there is normally a special reason?

dunno?

tumbleweed: But the wprintf related should be fixed then?

not sure what you're asking

tumbleweed: If the wrapping functions are doing '\r\n', then we should remove all '\r\n' from the strings which are being sent to the functions?

sure

tumbleweed: Happy to merge it then

OK, I'll have a shot at it

string manipulation in C. So much fun

esp without dynamic memory allocation

the other way around (have everyone do CRLF everywhere, and translate to LF if needed) would be far simpler memory-wise :)

tumbleweed: Use static buffers?

yeah, I have to

(or call the wrapped prints multiple times)

I guess I'll crib the buffer size from the telnet bit

tumbleweed: Yeah - you can't call a function with va_list multiple times

that's true

tumbleweed: It appears to work at first until it doesn't