Jan, sorry for the debugger issue - it sounds like the debug info is stale: the installer should have removed the object and debug files so that it will do a Build before debugging and syncing the source code with the debug info file, but that does not appear to be the case. I will look into it. You should be able to do a Project->Rebuild and get everything syncs up.

re: low level details of I2C etc.: indeed, that's the whole purpose of the JumpStart API - to abstract away (some of) the low level details. Lets take I2c as an example. The actual I2C protocol is relatively simple, if you know how to toggle a square wave, that's the clock (SCL). Toggling another line and you have data (SDA). Do it with the right timing and sequence and there's your I2C. The problem is that with the complex 32-bit Cortex-M devices, it's no longer trivial to toggle a GPIO pin. You have to enable power to the correct bus, for a particular pin, set its mode to output, set open drain or push-pull (for I2C, it should be open drain), set the output speed, set the optional pull-up or pull-down resistor, and all that before you have to figure out how to generate the correct timing.

Or you can use the built-in I2C subsystem. Great! Except that to use the vendor library, you have to initialize a created structure with fields correspond to the IO register bits. So you end up having to look into the manual for details. Note that they don't bring enlightenment on how the I2C works or anything, it's simply a particular vendor's implementation of the I2C. For example, on the STM32F030, you can set up the subsystem to do "autoend". Wonderful, so you look at STM32F401, and behold, it has a completely different I2C implementation. There is no autoend, but arguably it's a more flexible implementation. So writing I2C on these two chips require completely different sequences of instructions. And these are from the same chip vendor, imagine you then move on to NXP LPC series. Writing I2C on top of them is basically making sure that you fully understand the manuals.

As I noted in one of my responses to the "Preview" article - our primary target audience is in fact professional engineers. Bit-banging I2C is no fun and it's not a whole lot of fun either to fight with the MCU's I2C subsystem. What they want and need are working I2C code so that they can work on their applications at hand. I2C, or any other low level protocols are for solving application programming and should not be the problem by themselves.

Again, JumpStart API does not preclude you from bit banging I2C or use the vendor supplied library. However, if your goal is to write a program to talk to an I2C device in as short a time as possible, JumpStart API is the solution.

Take another example: system clock set up. On every STM32F device's reference manual, there is a "clock tree" diagram. It's non-trivial to see which clock to use, and with all the prescalars and dividers, it's hard to find all the parameters to the PLL variables (some STM32F devices have 2 PLL "variables" and some have as many as 4). Indeed, ST's CubeMX is a valuable tool to see which path a clock may take and to calculate the correct values for PLLQ, PLLN, and so on.

Well, with our next release of the compiler, to be available by end of Nov 6, 2015, JumpStart API also supports the STM32F4xx series and adds a new clock call:

    _Bool JSAPI_CLOCK::SetSystemClock(unsigned hsi_mhz, unsigned hse_mhz, _Bool hse_bypass, unsigned pll_mhz, unsigned flash_ws);

You specify the HSI frequency, the optional HSE frequency, if you use an external OsC, and the desired PLL speed (plus a couple other parameters), and the function does all the calculations for you. Does it do everything you possibly want to do with the clock setup? Just like the I2C API, the answer is no. However, for most people, they just want to write "jsapi_clock.SetSystemClock(16, 0, false, 84, 5);" and have their F401 buzzing at 84 Mhz.

The question is: what would you rather do? Spend times just to get the basic structure going, which is completely useless if you move on to a different chip, even from the same silicon vendor, or spend time writing your application? Again, if the answer is latter, then JumpStart API is for you.

Richard, thanks for the reply.

