61 receive responses from a tcp server 2 #74
Conversation
calebbourg
changed the base branch from
main
to
more_robust_wait_response_cmd
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
calebbourg
force-pushed
the
61-receive-responses-from-a-tcp-server_2
branch
from
96834b0 to
cc4c417
Compare
| fn set_dns_config(&mut self, dns1: IpAddress, dns2: Option<IpAddress>) -> Result<(), Error>; | ||
| fn req_host_by_name(&mut self, hostname: &str) -> Result<u8, Error>; | ||
| fn get_host_by_name(&mut self) -> Result<[u8; MAX_NINA_RESPONSE_LENGTH], Error>; | ||
| fn get_host_by_name(&mut self) -> Result<NinaResponseBuffer, Error>; |
There was a problem hiding this comment.
One idea of mine, perhaps we could have a couple of different NinaResponseBuffer types:
- A shorter one, 255 bytes in length and maybe called
SmallNinaResponseBuffer - A larger one intended for things like HTTP response documents and maybe called
LargeNinaResponseBuffer
The type that we always specify in these method definitions would implement a NinaResponseBuffer trait and then we could make the return type be a generic.
esp32-wroom-rp/src/spi.rs
Outdated
| // return Err(ProtocolError::TooManyParameters.into()); | ||
| // } | ||
|
|
||
| let mut response_param_buffer: NinaResponseBuffer = [0; MAX_NINA_RESPONSE_LENGTH]; |
There was a problem hiding this comment.
And then per my comment above about a generic NinaResponseBuffer trait/type, this could instantiate a LargeNinaResponseBuffer.
esp32-wroom-rp/src/spi.rs
Outdated
|
|
||
| fn receive_data(&mut self, socket: Socket) -> Result<NinaResponseBuffer, Error> { | ||
| self.avail_data_tcp(socket); | ||
| let mut response_param_buffer: NinaResponseBuffer = [0; MAX_NINA_RESPONSE_LENGTH]; |
There was a problem hiding this comment.
And per my comment above, this would instantiate a SmallNinaResponseBuffer.
calebbourg
force-pushed
the
61-receive-responses-from-a-tcp-server_2
branch
from
a8888fd to
55a4fac
Compare
…ry string output of the result response buffer
…ring is correct for read_response16's buf read length
… is working but more debugging around response payloads of length 5744+ still need to be figured out why those don't yet work.
| operation.command as u8 | ||
| ); | ||
| self.control_pins.esp_deselect(); | ||
| return e; |
Check warning
Code scanning / clippy
unneeded `return` statement
| let (current_length, response_buffer) = | ||
| self.get_data_buf_tcp(socket, available_data_length)?; | ||
|
|
||
| for i in 0..(current_length - 1) { |
Check warning
Code scanning / clippy
the loop variable `i` is only used to index `response_buffer`
2 participants
Description
describe the intent of your changes here and/or what problem this tries to solve
GitHub Issue: link your GitHub issue here
Changes
Testing Strategy
describe how you or someone else can test and verify the changes
Concerns
describe any concerns that might be worth mentioning or discussing