-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to more powerful hardware #108
Comments
@dev-zzo As awesome as this would be, there are several reasons why this is something for the not-so-close future:
You also have to remember that we are a small company with only a few employees and with this whole open source thing (which is an awesome thing!) we do not earn much money (in fact, we only earn money with selling the hardware, which is also open source and thus can be cloned simply). Maybe you can correct me and tell me how simple porting code from XMEGA to ARM is? |
From what I can tell, platform details can be successfully abstracted away (and already are for most of the code anyway); I think the most platform dependent parts are a) codec implementation details dealing with bits on the line b) host interface implemented with USB and c) cryptography implementations for DESFire. The rest of the code appears to be portable easily enough as it doesn't use any hardware features. NB. I don't think moving to closed source would increase your bottom line as a company, but would certainly prevent you from receiving all the open source contributions. |
OK, we'll discuss this internally at some point in the next months. NB. We don't plan on moving to closed source and I didn't want to sound like if we want to in my previous post :) |
So what about the more powerful hardware? |
Considering all the issues regarding timing constraints that were previously reported, is there any intention to move on to e.g. STM32 instead of AVR8? We would get 20MHz->32MHz, SRAM 8KB->20KB at the same price point, plus easy debugging via SWD. And if that's not enough, there are upgrade paths within the same family, preserving most of the code, whereas with AVR8 there is basically no room for code/data use growth, not to say about CPU clock speed. @geo-rg @david-oswald -- any ideas?
The text was updated successfully, but these errors were encountered: