[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/diy/ - Do It Yourself

Search:


View post   

>> No.1772366 [View]
File: 90 KB, 2406x938, buggy rs232.png [View same] [iqdb] [saucenao] [google]
1772366

>>1772242
Ok, before all that, looks like the logic analyser was a good idea after all. Here I can see that the serial printouts end before the code's RS232 receiving stops functioning. It's also not printing anything to the text file, not even the "BEGINNING OF FILE" that should be there, so I'm reformat the card now. I increased the serial baudrate and now I'm not seeing the abrupt stops in the middle of serial.print() commands. I'm still getting the "serial prints every second symbol as 255" bug even though there shouldn't be any edge for it to trigger off and there's no room between some of the bytes for the required microsecond delays and no sign of the CTS line being pulled low as it processes the serial data. So it isn't a timing bug but something far stranger.
>>1772364 Ah, good to know, that explains what I'm seeing here.

Note that the funky looking $ and . signs are my custom interpretations of particular nonreadable ASCII symbols that make up the start of an HPGL datastream. They appear at the start but nowhere near the actual data I'm harvesting, so it isn't an issue.

This code used to work without crashing (but it still had the 255 bug) half a year ago, but now I've fleshed the code out to generate its own filenames to store the data in. Which at some point was working very well. It counts up the number of files on the SD card to number N, checks file "hpgl_[N-1].txt" to see if it exists. If it doesn't exist it makes it to write in. If it does exist but is empty it uses it to write in. If it does exist and already has over 15 bytes of data it makes the file "hpgl_[N].txt" to write in.

Navigation
View posts[+24][+48][+96]