[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] Contributing and coding standards?
|
Hey Daniel,
Your board is an utter powerhouse compared to ones on which I have
deployed the "full" Paho C library!!!
For comparison, just a few years back I successfully deployed the Paho C
library on an _ancient_ ARM9TDMI processor running:
200MHz with 32MB flash and 32MB RAM, with 8kB caches!!!
It used Linux 2.6 and gcc 4.2.
Mosquitto was also running on the board to create an internal
message/event bus, and I used Redis for MQTT message persistence and
SQLite for longer-term storage. The board was also collecting,
aggregating, and transmitting a fair amount of data.
The performance of the Paho library was never an issue.
So you should give it a try before attempting to transform the Embedded
C library into something different than it was meant to be.
Frank
On 12/3/18 5:10 PM, Daniel Santos wrote:
Sorry for the late response. I just got over being sick and catching up
today.
Having the ability to run the full Paho C library doesn't making it
automatically make it prudent. In my case I'm running a MIPS32KEc with
256MiB of ram. This is a 580 HMz cpu with 64KiB of i-cache and 32KiB of
d-cache and my MQTT stuff is only a very small part of what is running
on the board. The larger my footprint, the less I'll be able to do
before saturating the CPU, either due to execution of instructions or
cache misses. Having a certain amount of free RAM is important to the
kernel (Linux in my case) being able to allocate optimally sized buffers.
Daniel
On 11/16/18 9:44 AM, Frank Pagliughi wrote:
Just out of curiosity, why are you folks looking at the Embedded C
library if you have a POSIX system rather than the Paho C library?
Frank
On 11/15/18 7:34 PM, Greg Troxel wrote:
I definitely am in favor of writing to the POSIX spec instead of linux
man pages. That gets you portability to a huge range of systems,
including ones you don't even know exist.
Usually, libraries are written to POSIX, perhaps relying on as little as
necessary. But, there are platforms which are much less than POSIX,
like the Arduino IDE. I am not quite clear on if your platform is not
posix (an unhosted environment like one might have with the Arduino
IDE?) or if you are just wanting things to be leaner. It seems to me
that lean, and a non-POSIX environment are two separate issues, and that
lean would benefit almost everyone, especially if the issue is CPU and
memory use vs code size.
About socket and timer: when designing for arbitrary less-than-POSIX
environments where you try to assume C99 (or C++NN) and no further, you
run into needing various things that aren't in that spec, and then
defining interfaces that the platform has to define to use the library.
I think that's what you mean about Socket and Timer.
I would suggest, without certainty, that if you need something that
exists in POSIX (like sockets), that you consider using that or a
defined subset, and then ask the platform to define the calls that POSIX
expects. This reduces brain effort for readers, as they know the
interface, and you will probably find that many systems that are C99 but
not POSIX do various things that are posixy the posix way.
Also, it may be good to have the platform API in C, not C++ - but that
may be my old-school bias showing.
Hope this helps...
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/paho-dev
