FYI: will be adding the offline toolchain here tomorrow
5 Likes
That is the best new 
Local and fast compiling 
Pokitto Server will be full up nice pokitto game in no time thanks to you
This makes me marvel at how the language had changed. When I went to school, on/off line were about available on a computer or not. So an “offline IDE” would be something like my 029 programming drum card, with support for both FORTRAN and ALGOLW!
2 Likes
I’m building the framework for the offline IDE info at the moment, heavy editing on the Pokitto.com site
1 Like
… going to take a little bit of time still, need to test it all works.
No major rush as far as I’m concerned.
As much as I’d like everything working, I’d rather wait and have it working well than have it rushed and falling apart.
Yea, the other thing known as life keeps interrupting the coding 
lets see if i still have a chance to fire up the computer tonight…
I did an overhaul of the wiki/tutorial sections of the main site. comments welcome.
3 Likes
Yes take your time.
We are exited but we also are father/mother with a family and kids
IRL is always the priority
1 Like
Oh wow:
As I’ve been trying to link the online and offline versions, I’ve finally found the way to make the mbed online IDE compile the “right way”.
This means I am able to dictate code placement in memory & size of binary file output. This was not the case when I was working on this earlier, when changes in scatter files did not actually change the output. At what point this has been fixed in the online IDE, I do not know.
Its good news because reliability of loading can be improved a lot now, and some of the issues that you all have faced can be fixed at the same time.
2 Likes
Success!!
The online IDE is now generating bootable binaries. The HEX output looks good, now I still need to test.
What I am doing is the online compiler is injecting the bootloader payload into the binary. In this way the bootloader will not be overwritten, which was the case when some of you reported problems. EDIT: this in turn was caused by the combined behaviour of the online IDE and the LPC11U68 rom bootloader.
Sorry for the delay with the offline tools, but once I get this thing fixed, we will have a nice solid base from which to maintain both online and offline compiling.
3 Likes
bootable binary confirmed in the online IDE. I see the loader sequence (C button does not does anything though) after updating the hello world project libraries
2 Likes
Thats good. I am working on it right now.
There is only one thing missing: I have a bootable verify mechanism that sits at 0x3FFF4 and describes the version and address of loader. But I cant get the damn bytes placed, because the compiler complains the bytes overrun the end of flash region (which is at 0x40000)
Theres a keyword, version number and address of loader. And for some reson the compiler is trying to place something AFTER these bytes, which results in “can not fit region” error at compile
EDIT: if anyone is familiar with;
Error: No space in execution regions with .ANY selector matching __dczerorl2.o(.text).
Then by all means let me know
Don’t know if this will help at all (I’m hoping it will spark an idea maybe).
Things that end up in the text section include:
- executable code
- constant values
- interrupt vector table
Perhaps the 0x3FFF4 area was already in use by something? E.g. perhaps something placed at an earlier address span across 0x3FFF4 and the compiler’s response is to try to move it after what you’re placing at 0x3FFF4.
It depends how the mechanism to place something at a specific address works.
Also, it won’t help but it might give you a laugh:
2 Likes
I know nothing about this, but my suggestion would be to temporarily move the bootable verify mechanism lower in memory (ie. 0x3ffe4 or 0x3ffd4 ) and see what is being written afterwards and how big it is.
This is what I’m trying to do. I understand GCC .ld but Keil scatter files are not so familiar to me
LR_IROM1 0x00000000 0x40000 { ; load region size_region (228k)
ER_IROM1 0x00000000 0x40000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
*(.ARM.__at_0x3FFF4) ; key
}
; 8_byte_aligned(16+47 vect * 4 bytes) = 0x100
; 32kB (0x8000) - 0x100 = 0x7F00
RW_IRAM1 (0x10000000+0x100) (0x8000-0x100) {
.ANY (+RW +ZI)
}
}
Now now… that would be giving in, wouldn’t it? No. We gotta beat this thing into submission!
Edit: your idea is completely workable though. If I do not find any other mechanism, I will just move the key. But then I have to do it with the offline compiler also.
1 Like
Could be wrong but:
0x40000 = 262144
262144(B) / 1024 = 256(KB) (more than 228K?)
Thats just a typo (the 228) … its in the comments. No effect
What is happening is there is some stdlib function defined somewhere (thats the __dczerorl2.o) , that has some “supreme right” to be placed after all of the other code. That code gets placed after the key, and causes the region overflow
1 Like
Research seems to indicate it’s the compiled form of “…/cmprslib/zerorunl2.c” or maybe “fpdiv.c”.
1 Like
Any idea why it always comes last in order? The online IDE does not output .map file, so I am in the dark as to why