• Content count

  • Joined

  • Last visited

  • Days Won


yyrkoon last won the day on March 17

yyrkoon had the most liked content!

About yyrkoon

  • Rank
    Level 4
  • Birthday 07/05/1966

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

2,071 profile views
  1. @zeke thanks, That, more or less seems to be what I do myself. In this case however, there won't be a user interface, nor anything related to "feedback" over serial as an I2C slave can't communicate with the master unless the master initiates the communications. There also won't be an LCD, but I do not think that was you point, and I'm not sure If I will be able to use UART for serial debugging or not. However, this very well may be a chance, and a reason for me to use the logic analyzer I bought a few months ago. Now, I need to try and figure out how to program the 28pin G2553's. With the 20pin dip package MCU's I've just been using a ZIF socket on the launchpad, and moving programmed parts to a socket on the board which needed the MCU. Now, I'm kind of at a loss. My buddy wulf has put JTAG, and spy-by wire headers on the prototype, but . . . I've no clue where to start.
  2. So, on the surface, it looks like PWM is very simple. I could potentially get away with a fixed period, and make a variable duty cycle. e.g. *something* communicates with the MSP430 over I2C and gives a value between 1-99. Which would represent duty cycle. Then, it's just a matter of performing simple math with the value in CCR0, and put that result into CCR1. But there is still the potential for pin / resource conflicts that I'm not fully clear on yet.
  3. The ADC is pretty easy. There's documentation all over the web, which is how I prefer "things". Reading blog posts that go into detail as well as explaining their code. That way, if I don't get the initial explanation, the code, and code explanation usually does the job pretty good. Usually, blog posts are also short, and to the point. Which is why I normally do not do well with specifications. I just want to know what I need to do, in order to achieve and end goal. Not memorize ever_single_minute_detail. To do what I need to achieve, I may have to go to the 2955, for the added program ram, and flash. But, I'm 99% sure what I need to do can be done on a 2553. @zeke, would you mind going into high level detail about this state machine you mentioned ? Perhaps a very simplistic pseudo code example ? One of the things that has me a little "worried", is wondering if the interrupts could potentially preempt one another. Thus, having missed interrupts. However, I'd probably want to use hardware I2C, and for PWM, I'll probably have to use interrupts on the timers, to get a proper frequency, and duty cycle. *Maybe* I could get away with a polled GPI, but the ADC's . . . yeah not sure. EDIT: Ideally, I'd prefer to do everything in hardware if at all possible. So, PWM, ADC, and I2C all in hardware using interrupts, and as for the GPI, it doesn't matter.
  4. Part of what I was trying to figure out is would I be able to use PWM ADC, as well as I2C plus 1 each GPI, and GPO, all on a G2553, which seems perfectly doable. After that, I was not sure how USCI handles I2C coms. But if it's as simple as setting a constant to the device address value, then again, No problem . ..
  5. @Clavier , Awesome, thanks. I would have responded sooner, but someone *cough* @bluehash moved my post, and now I'm not getting notifications . . . Anyway, you pretty much answered, all the questions I had. Which mainly was if I use USCI, would I have to handle all the bus com stuff. e.g. device address, and all that. But I do need to figure out what you're talking about, concerning setting the slave address in some register. Because I'm going to need to do that via dip switches. e.g. physically. I did also find this on github last night -> https://github.com/wendlers/msp430-i2cslave Apparently written by one of the people from the German branch of TI.
  6. I was wondering if anyone knows of a good read concerning implementing an I2C slave device. What I'm looking for, is something that covers kind of a high level discussion of what needs doing. Without a bunch of specification, or physical characteristic discussion. Meaning, I do not care about the electrical / physical characteristics of such a device, and I have a hard time digesting specification type books. Mostly, what I really need to know is a processor / language agnostic view of how to implement the slave addressing stuff. Such as device addresses, and register addressing. Code examples would be cool, in any language, but are not strictly speaking, necessary. Additionally, I'm also interested in implementing a slave device using the 1-wire protocol too. EDIT: Additional information, which may help someone else help me. As a hobby project, for the purpose of learning, I'm attempting to turn an MSP430G2553 into a slave device that could potentially be used as an I2C slave device that could possibly be an ADC, PWM, GPIO expander, or a combination of all mentioned plus more. However, the reading material does not necessarily have to be specific to the MSP430G2553, or any MSP430 for that matter.
  7. I will however probably start watching more videos from Jason Turner, I like his style, and so far what I've seen. He covers stuff that is interesting to me. Which I've only watched this one video, and part of another. Thanks @chicken
  8. Here is what I took away from this video. Dan Saks is a wind bag, that knows nothing about programming. Someone who also envisions himself as some kind of psychologist, at which he also does a very poor job. I'll probably never watch another video with him in it, or read anythign written by him from this day forward. My time is much too precious to me now days, to be watching videos about programming, that aren't really about programming. I mean seriously, how old is this guy that he has to worry about which language people are using ? I don't see him telling Java programmers they should be using C++. Which by the way, makes a whole hell of a lot more sense to me, than the topic of this video. EDIT: By the way, I'm not C++ guru either. For that matter, I would not say I'm a C guru, but I am the most proficient with C.
  9. Chicken, watched it, and thought it was pretty cool. So, I do not know if you read all of oPossum's, and Rickta's talks in the past about templates and the const keyword. But yeah the stuff this guys touched on that talked about those two points did not surprise me. But some of the other stuff did. But maybe the contructs you talked about not understanding were Lamba's ? My understanding which I freely admit will be very limited is that Lambda as essentially templated functions that are used on the spot they were created. Without having to flesh out all the gory class structure before hand ? Question mark at the end there because I have a vague memory of something *someone* in *some* video was talking about when explaining Lamda's, and I'm not sure my understanding of what a Lamda is would be correct. I guess my understanding was close, but not really close enough to be factual. Basically a *Lambda* is an Anonymous function that does not have a function definition. e.g. a function that is used on the spot, and is pretty much a throw away function. Only used in one part of the code.
  10. You're welcome, I suppose. Personally, I did not like the video much. Much of it was talking about BS that has nothing to do with programming, and the assumptions he posed were no where close to how I see things. It was not until the questions part of the video, that someone else even came close to why I prefer C instead of C++ most of the time . . . Question: " What do you do when someone says C++ is far more complex than C . . ." Dan Saks: "Uh . . . nothing . . . it's true . . ." I also do not agree with his philosophy that "If you're arguing, you're losing". I say if you're not arguing, you're not learning. But, I suppose his idea of an argument is adversarial in nature ? No idea really . . . EDIT: I also found it rather pompous that he thinks he knows other people better than they know themselves. As if programmers are also people, but still do not have half a brain to think with on their own. This "Framing" garbage might be vaguely true, but anyone who took English for a few years in Grade through High school knows how to read, and make sense of what they've read. Much of what he discussed also seemed very contrived to me. Almost like he was trying to "frame" his own conversation in a way that makes himself think it's good. But the problem with all of that, is that I have a brain of my own, and the ability to use it to reason for myself. e.g. I do not need someone to tell me what something means, and I can, and will form my own opinions of things. That, and I'm no one special, in that I'm not the only one with this "magical ability"( Apparently ) to see through what I consider BS. As far as his testing results . . .yeah, I do not believe it. But I'm far more likely to believe all that, than the other crap he was spewing.
  11. Anyway, I'm not trying to convince anyone of using anything. I own an rPI 3 too. But am literally swimming in beaglebones ... between 5 blacks and have had around 50 greens come through here semi recently. SO the advantages of the beaglebone over any other SBC should be obvious to anyone in the field, but for those who are not sure. It's the shear amount of I/O / peripherals the boards is capable of providing all at once. On top of that, there is a pretty solid community behind the board. To be sure there are others that are better for other things. If you just want a low energy usage / "high performance" SBC, the XU4 will wipe out 99% of the boards on the market. At half the cost of the boards that *may* outperform it. I say "may", because an octa-core with 4 of those cores being A15 cores is not something that will be easy to beat. Performance wise. There is only one SBC i know of out there that I'm fairly confident that will beat and XU4, for general purpose computer related things. And that board entry cost is ~$1800 USD, and it has issues. But it's also one of the few ARM based boards with 16G ram as well. But anyway, my purpose here is pretty simple. I know it's not easy always to get information on various hardware. So I almost feel compelled to share my experiences with others, so they may get an idea of what exists, and how it may be useful to them. The ODROID XU4 is not exactly something I'd say could replace a Beaglebone when considering something for a "pure embedded" system. But it does have probably around twice as much I/O when compared to an rPI 3. Where it will really shine, is running a desktop, comparable in speeds to something like a entry to mid range x86 system. It would also serve very well as a low power NAS, or SAN type of system. Since the USB buses, and GbE networking do not share any I/O at all. With that said, it's known that the GbE interface on the XU4 is not a maximum of 1000Mbit, but rather falls a little short at some where around 850Mbit, if memory serves me.
  12. So, the ODROID C2 is nearly exactly the same thing as an rPI3, except the C2 has GbE ethernet, and 2G ram. They both use the same ARM processor type( A53 quad core ), but I also believe the C2 runs at a higher frequency. The C2 also has the ability to use a snap on emmc 5.0 emmc module. At $42 they're only $7 more than an rPI3 shipped, and IMHO well worth the added cost. Additionally, the ODROID C2 is header pin compatible with rPI "hats"
  13. Sure, I get it. Like you, I guess I am just more used to using C most of the time, but I still like many aspects of C++, as well as other languages. It's kind of funny, I was watching a youtube video the other day before bed, and I forget the speakers name( He's pretty well known, I should remember his name, but I dont - I'm not a "fanboy" that way ), where he was explaining why C++ was what he considered the better choice for embedded software development. Then he showed a chart from the last 10-15 years. Which showed C graphing upwards, while C++ was trending downwards . . . Ah right, Dan Saks, but his contention is that C++ is better than C, and I completely disagree with that. I think every language has it's place, and for different people, that will skew one direction or another. But there is a reason why you will never, at least within the near future, see any C++ code in the Linux kernel.
  14. By the way, the ODRIOD C2 was on a 5 week back order because apparently *someone* was buying all the stock AmeriDRIOD had, for production systems. So I did not bother ordering one, yet.
  15. So, I've had an ODROID XU4 sitting next to me for the last month, and I've not really had any time to start off with it - yet. Currently, I have an Asus eeepc with a busted screen serving as my ARM development system, and I'm seriously considering moving all that to the XU4. Because of the USB 3.0, and GbE on the board.