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

[free_electron]

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.

superloopcode


const event1time=700
const event2time =300
eventtrigger1 = 0
eventtrigger2 = 0

while 1
{
if not eventtrigger1 { toggle led1 ; eventrigger1= event1time }
if not eventtrigger2 {toggle lerd2 ; eventtrigger2=event2time}
}

no big deal write superloops.

My reason for feedback criticism is the following:
- hardware is easy for me. i dont need stackable boards and stuff. i'll roll my own.
- software is a bitch. especially language like c. there is too much syntax, typing and semicolons. it gives me semi, and other, colon cramps...

that is where stuff needs to be made easy.
we need to be able to define an alias.

myredled = this pin of that board
mebutton = that pin of that board

myredled=mybutton

that is the key thing to make software development  easy. the final code is extremely readable. there are no endless calls , brackets andother vrap. it reads lke a flowchart.
if i change hardware i change the definition of 'myredled and the code still works.


think about it. you are on the right track with your hardware. the softwarelayer needs key attention.

[QuickStack]

software is a bitch. especially language like c. there is too much syntax, typing and semicolons. it gives me semi, and other, colon cramps..

I feel you. I develop 50% of my time in c and 50% in Visual Studio, C#or VB.net. The c language is old and the syntax is not very good, but it is the most used language for embedded systems. So it can't always be avoided.

[QuickStack]

How big is your kernel? Is it all in EEPROM? How much RAM is left for user code?

The kernel runs in flash and the code size of the kernel between 7kb and 18kb depending which functionality is used. The RAM requirements are about 100 byte plus the stack-space for the threads. The processor on the HELLO has 128kb flash and 8Kb RAM and can easily run 10 to 15 threads. The average thread stack space is 100 bytes so 10 threads take 1Kb. So 1.1Kb of the 8Kb will be in use. (about 14%)

What security features are built into the kernel?  I can't imagine an easier way to spread a virus than installing someone's operating system with access to your network via the USB port. Odysseus  may have invented the Trojan Horse but.....

The kernel runs not in the PC but in the HELLO. If it has a connection with the PC and the connection is a COM port. It is like connecting any other device connected to a com port and the security is dependent on which program runs at the PC. The development environment (MPLABX) is the only program you would need to install on your PC. MPLABX is a professional industry tool, so you wont install any kind of sketchy software on your PC. MPLABX is available on Windows, MAC and Linux.

[codeboy2k]

I'll have to look at the Pub/Sub stuff more closely.  Back in the late 90's early 2000's I wrote hierarchical publish/subscribe servers, best effort delivery and guaranteed delivery multicasting clients and servers over TCP/IP.  We later extended this with gateways and store and forward servers so that clients that were subscribed to subscriptions offering guaranteed delivery semantics could go down and/or offline and get everything they missed.  Clearly you can't do this store and forward in an embedded environment, but even back then I often thought about putting the basic pub/sub at the board level.

I think that's what you are doing at the software level board to board, but maybe your using the 16Mb/s QuickStack bus to achieve this.

However, I agree with what's been said already, the QuickStack API just looks a like basic library of function calls on an RTOS, and doesn't really add much value as free electron pointed out.

The concept is great though:  stack another board, copy/paste the code and change the address and it just works.  That's a great achievement.

Regarding the 2.5V reference, didn't the designer read the datasheet there? in just 2 minutes reading the datasheet I saw that it needs a <100 ohm series resistor when used in unity gain configurations with load capacitance greater than 100pf. Actually having the 100nf there is good to make sure that it is dominating the added capacitance of added boards(2V5_Ref is on the left interconnect), so I think having the 100n there at the output is good, it just needs to have a low value series resistor there too, looking at the graph figure 4-4 maybe extrapolate to 82 ohms or so.

[Stonent]

In general, I'm OK with the shield culture. I just don't really have plans to buy any of my own unless it implements something too complicated to do myself.  The Arduino is a nice platform for me because it is easy to prototype on and then move off the Arduino to a standalone AVR.

My thought would be to move the debugger off the main board and make it a stackable item. With that you could cut your  board costs quite a bit. You'd have to probably raise the starter kit price because it would include the MCU board and the debugger board, but additional processor boards could be up to a third cheaper.

If the debugger needs lines that aren't on the main bus, just add a small header in the middle that the debugger can tap into but is otherwise not brought into the user environment.

From what I could tell the brain board can be stacked on the top or bottom, what would happen if two brain boards got stacked, would they share the bus or fight?

The more I think about it, these boards remind me of programmable logic controllers like Allen Bradley / Rockwell Automation make. Modules share a common bus and are addressable by a main processor module.

Now lets move on to the open-ness of your design. Would I be able to get access to your firmware and flash an identical PIC chip and interface it into your software?

[QuickStack]

Clearly you can't do this store and forward in an embedded environment, but even back then I often thought about putting the basic pub/sub at the board level.

Pub/Sub combined with use-count of message is a great tool for loosely coupling modules and it makes re-use much simpler.

the QuickStack API just looks a like basic library of function calls on an RTOS

The Kernel is a big part of the solution but the QiuckStack API goes much further. It decouples all hardware peripherals, like SPI, UART, I2C, input captures, PWM’s, Pins, Timers, Comparators, ADC, DAC, CAN, etc.  from the devices and provides a fast bus. 
The concept is great though:  stack another board, copy/paste the code and change the address and it just works.  That's a great achievement.

Regarding the 2.5V reference, didn't the designer read the datasheet there?

No, you are the second person that found this problem. Actually, the latest schematic has multiple issues and was hastily put up without checking. Thanks for mentioning it.

[QuickStack]

My thought would be to move the debugger off the main board and make it a stackable item. With that you could cut your  board costs quite a bit. You'd have to probably raise the starter kit price because it would include the MCU board and the debugger board, but additional processor boards could be up to a third cheaper.

We will have a version with and without debugger. The HELLO with debugger can also be used as a stand-alone debugger

From what I could tell the brain board can be stacked on the top or bottom, what would happen if two brain boards got stacked, would they share the bus or fight?

The bus structure is designed for multiple brain boards. Initially we thought that we could build it completely automatic but that is probably too time consuming. We are currently working on a version where the developer specifies in software which brainboard is the stack master. A stackmaster will pull up some of the lines and will be the sole provider of the reference voltage. (not yet in the latest schematic). It will also indicate which smart lanes are already in use. After initialization, it operates the same as any other brainboard with the exception of synchronization of access to the I2C lines.

Now lets move on to the open-ness of your design. Would I be able to get access to your firmware and flash an identical PIC chip and interface it into your software?

The software is open and will be available as object library and source code.

[Kjelt]

Very nice , hope it works out for you. Personally, I wish there was an ARM cortexM3 or M4 micro on it but perhaps later on in next versions.
If SW and HW are open source are you not afraid another company with cheaper labor costs will start producing these and sell on ebay, i mean how are you going to protect your investment?

[QuickStack]

Very nice , hope it works out for you. Personally, I wish there was an ARM cortexM3 or M4 micro on it but perhaps later on in next versions.

The Cypress PSOC5 would be a great candidate. It has PPS, cortex M3, free compiler and developer environment lots of peripherals. Great chip.

[QuickStack]

If SW and HW are open source are you not afraid another company with cheaper labor costs will start producing these and sell on ebay, i mean how are you going to protect your investment?

That is always a risk. We licence QuickStack as "Creative Commons Attribution-Non Commercial-Share Alike 3.0 Unported" but I know that it will copied anyway. Ebay removes sellers that copy illegal but others do not so it is an issue.
The boards can be copied and modified non-commercially including by hobbyists. You can create your own boards on the platform as long if it is non-commercial. We have a waiver for somebody who wants to produce and sell unique boards on our platform. We don't want to compete with our own products.