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 Man wrote:

 

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.

Are those the only two choices? What about Energia, mbed, which make getting going with ARM microcontrollers extremely simple for beginners and hobbyists.

For commercial customers, there are cool tools like TI's PinMux to help set the registers,

and a wealth of peripheral driver code, all with source code.

Even with jumpstart, if you move to different silicon, you'll still need to spend time ensuring

the new microcontroller can support certain functions on certain pins, so you still need to

go through the microcontroller documentation.

With the same vendor usually the peripherals can be fairly similar, so it doesn't take

ages making the necessary tweaks if the manufacturer has not supplied driver code (which is unlikely) - and one gets to learn about the peripherals at the

same time, meaning one can make better use of them.

Jumpstart may be a great product, but it is unfair to imply there are only two choices here

when there is plenty of code from manufacturers to make life easier - no need to work

just from the datasheet to get the basic structure going as you say.

Is source code available for Jumpstart? I'm still not clear.

shabaz wrote:

 

...

 

But I take your point, this is only examining the jumpstart API specifically which may not be the core part of the offering.

That is one of the hardest things for me to get:"What is the core part of this offering?

What in this kit is the thing that'll teach you embedded programming?

If I would know the answer to that, it would make my review easier and more focused.

Our primary business is the compilers, between "GCC - even if it's not free!" and "IAR/Keil even at $7000+ is quite OK", there is a market niche there. The JumpStart API, and the MicroBox kit, are here to give further values to the compilers. Our goals have already been stated: capture the professional engineers in the niche we said, and to provide values for educational institutions.

As for teaching embedded programming, the MicroBox provides all the tools and information, in a single package. With the ST-Nucleo and the ACE Shield, all sorts of programs can be written for learning embedded programming. For example, we have an example project that walks the 8x8 LED one by one. A class exercise can be written to say, "now make a starburst pattern with the LED matrix". If a hobbyist/student were to do that, they will learn about bit-masking, and loops. You mentioned about the I2C API source code is not provided, fine - a student can write bit-bang I2C routines. They can use the JumpStart GPIO API to make life a bit easier, or they can do it all with the StdPeriphLib. The point is that they know for sure that the hardware does work which makes their job easier. The OLED, the RTC, the Crypto-chip etc. are all there for experimentation purpose. If you want to do the most basic type of embedded programming, then yes, indeed the Arduino may be the best, as demonstrated by legions of artists that make blinky wearables and the like. However, our kit allows you to go further. Even the C ebook, we learn a lot about what trips people up by us doing our own customer supports for 20+ years, and the book is written to emphasize some of the "gotchas".

It just occurs to me where there may be a disconnect between Shabaz and yourself and our positioning. You folks are probably look at from the point of view of "what does this MicroBox thing offer that cannot be duplicated with X, Y, and Z, - for less!"? Whereas our positioning is that we offer a great alternative compiler to the existing solutions and by the way, to get started, you can purchase this low cost kit that has everything you need. Perhaps this observation may help to clarify the points.

Richard,

This is what I'm reviewing:

"what does this MicroBox thing offer that cannot be duplicated with X, Y, and Z, - for less!"?

in the perspective of the kit's position from the website.

I'm not planning to compare it too much to other offerings. I'd like to review how this kit performs as an educational starter kit by itself.

I may refer to other kits or tutorials when I think that either the JumpStart Kit or the other solution does it better.

But I don't intend to do a comparative review, just a review of the kit itself - by its own merits.

Sounds good. Different reviewers have different backgrounds and different interest, as do we of course. Thank you for your time in doing this.

Sounds good. Different reviewers have different backgrounds and different interest, as do we of course. Thank you for your time in doing this.