RE: ImageCraft JumpStart Microbox Education Kit - Part 2: Stepping Through an Example - what do I learn?

richardman — Sat, 31 Oct 2015 12:38:03 GMT

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.