I will try the rebuild the projects and report back (I did that for the OLED and RTC projects that were giving the error and it didn't help this morning, but I'll retry once more and see if it's gone).

On the JumpStart API and learning cycle:

I don't doubt that the API is a good one. The examples work good and fast. The code is clean. The granularity of the API functions looks alright. So as an abstraction API it works well. You can just see that by trying out the examples.

I'm a believer in abstraction (I've had some flack on forums for using abstraction libs/layers in the past, and I typically don't engage in discussion about good and bad because all the arguments pro and contra abstraction for embedded controllers can be found on various websites).

Where I have my doubts is: I'm not convinced that learning one particular abstraction layer -  your 'JumpStart' API  - without further drilling possibilities to see what's happening inside the controller and peripherals - is the right path to learn embedded.

I understand you want to protect your IP and not public code or allow a trainee to step through it. But it is a blocker for an educational kit that aims to be generic.

At this moment I feel that the learning path and horizon of the embedded programmer using the kit is restricted - and his decisions funneled towards the JumpStart API.

If the kit would be positioned as 'Kit to learn the JumpStart library and API on an ARM Cortex', I think you are achieving that.

As a kit marketed as a 'solution to teach embedded programming on an ARM Cortex' (and I think you position it as that when I read the kit's documentation), it doesn't feel alright for me.

Richard, thanks for the reply.

I will try the rebuild the projects and report back (I did that for the OLED and RTC projects that were giving the error and it didn't help this morning, but I'll retry once more and see if it's gone).

On the JumpStart API and learning cycle:

I don't doubt that the API is a good one. The examples work good and fast. The code is clean. The granularity of the API functions looks alright. So as an abstraction API it works well. You can just see that by trying out the examples.

I'm a believer in abstraction (I've had some flack on forums for using abstraction libs/layers in the past, and I typically don't engage in discussion about good and bad because all the arguments pro and contra abstraction for embedded controllers can be found on various websites).

Where I have my doubts is: I'm not convinced that learning one particular abstraction layer -  your 'JumpStart' API  - without further drilling possibilities to see what's happening inside the controller and peripherals - is the right path to learn embedded.

I understand you want to protect your IP and not public code or allow a trainee to step through it. But it is a blocker for an educational kit that aims to be generic.

At this moment I feel that the learning path and horizon of the embedded programmer using the kit is restricted - and his decisions funneled towards the JumpStart API.

If the kit would be positioned as 'Kit to learn the JumpStart library and API on an ARM Cortex', I think you are achieving that.

As a kit marketed as a 'solution to teach embedded programming on an ARM Cortex' (and I think you position it as that when I read the kit's documentation), it doesn't feel alright for me.

jancumps wrote:

 

...I will try the rebuild the projects and report back (I did that for the OLED and RTC projects that were giving the error and it didn't help this morning, but I'll retry once more and see if it's gone).

 

I retried and it doesn't help.

I used project ACE Shield Validation.

I did a Clean and a Rebuild.

I opened the main.c

Clicked line 39, SetupOLED() and have the errors below:

It's repeatable. If you want I can capture a video of how it happens.

(edit: note that it's complaining about RTC\main.c even though I have another project active. I've also done a rebuild of that RTC project)

(edit2: also occurs after doing the full install, making project RTC active, Clean & Rebuild, click on one of the source lines in main.c. I clicked on the margin of line 12 this time:

"Already have breakpoint at this address: break-insert C:\iccv8cortex\examples.JumpStartMicroBox\STM32F030\RTC\main.c:12"

)

Points taken re: JumpStart API. I will take your observation into consideration.

As for the debug issues, the debugger and I will contact you via email to see what's going on. There is no point in using the blog for this process. Once we clear the issues, you can report back.

Thanks

Richard Man wrote:

..l

There is no point in using the blog for this process. Once we clear the issues, you can report back.

 

Thanks

That's not how a review works. i will not continue this exercise when you say when I should or should not blog.

Feel free to revoke my license.

Dear Jan, I'm afraid there is a misunderstanding: I am not dictating how you should write your blog, I am just saying that for the ease of communicating, including possibly sending us log files so we can determine the cause of the problem, is best to do it via email. If you insist that we do it via comments on this blog, that is fine with me. The debugger person, Sid, will have to get an account, we will have to see whether we can duplicate your issue with our set up. If by chance that "it works for us" - which does happen as issues may be related to some configurations, we will need you to send us the log file. To begin with, enabled Settings->Debugger->Full Setting, then run the the debugger til the problem occurs. Then copy and paste the content of the debug window and ... well, you can post it as a comment if you wish.

Possibly we might even need the Windows message logs, in that case, you need to run the Windows dbgview program, which we install under c:\iccv8cortex\.bin (there's a dot before the bin), and do the exercise again. Then you can save the log file and provide the content to us.

Thanks

HI Jan, I am the writer of the debug engine for the this tool chain and would love to figure out what is going on.

First, we are trying to characterize some issues that users have reported in the area of setting/clearing breakpoints, to date we have not been able to identify the root causes so your ongoing input would be most valuable.

I have a work-around that you could try that may help and also would also help us to home in on the issue. First activate one of the two projects you have been looking at and start the debugger. Attempt to set a breakpoint on a source code line, if the "not found" popup appears click OK and then on the Debug menu select "Remove all breakpoints." Stop the debugger and repeat this process for the second project you have been looking at.

Let me know if this resolves the issue of setting breakpoints,

Sid