128K is not enough!

So this should not happen for the electron right? or this board have also a wifi?

Bye.

That's a pretty bold statement to make without backing it up with some reasons. Sure, that Mediatek dev board has some impressive stats, but a given project doesn't always need all those features. If all I need to do is monitor a sensor and trigger a relay, I might as well just use an ATTiny45, or something, and save myself $58.

5 Likes

Noob me here.
For the Photon…
Wondering why the protocol stack for WiFi (or 802.15.4, etc) isn’t on its radio chip’s MCU as is done in all the chips I’ve seen of late. You have the choice to co-mingle other code, or use a UART/SPI and a co-processor.

or did I misunderstand the 240KB of flash remark.

Fuzzy on how the BCM43362 fits in this architecture and if it runs the stack, and the ST32 ARM is a co-processor why is it loaded up with 240KB?

1 Like

The problem here is that the Photon that shoul be far more powerful than the tensy leave the developer the same limitations that the teensy have: in a single word ROM SPACE.

Bye.

The 240kB is actually patches to the mask ROM code already in the 43362; this needs to be loaded into the 43362 on every boot to make it operational. The 43362 takes care of the 802.11 protocol stack, including a WPA supplicant - it doesn’t do any TCP stuff though… and IMO that’s a very, very good thing.

3 Likes

Is the 240KB of code destined for the 43362 merely stored in the flash of the ARM MCU to be copied to the 44362?
If so, couldn’t such code be put in a $1 SPI flash chip and the 44362 could retrieve it from that storage?

1 Like

The 43362 can’t boot from a SPI flash but yes, you can certainly store the image somewhere else than in on-chip STM32 flash; the problem is only the P1 has on-module SPI flash, which would require every P0 user to add a compliant SPI chip. Our designs do this for one of the redundant copies.

1 Like

Is there any new methods to allow bigger user firmware size?
I am compiling locally, so I am able to change the core firmware.
I would need to use cloud so I can not remove it, but is that right removing sprintf from the core will allow additional 20kb? If yes, how to remove it?
Is there any other part of the core that can be removed? Maybe a list of the function with sizes?

Thanks!

@atom, are you asking in regards to a Spark Core or newer devices? There is currently no way to remove modules from any DeviceOS to reduce its size.

Thanks for your reply. I am asking about Photon.

Hi again!

Still there is no way to delete any modules to increase the user flash size?
I just can not believe it is not possible, if I build locally.
Or if I move some of my modules to the firmware? Is it possible?
I have tried the following:
In my code I do not use json, but I added for test
inserted in the void setup():

char buf33[100];
memset(buf33, 0, sizeof(buf33));
JSONBufferWriter writer(buf33, sizeof(buf33) - 1);

writer.beginObject();
writer.name("d").value(10.5);
writer.endObject();

I locally compiled it successfully.
Then I deleted the file:
spark_wiring_json.cpp from /src/firmware/wiring/src
Then I tried to compile it but I got error that the JSONBufferWriter is missing.
Then I deleted the code from the setup, and I could compiled it again successfully.

So why can I just delete the spark_wiring_json.cpp? and increase the user flash size?

Thanks!