SPI SDcard 를 가지고 파일을 입출력 하는 것을 해봤다.
그 중 문자열에 CR (Carriage Return) LF (Line Feed) 은
보내는 쪽과 받는 쪽에서 서로 약속을 해줘야 한다.
그렇지 않으면 메모리 낭비라던가 문자열을 Parsing(문자열 추출)할 때 원하는 데이터를 가져오기 힘들 것이다.
그래, 저번에 해본 f_write, f_puts 와 f_read, f_gets 를 통해 문자열을 비교해보자.
사실 f_puts 는 리턴값이 제대로 Write 가 되었다면
쓴 길이 (pb->nchr) 를 반환하고
그렇지 않으면 EOF 를 반환한다.
그래서 저 위에서 처럼 "fres = " 사용 안하는게 맞다.
반환한 크기는 NULL 까지 포함한 크기다.
sprintf((char*)buffer, "%s", text);
for (uint8_t i = 0; i < 3; i++){
f_puts(buffer, &fil);
}
f_read 는 신기한것이 문장을 \r\n 또는 \n 을 넣어서 띄우면 뭔가 하나가 더 추가된다는 것이다. 한 문장이 끝나서 \0 같은 것을 읽어온건지 어떻게 한번만 쓰면 문서 전체를 읽는지 연구해봐야겠다.
코드
Line Feed 만 추가한 것이다.
있는 그대로 잘 읽어온다.
Carriage Return 이 없어서 바로 뒤에 붙는 모습이다.
둘다 사용하면 한 줄이 붕 뜬다.
텍스트 파일에서는 한줄 더 떨어졌지만 여기서는 잘 읽힌다.
f_puts와 CR, LF면 한줄이 더 떨어지는데 그 간격만큼 벌어지는 것 같다.
CR, LF 가 없는만큼 연달아 써진다.
제대로 잘 읽힌다.
역시 잘 읽힌다.
3줄로 깔끔하게 써진다.
CR 이 부족한 모습이다.
CR 이 부족한 느낌이다.
맨 아래 문자열 밑줄까지 CR 과 LF 가 잘 적용되었다.
잘 읽힌다.
읽은 마지막 줄에 한줄 떨어져 보이는 것은 \r\n----READING_TEXT----\r\n 으로 했기 때문이다.
CR 이 있음에도 제대로 안 읽힌다.
출력 쪽 문자열에는 아무 것도 안 붙인다는 가정하에
읽기와 쓰기가 일치하는 것에 ◎를 붙인다.
None | f_puts | f_write |
---|---|---|
f_read | ◎ | ◎ |
f_gets | ◎ | ◎ |
LF | f_puts | f_write |
---|---|---|
f_read | ◎ | |
f_gets |
CR, LF | f_puts | f_write |
---|---|---|
f_read | ◎ | |
f_gets |
여러줄을 일부러 붙여서 사용하는 경우는 거의 없다.
쓰는 쪽과 읽는 쪽이 정해놓고 사용해야하며
파일을 작성하기 위해
정해진 크기만큼 쓰는 f_write 는
따로 코드를 추가해 문자열의 길이를 넣어서
메모리 낭비를 줄여야 한다.
그에 반해
f_puts 는 쓴 만큼만 메모리를 사용한다.
하지만 리턴값이 FRESULT 라는 구조체가 아니라서
얼마나 메모리를 사용했는지
데이터가 잘 써졌는지 Error check 하는 함수를 만들어야한다.
터미널을 통해 읽어오는 건
당연히 f_read 가 간편하고 코드도 짧다.
평소 STM32 를 다루는 사람이라며 \r\n을 사용 -> f_write
아두이노에서 넘어왔거나 C언어만 했다. -> f_puts
터미널 읽기는 -> f_read
아직 미숙하지만 열심히 작성한 코드이다. ▼
[Github Code]