NetBurner Community Forum

The SBL2E has a handy serial port function called SerialGetLine(). I tried using this to parse data coming into one of the ports and just about went nuts before I finally realized that it forces all lower case chars between "a" and "z" to upper case!!!&*^$%#&!!!!

This is not documented in section 9.4.2.3 of the SBL2e Programmers Guide where the function is described. The good news was that the culprit popped out as soon as I looked at the source. I'm using the interrupt-based serial routines: the actual function is IRQ_SerialGetLine(). Looks like the polled version does this too.

This could be useful, but perhaps controlled by an input parameter. If it stays this way, please update the documents NB guys. I'm still on Rel24_rc2, so maybe this is fixed in 2.50?

While I'm on the topic of the SBL2E serial functions, is there any rationale for not providing an fd when these serial ports are opened so we can easily use select() and the other typical file descriptor calls? Conserving memory space? I guess we could build up an IOexpandStruct, but I was surprised not to see it already done. Just wondering.

Finally, I notice that the usual read() and write() functions for the SBL2e are Read() and Write() and they seem to be methods limited for use w/ Tcp only. We have quite a bit of code written for the other platforms using the more generic read() and write() with the serial port fds so it's not a slam-dunk port to the SBL2e. Thoughts?

I read this in the online manual, first section:
"The SBL2e network libraries are designed to run in a very small amount of RAM, as low as 32k bytes. The most efficient use of memory is achieved through the use of function “callbacks”. A callback function is a function that is called through a function pointer. These are useful in small memory environments because it enables the TCP/IP stack to call your network function directly and avoid having copies of the data stored in additional memory buffers."

If you only have 32k bytes, there just isn't enough room for all the functionality you are referencing. The other platforms do not use a callback style stack, so I do not think any of your code will port over. This is a totally different stack. If you just considered what is needed for buffering on the serial ports and tcp sockets to support things like select() and unix style read() and write(), the ram would be waaaaaaaaaaaay too small. I would guess anything with a fd requires buffer space.

This part seems like a great low cost solution for very specific specific/simple solutions, but its not going to compete as a general purpose platform with lots of services running at the same time, no processors with small amounts of memory will. The other platforms have 8MBytes of ram, tons of room in comparison.