I am writing a program using SDK 15.0.0.
I'm trying to merge SPI and TWI programs into BLE programs.
I used keil before to confirm that each program was working properly.However, since it exceeds 32k bytes when it merges, I decided to use Embedded studio.
TWI and SPI are programs that save the output value from the acceleration sensor to the SD card.
In keil I was able to write to the SD card normally, but in Embedded studio the character was not written.However, it turned out that the number of bytes originally intended to be written was secured by tab and line feed.The code is written as “f_write (& file, buf0, 5, (UINT *) & bytes_written);”, but it is possible that keil can write and Embedded studio can not write characters. Is it?Or simply my lack of settings?
Please tell me ignorant me.
Both Keil & SES are just IDEs with associated toolchains - they are both perfectly capable of generating working code for their intended Targets.
However, they are entirely different toolchains - so the generated code will not be identical.
The 3 top suspects would be:
The thing to do is to use the debuggers in both tools to examine what is happening in the working case, and see where the non-working case diverges.
Also use an analyser or oscilloscope on the interface lines - again, examine what is happening in the working case, and see where the non-working case diverges.
Have you tried using some unmodified SES examples from the SDK - to get you familiar with the setup, and give you a known-working basis to work from ?
Thank you for reply.
I will try to find out the cause.
I tried to try the fatfs only example in Embedded studio."L6218E: Undefined symbol __initial_sp (referred from entry2.o)"And could not be built successfully.I do not know the cause of this either.
I was able to compile the fatfs example in Embedded studio, but running it did not write numbers to the SD card.Blanks were written instead of numbers.I do not know the cause of thisHelp me...
y001 said:I do not know the cause of this
You need to find the cause - that's what debugging is all about!
awneil said:The thing to do is to use the debuggers in both tools to examine what is happening in the working case, and see where the non-working case diverges
awneil said:use an analyser or oscilloscope on the interface lines - again, examine what is happening in the working case, and see where the non-working case diverges
(can't get the stupid forum to do that in a single quote)
Debugging is a key part of software development - and, in fact, any kind of development!
How To Debug