EEVblog Electronics Community Forum
Products => Crowd Funded Projects => Topic started by: QuickStack on November 27, 2013, 07:17:12 pm
-
Hey everyone,
We just started our Kickstarter campaign for QuickStack.
http://www.kickstarter.com/projects/2016620887/quickstack-lets-make-it-easy (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 (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.
-
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.
-
So this is arduino with PIC uC. As breadboard fan I can't like it ;D
I see problem if this will have limitations of free MPLAB (2k of hex)
-
"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 (http://www.quickstack.org/docs/8xRelayBoard.pdf)
"Low power"
... and use relays with mechanical memory ! now you are burning power in relay modules.
-
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 (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
(http://i.imgur.com/T9cCODC.png)
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.
-
>> 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)
-
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.
-
So this is arduino with PIC uC. As breadboard fan I can't like it ;D
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)
-
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.
-
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);
-
"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.
-
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.
-
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?
-
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.
-
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:
(http://i.imgur.com/LqAfUI8.png)
Without a kernel:
(http://i.imgur.com/kmdIFeL.png)
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.
-
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?
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);
}
}
-
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?
-
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.
-
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
(http://i.imgur.com/MsA4s60.png)
This is a standard message queue
(http://i.imgur.com/4N1laV3.png)
Lastly the most advanced agile solution is based on publish/subscribe.
(http://i.imgur.com/5mqbYzC.png)
EDIT: oops , too much cut and pasting. The "myQue" literal should unique.
-
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.
-
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.
-
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.
-
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!
-
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".
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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?
-
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.
-
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.