How do I go about picking an architecture ? My first thoughts suggested Cortex M3 but the more I look into it the less sure I am.
Obviously I don't to go to the trouble of learning a new technology only to find that I've made a bad processor choice (ie nearly end of line). I've spent many hours looking at many websites and have yet to find any high-level stuff on choosing my first ARM device.
If there's one thing wrong with ARM its the almost infinite number of devices
I'm an embedded developer wanting to undertake my first ARM project, so I'm completely new to the ARM architecture. I want a low power device with serial, USB and some ADC channels.
I already explained to you where, and even provided a quote.
tamir, are you talking about this "quote"
"For commercial use, you should have full access to the source code..."
which part of that talked about "performance, stability and in the end SAFETY"?
are you suggesting that having, or not having, access to the source code will hurt "the performance, stability and in the end, SAFETY of systems".
if so, how?
if not, what exactly did you mean?
try to focus on the end of the quote. namely, the expression that start with a "s" (a blatant clue, surely you agree). if you need more, just say so. Ahh, whatever, I'll give you one more: the next character is "o". now it's a no-brainer.
tamir, thanks for that clue, not.
if you cannot answer the questions, please just admit to it and we will excuse you on your behalf.
thanks in advance.
I never like this, but it is a software release date and a reason to celebrate to let get it on!
I meant: "I'm never like this, but it is a software release date and a reason to celebrate to let get it on!"
Mr Tamir.
What are you on { about } ?
release P004 rocks...!
Per did use the word, "dangerous".
But I don't think he was talking (particularly) about hazards to persons or property - I think he was talking about business risks.
As in, "there is a danger [business risk] that not having the source code may leave your project/product high & dry"
I think.
"I think he was talking about business risks."
nice try. I would give you an F for effort.
tamir, don't give up. don't EVER give up, :).
so Andy, you are conceeding on that the two other fronts (performance and stability), Per didn't think using OEM libraries would have adverse effect? could you work that out with tamir? :)
"As in, "there is a danger [business risk] that not having the source code may leave your project/product high & dry""
so it would not have any adverse impact on "SAFETY" (aka business risk) if you have access to the source code?
does that make it OK to use the Luminary libraries? could you please work that out with Per? :)
This thread quickly evolved into a kindergarten brawl, for no apparent reason.
Why should I be required to give examples to something I'm not claiming?
The probability of bugs is similar whoever wrote the code. A much used library from a manufactuer should - hopefully - be reasonably well-tested by all the users.
But I was talking about the business risks of using a library you don't have the source code - and suitable license - for.
With the source code, you can perform security reviews, looking for buffer overflows, resource leaks...
With the source code (and most licenses), you can correct bugs without need to wait for a new official release, and without worrying about the supplier vanishing.
With the source and a suitable license, you can not only fix any bugs, but also move the complete source code to new platforms.
Since a chip manufacturer isn't likely to supply general libraries with full source and BSD, LGPL or similar licenses, you should be very careful about using them. You may end up with a very serious nose bleed.
The CRTL can also be a bit problematic, but the advantage with the CRTL is that there exists a large number of suitable licensed C runtime libraries, so a company can replace printf(), strxxx(), time(), ... with alternative implementations without having to start from scratch, as long as the target has some safety margins in case the alternative implementation takes more code space, RAM or executes a bit slower.
I'm not. Actually, now that RTX related problems have been solved (I hope; will know more the coming days when the feedback from the client(s) arrives) there is a real possibility to making it to the original deadline. Say, Ashley, are you related to "Jack Sprat" [or maybe I should say: ARE you "Jack Sprat"? Sorry Per for resuming the kindergarten for a while; I'm actually enjoying myself. this was a good day - have I mentioned release P004 yet? :-) ] ho and Ashley you forgot to grade me!
With the source code (and most licenses), you can correct bugs without need to wait for a new official release, and without worrying about the supplier vanishing. A ticket machine was violating the J1708 protocol and created many errors on the bus. When the manufacturer was approached they, of course, replied "no such thing". After being shown proof they stated "this will be fixed in the next release out in October next year (my emphasis).
Erik
"Why should I be required to give examples to something I'm not claiming?"
sounds like you are unclaiming what you just claimed. what do you think this guy/gal was claiming when s/he said:
"For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture."
no answer is required, :).