Skip to content
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

Open
dev-zzo opened this issue Apr 26, 2017 · 4 comments
Open

Move to more powerful hardware #108

dev-zzo opened this issue Apr 26, 2017 · 4 comments
Assignees

Comments

@dev-zzo
Copy link
Contributor

dev-zzo commented Apr 26, 2017

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?

@geo-rg
Copy link
Collaborator

geo-rg commented May 2, 2017

@dev-zzo As awesome as this would be, there are several reasons why this is something for the not-so-close future:

  1. There are several thousands of Chameleons RevG in the world right now. Upgrading to new hardware after just 10 months would result in many people having a tool with discontinued software (or parallel software development).
  2. Also, the old software would have to be maintained in parallel to the new one.
  3. I think that the constraints we are experiencing right now are not that bad.
  4. I don't have any experience with porting code from xmega to ARM but it seems to be not very simple.

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?

@dev-zzo
Copy link
Contributor Author

dev-zzo commented May 2, 2017

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.

@geo-rg
Copy link
Collaborator

geo-rg commented May 2, 2017

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 :)

@anonymix007
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants