QuickStack, a new embedded platform. We would love to get your opintion on it!

[QuickStack]

Hey everyone,

We just started our Kickstarter campaign for QuickStack.
http://www.kickstarter.com/projects/2016620887/quickstack-lets-make-it-easy

Here is one of the latest schematics for the BrainBoard. (updated Dec 3rd)
http://www.quickstack.org/docs/helloschematic.html

We would love to get your thoughts and input on this!


EDIT DEC 3: Updated the schematic.

• The pull-ups no are no longer connected together.
• The opamp on Vref now has as shutdown and a 100K load resistor to stabilize it. Did some testing and simulation on this and now even with 100uF on the output it is perfectly stable.

[madires]

I'll be frank ;-) Is that the Picuino? There are so much platforms to choose from I'm not sure which one I would select if I had to.

[filip_cro]

So this is arduino with PIC uC.  As breadboard fan I can't like it   

I see problem if this will have limitations of free MPLAB (2k of hex)

[free_electron]

"let's make it easy"
qWbrRlyOn(4)  Really ? where is the vomit icon ?
you better come up with some API names that are humanly readable... i;d rather learn the mnemonics for assembly than this kind of gobbledegook.

"Great Documentation We really take pride in the QuickStack documentation"
why does the relay board documentation only give a code example for the led board ?
http://www.quickstack.org/docs/8xRelayBoard.pdf


"Low power"
... and use relays with mechanical memory ! now you are burning power in relay modules.

[QuickStack]

qWbrRlyOn(4)  Really ? where is the vomit icon ?

you better come up with some API names that are humanly readable...

We already had this mentioned by someone else and looking into improving it.
We wanted to keep the names related to the information you work on. Lets say you copy data from an SPI device to a I2C device. With the naming we use it looks something like this:

pSPI spi = qSpiCreate(.....);
pI2C i2c = qI2cCreate(.....);

char* pBuf = qMemAlloc(256);

qSpiRead(spi, pBuf, 256);
qI2cWrite(i2c, pBuf, 256);

We have something like 20 of these "objects" like SPI, I2C, EVT, etc. The nice thing is that the auto-completion helps you to navigate those names. The "q" is to differentiate QuickStack functions from other functions. If you type "qSpi" followed by ctlr-space the development environment gives you a list of all SPI functions. That is why all functions start with the "object" name. We are working on a video to explain this a bit more in depth.

I agree with you that qWrbRlyOn(4) is pretty cryptic. We will definitely think a bit more about this to find a balance between cryptic and auto-complete support.

"Great Documentation We really take pride in the QuickStack documentation"
why does the relay board documentation only give a code example for the led board ?
http://www.quickstack.org/docs/8xRelayBoard.pdf

Didn't realize this. Most of the work in documentation has gone into the User Manual and Reference Manual. The Workerboard documents are still in progress.
The Relay board example should have been this


You're absolutely right in saying that it could be counter intuitive having relays when you want to go low power.
What I meant to say is that the software allows the option of low power. You could easily put some triacs on a breadboard to do the same thing using less power.
Or perhaps you just want to switch something on for a few minutes per day. Then everything can be in sleep most of the time.

[free_electron]

>> qSpiRead(spi, pBuf, 256);

>> type "qSpi" followed by ctlr-space the development environment

i'm gonna bitch a bit more here ( you made the claim "let's make it easy")

1) make the libraries smart enough so they can figure out themselves how long a passed structure is. make strings autosizing.
it is a matter of creating a macro that creates a structure that is 2 bytes longer than what is required the frist two bytes hold the length of the structure , followed by the actual data content.

dim q (10)  creates a structure of 12 bytes <0x00 0x0a> <data>
i2cwrite (mydevice,q)   < the write handler figures out how long the structure is.

2) ctrl-space  ? can we have a code editor like visual studio please ? autocomplete is always on , tooltips , intellisense , autocapitalisation
if it ain't got this i won't use it. Ctrl-space makes me puke.

3) why all that complex doing with function callery ?

make a preprocessor.
the keyword 'connect' allows definition of boards
the keyword 'create' allows definition of sub entities of a board

connect mybigrelayboard .byserial 0x12345
connect mysmallrelayboard.byname "MySmallRelay"
connect myi2c.byserial 0x15432
connect myinputboard.byserial 0x45623

create heater as Relay(mybigrelayboard.4)
create fan as relay(mysmallrelayboard.2)
create i2cbus1 as i2cbus(myi2c,3)
create startbutton as input(myinputboard.2)
create stopbutton as input(myinputboard.4)

heater = 1
fan = off

dim mydata(2)
mydata(0)= 0x45
mydata(1)= 0xff


i2cwrite (i2cbus1,mydata)
heater = 1
fan = off

create aliases for ON OFF , TRUE and FALSe

the preprocessor simply spits out inline functions that do the gruntwork

if startbutton =1 then fan =1 gets converted behind the scenes by the preprocessor to :

if qwbinpt(3) ==1 then qwbrlyon(4)

[c4757p]

I agree with you that qWrbRlyOn(4) is pretty cryptic. We will definitely think a bit more about this to find a balance between cryptic and auto-complete support.

What does whether the name is cryptic have to do with autocomplete support? I have yet to see an autocomplete that can handle qWbrRlyOn but not quickstack_relay_switch_on_this_is_a_really_long_name...

And why is autocomplete so important anyway? If the names weren't cryptic, you'd be able to remember them... and to use them right, you'll probably want to look at the documentation anyway. And besides, typing out code is rather a small part of the time spent by an embedded developer.

For a better way to do autocomplete, what about C++ namespaces? Granted, not every embedded platform has a C++ compiler, but for the ones that do, you can use Q::Relay::switch_on, autocompleting each step through the namespace hierarchy.

[QuickStack]

So this is arduino with PIC uC.  As breadboard fan I can't like it   

I see problem if this will have limitations of free MPLAB (2k of hex)

There is no code size limitation. The only limitation is that GCC cannot optimize to the smallest code size and faster code. We tested this and the code size difference is about 9% (code is 9% smaller when compiled with GCC level-s) the difference in speed is 12% (code is 12% faster when compiled with GCC level-3)

[QuickStack]

1) make the libraries smart enough so they can figure out themselves how long a passed structure is. make strings autosizing.
it is a matter of creating a macro that creates a structure that is 2 bytes longer than what is required the frist two bytes hold the length of the structure , followed by the actual data content.

dim q (10)  creates a structure of 12 bytes <0x00 0x0a> <data>
i2cwrite (mydevice,q)   < the write handler figures out how long the structure is.

That is nice but that requires specific formatting of memory. All our internal structures know about the length but in this example it is user generated data and you don’t want to limit that usage

2) ctrl-space  ? can we have a code editor like visual studio please ? autocomplete is always on , tooltips , intellisense , autocapitalisation
if it ain't got this i won't use it. Ctrl-space makes me puke.

The IDE is based on NetBeans and is very powerful. You can set it that it behaves more automatic like VS-2012

3) why all that complex doing with function callery ?

That would be an option. But the relay boards are generic, not everybody uses a relay for a heater like in your example.

[QuickStack]

I agree with you that qWrbRlyOn(4) is pretty cryptic. We will definitely think a bit more about this to find a balance between cryptic and auto-complete support.

What does whether the name is cryptic have to do with autocomplete support? I have yet to see an autocomplete that can handle qWbrRlyOn but not quickstack_relay_switch_on_this_is_a_really_long_name...

And why is autocomplete so important anyway? If the names weren't cryptic, you'd be able to remember them... and to use them right, you'll probably want to look at the documentation anyway. And besides, typing out code is rather a small part of the time spent by an embedded developer.

For a better way to do autocomplete, what about C++ namespaces? Granted, not every embedded platform has a C++ compiler, but for the ones that do, you can use Q::Relay::switch_on, autocompleting each step through the namespace hierarchy.

The compiler is not C++ so we can’t use objects. We have tried to mimic objects as much as possible. So the “q” indicates a part of the QuickStack library, “Wbr” is for the workerboard that the function works on and “Rly” is a bad choice. RelayOn would be much better. The first parameter in the is a pointer to a pWBR. It is definitely an option to name this qWorkerRelayOn(pWORKER, int RelayNbr);

[JohnnyGringo]

"let's make it easy"
qWbrRlyOn(4)  Really ? where is the vomit icon ?
you better come up with some API names that are humanly readable... i;d rather learn the mnemonics for assembly than this kind of gobbledegook.
 

Your naming scheme is... well.... rather sucky obtuse.

EDIT: Pick up a copy of the book "Code Complete". It's the IT bible when it comes to naming conventions.

4 of which are single pole dual throw (SPDT) and 4 are single pole single throw (SPST)

  Make them all SPDT, if I only need a SPST, I'll just wire up one leg.

[free_electron]

3) why all that complex doing with function callery ?

That would be an option. But the relay boards are generic, not everybody uses a relay for a heater like in your example.
[/quote]

it doesn't matter what you use it for.

i should be able to define a variable that points to a particular channel. by then assigning a value to that variable the channel changes.
i should also be able to define a variable that holds all relays

dim heater as relayboard.4  ' relay 4 of the board
dim allrelays as relayboard.allrelays

allrelays = 0x55   << affects all the relays
heater =0

that way the actual program is very simple

if  abs(temperature - setpoint) >2 then heater = on else heater=off
if temperature <(setpoint-3) then too_cold_led = on else too_cold_led= off
if temperature >(setpoint+3) then too_hot_led = on else too_hot_led= off

temperature is the reading of an AD converter. setpoint is a variable holding the desired temperature
heater is a relay
too_hot_led and too_cold_led are digitla outputs ( could be relays as well )

you really want to be able to create an alias for the I/O. having all these function calls everywhere just makes for unreadable code.

[sleemanj]

Non obvious abbreviations in function names should NEVER be a thing.  A non-familiar programmer should be able to look at the code and easily get a feel for what's going on.

Before I read the whole thread, I naturally assumed "Rly" was short for "Really" and figured it must have been some afterthought kludge where the existing function didn't do what it should Really have done but couldn't be changed without breaking stuff.

The code sample looks like somebody spilled their alphabet soup on the floor as a result of all the abbreviations.

Is saving two keystrokes really worth abbreviating "Relay" to "Rly"?! 

I still don't know what "Wrk" means?

[QuickStack]

Non obvious abbreviations in function names should NEVER be a thing.

Thanks for all the input. We understand that we have to work on naming and we will.

[QuickStack]

i'm gonna bitch a bit more here ( you made the claim "let's make it easy")

We always appreciate criticism. The claim "let's make it easy" is based on current embedded platforms out there. If you compare QuickStack with other stackable systems that are C or C++ based there are definitely some properties that will make development easier.

• No pin contention
• Every peripheral can be connected to every pin
• Full hardware abstraction
• Off the shelve enclosures
• On board hardware debugger
• Includes a kernel

How does a kernel make easy? Compare a simple 2 LED blink program where one blinks at 300mSec and another at 700mSec kernel based and non-kernel based.

With a kernel:


Without a kernel:


Without a kernel you have to write a superloop and that does not make it easy or readable. The kernel version also switches to a low power mode while it is waiting. The non-kernel version just burns power in the loop.

[Harvs]

Clearly you've put a lot of work into this, so I hope it succeeds for you.  You've certainly improved in a few areas above what is currently dominating the market.

A couple of criticisms from me:
- "QuickStack is the only platform that integrates hardware and software completely"
Ok, I can't see from your kickstarter page how you've gone significantly further than the hardware/software integration levels currently available in something like Arduino.  In fact I don't really see how much further you can go than something like Arduino???

- "QuickStack is a Platform somewhere between Adruino and PC104"
Firstly, best you correct your spelling mistake on the Kickstarter.  I don't get where you're really going with this comparison.  PC104 - i.e. Intel ISA, 500MHz to multi GHz multi core PC with PCI bus.  Arduino - simple 8-bit uC.  You can almost point at any board currently out there and say it's somewhere between those two, because they're nothing a like.

- Multitasking
I've written a lot of multi-threaded code, and as I'm sure you know, it can easily be an order of magnitude more complex to write and particularly debug than a single threaded app.  Granted you only have a single core to mess with variables at any one time, but how is it that you've made it so simple for people?

e.g. lets have two functions, one that reads data from a sensor and converts it to a string, and another function that puts that string out to serial port.  Now in any other system I've worked with, you as the programmer need to program how thread contention is handled.  I.e. it is unacceptable to have the sensorFunction modifying that values of the global variable halfway through transmittString working on the data.  Hence you end up delving down into the Atomicity of the functions, thread locks (spinning locks vs yielding locks), etc.  Now there's many code patterns out there for how to write your program to deal with this sort of things, and it generally boils down to some form of Event based system.  But clearly that's not in the realm of simple, so how have you gents dealt with this problem?

Code: [Select]

String ASCIISensorValue;

// Let this be the first thread
sensorFunction (){
while(1){
delay(20); //delay 20ms
float sensorValue = readTheSensorValue();
functionToConvertFloatToString(sensorValue, ASCIISensorValue);
}
}

// Let this be the second thread
transmittString(){
while(1){
delay(100);
printf(ASCIISensorValue);
}
}


[Rufus]

While other piss and whine I'm reasonably impressed.

I didn't look too deeply at your interconnect but at first sight it seems very dependant on the PIC24 peripheral pin select feature. Isn't that going to limit what processors 'brain' boards can have? I kinda would have expected to see a PIC32 which gets you more MIPS and a free C++ compiler but I think (not yet had the need to use one) the PPS is rather more limited on those.

Did you write your own multitasker or are wrapping FreeRTOS or something?

Browsing the Hello board schematic I think you are going to have to re-think the "Enable Pull-ups" stuff which connects all the I2C lines through the pull up resistors if you don't enable it. I also question the Vref buffer and that it is happy with 100n straight on it's output. It saves some current in the reference but adds offset, drift, and cost - are you that careful with the power budget elsewhere?

[bxs]

Hum, seems just another board.

It's a board with a PIC24F with a PicKit3 on it...

The software framework don't seems that simple, it uses some ugly names.

And even to use that software framework you end up also having to use Microchip tools, IDE, compilers, etc.

Is Microchip fine with you guys putting a PicKit3 on your board?

But, good luck  I've seen many times worst things having a huge success.

[QuickStack]

Ok, I can't see from your kickstarter page how you've gone significantly further than the hardware/software integration levels currently available in something like Arduino.  In fact I don't really see how much further you can go than something like Arduino???

One example where Quickstack goes beyond Arduino is that it can allocate all peripherals on demand to abstract hardware (peripherals) and software.
This means that abstraction of hardware goes beyond a single peripheral and one module does not interfere with another module. If you want a UART you just allocate one.

If you have two boards you can write the software for one of the boards without knowing what peripherals are used by other boards. This means that you can keep adding boards without pin or peripheral contention.

Firstly, best you correct your spelling mistake on the Kickstarter.  I don't get where you're really going with this comparison.  PC104 - i.e. Intel ISA, 500MHz to multi GHz multi core PC with PCI bus.  Arduino - simple 8-bit uC.  You can almost point at any board currently out there and say it's somewhere between those two, because they're nothing a like.

Thanks for the heads up on the spelling mistake.
In terms of processing power there are definitely a whole range of devices between Arduino and PC104.
We chose this comparison on the basis of the platform, communication structure and expandability. We are similar to PC104 in the way that it is a stackable system and can expand to become huge network of boards. QuickStack allows for the same level of expandability.
We are however not a PC platform but a truly embedded platform.

So I suppose what I am trying to say here is that we are not somewhere in between the two but that we have married certain aspects of the two. 

Hence you end up delving down into the Atomicity of the functions, thread locks (spinning locks vs yielding locks), etc.  Now there's many code patterns out there for how to write your program to deal with this sort of things, and it generally boils down to some form of Event based system.  But clearly that's not in the realm of simple, so how have you gents dealt with this problem?

Atomicity is always a big problem. Especially if the information is interrupt driven. In a superloop solution the variable becomes global without atomic protection and the application works OK in 99% of the time. Sometimes it fails and the bug is difficult to find. It is much better to understand how things work and protect the variable with a mutex.
QuickStack supports 5 thread communication solutions, mutexes, semaphores, events, message queues and publish/subscribe. Mutexes are more for the beginner while publish/subscribe is more for the professional. The publish/subscribe mechanism makes code more agile. In the 3rd example below you can add thread 3 to implement requirement changes and extend the application without changing existing code.
The beginner can use mutexes to protect global variables and can create rock-solid applications.

This would be used by beginners, a simple mutex solution


This is a standard message queue


Lastly the most advanced agile solution is based on publish/subscribe.

EDIT: oops , too much cut and pasting. The "myQue" literal should unique.

[QuickStack]

I didn't look too deeply at your interconnect but at first sight it seems very dependant on the PIC24 peripheral pin select feature. Isn't that going to limit what processors 'brain' boards can have?

At first we also thought we were limiting our options for other processors. There are a good number of other processors out there that have something similar to PPS. One such example is the PSOC5 from Cypress, they go even further in terms of PPS. We can also introduce any other MCU by adding a cheap (3-4 dollars) FPGA and using it as a crossbar.

Did you write your own multitasker or are wrapping FreeRTOS or something?

The software is based on a licensed version of Q-Kernel v6.

Browsing the Hello board schematic I think you are going to have to re-think the "Enable Pull-ups" stuff which connects all the I2C lines through the pull up resistors if you don't enable it. I also question the Vref buffer and that it is happy with 100n straight on it's output. It saves some current in the reference but adds offset, drift, and cost - are you that careful with the power budget elsewhere?

We have those pull-ups set up the way we have, to support multiple BrainBoards (hello's) in a single stack.

Good catch on the voltage reference, we'll have a closer look into it.

[QuickStack]

And even to use that software framework you end up also having to use Microchip tools, IDE, compilers, etc.

With QuickStack we wanted to define the hardware and software API that boards communicate with, there can be different implementations of the IDE and processors.
For example, the Cypress PSOC5 ARM implementation with their free IDE and GCC compiler will fit the platform very nicely. The whole platform is based on 3v3 signals.

Is Microchip fine with you guys putting a PicKit3 on your board?

Yes, we have a licenced version of the Debugger/Programmer.

[Rufus]

We have those pull-ups set up the way we have, to support multiple BrainBoards (hello's) in a single stack.

I assumed that is what it was for and it doesn't work. When you turn off the pull ups you are connecting SDA and SCL together through 2k or 9k4 resistors and worse you are cross connecting the two buses through 2k and 9k4.

The more brainboards on the bus the worse it gets.

Edit: even worse I hadn't noticed the INT CTS and DAT signals are also pulled up so they will all cross talk with each other and the I2C lines.

[QuickStack]

Oh damn, didn't see that.
Thanks so much, the schematic still has to be checked over again. I'll make sure we change it.

Again much appreciated!
 

[Rufus]

Oh damn, didn't see that.
Thanks so much, the schematic still has to be checked over again. I'll make sure we change it.

Again much appreciated!

A guy I used to work with would call that an OSINTOT.  An "Oh Shit I Never Thought Of That".

[Harvs]

QuickStack supports 5 thread communication solutions, mutexes, semaphores, events, message queues and publish/subscribe. Mutexes are more for the beginner while publish/subscribe is more for the professional.

Understood.  From the perspective of someone who know what all those words mean and how they work, thats great.

I just don't know how beginners are going to go digesting it all.

Kudos for doing it though.  I don't know of any other hobbyist platform out there where they've included a proper RTOS.