yyrkoon

Members
  • Content count

    1,347
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by yyrkoon

  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. 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.
  3. 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.
  4. 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.
  5. 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 . ..
  6. @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.
  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. So this is not meant as a bashing of C, or C++. Just some observations I've made in the last couple of days while working with both C, and C++. On a Beaglebone, while toying around with reading from a DS18B20 1-wire sensor. Also do keep in mind I'm not exactly an expert with either language, but I would say that I am more proficient in C, than C++. First off. I often have to search the web for perhaps some common things related to any language. Not because I do not know how to do something. But because I often switch between languages for various things, and perhaps I do not remember specific details. Other times, maybe I'm not 100% sure what I need to use for a specific situation. Anyway . . . With a DS18B20 1-wire sensor. In Linux, one has to setup a pin for 1-wire communications. It's fairly straight forward once you figure out how to create a proper device tree overlay for a Beaglebone. Once that is completed, and your kernel modules are loaded. You get a directory listing in /sys/bus/w1/devices/. This sub-directory is based off the sensors serial number, and starts off with "28-", followed by a 12 byte value representing this serial number. Example: william@beaglebone:~/dev$ ls /sys/bus/w1/devices/ 28-00000XXXXXXX w1_bus_master1 Once I had this figured out, while I did not know exactly how I was going to deal with this in C, I knew it would be easy. Now since lately I had been reading up on C++, I figured I'd give it a go with C++. So I did a lot of reading on how to "properly" in C++ read from a file. Okay, no problem there, everything seemed equally as easy in C, just different, and perhaps more readable. As I really do like using classes when working with things of this nature. Then I brushed up on using strings, and various other C++-isms. Again, no problems, until I ran into a hitch. Traversing directories, and building paths from wildcards . . . So this is what I've found out so far from reading many posts on stackoverflow, and other similar C++ forum sites. C++ has no way to work with directories in this manner. Other than falling back on C, and the struct dirent type. Now, I'm thinking to myself "how in the hell is this possible . . .". All while searching the web, more, and more, because I can not believe this is true. Right ? Wrong! So guys, what am I missing ? Passed that, I'm following some C code I found on the web, to work with the sensors sysfs file entry to get data form the device. I then decided to attempt to port the code from C to C++. When I ran into another snag. When using open() on an ifstream object, it expects a const char * value for the path . . . So again, I'm thinking to myself "wtf ?! I'm using a language where string is preferred over char arrays . . ." A language that Kate Gregory(So called C++ expert) proclaims to "stop using C" to teach C++ . . . In addition to the above, in order to format double / floating point value to a specific precision . . . std::cout.setf(std::ios_base::fixed, std::ios_base::floatfield); std::cout.precision(2); So much for %.02f eh ? Anyway, I was able to port most of the code over to C++, at the cost of an additional 14 lines of code. Which the original C code was only 57 lines. At which point I gave up. At least for the time being. Perhaps I need to read more, and get a better understanding of the C++ language. But this bit: dir = opendir(path); if(dir != NULL){ while((dirent = readdir(dir))) // 1-wire devices are links beginning with 28- if(dirent->d_type == DT_LNK && strstr(dirent->d_name, "28-") != NULL) { strcpy(dev, dirent->d_name); cout << endl << "Device: " << dev << endl; } (void)closedir(dir); } else{ cerr << "Couldn't open the w1 devices directory" << endl; return 1; } sprintf(devPath, "%s/%s/w1_slave", path, dev); time_t start_time = time(0); Mostly remains straight C. Because I have not found a C++ equivalent. Which also brings me to time_t time(). . . I do not know, perhaps I'm being pedantic. But when I use a language, I expect to use that language, and not have to rely on another . . . I am however starting to see why Linus Torvalds has a really bad attitude when it comes to C++. [EDIT] Do keep in mind when I say "C++ cant x.y.z . . .", I mean through the STL. I know there are libraries such as boost, and Qt, etc. But I really do not wish to deal with all that . . . for several reasons.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. So in interest of full disclosure. I *will* be purchasing the two board I'm about to mention. Soon. The ODROID XU4: http://ameridroid.com/products/odroid-xu4 The ODROID C2 : http://ameridroid.com/products/odroid-c2 I've done a lot of reading over the last several months. In hopes of finding an embedded Linux SBC(ARM) that can be used as a desktop, as well as a work station for ARM board development. To come straight to the point. For that purpose, and in the same price range. Nothing comes close to the ODROID XU4. The things that "sinched" the deal for me was the quad A15's( quad A7's too ! ), the inclusion of USB 3.0, and true GbE networking( not shared with the USB buses ). A friend of mine has one and has demonstrated it for me a couple times. This thing is a beast ! Passed all that, one can run Android on this hardware, and I've been considering tinkering around with Android development as well, The ODROID C2 is very much like the Raspberry PI 3, but at a higher price point, and added performance / features. I think I paid $35 for my rPI including a power supply, and free shipping. That's a really good price for the hardware. The C2 on the other hand, like stated above has very similar hardware with a few key differences. First, for all intents and purposes they use the same processor type. An A53 quad core. However the C2 is clocked at 2Ghz. Secondly, the C2 has true GbE networking. Potentially very useful for many applications. Lastly, the C2 has twice the memory - 2G versus 1G. We actually have a project involved using a C2 in a professional capacity. No, this project is nothing like a NAS, SAN, or anything of that nature . . .Although it would perform that type of job very well I think. I am very anxious to get my hands on one. Very anxious to get my hands on an XU4 as well, but the XU4 will be more of a toy for a while. As well as handling any kernel, or debian package compiling I need done in the future. What boards are all you interested in ?
  14. 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"
  15. 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.
  16. 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.
  17. 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.
  18. Definitely a lot slower. I'm sitting on a 9/3 Mbit connection, and sometimes I have to refresh the page for a post to take. Keep in mind when I say "sometimes" I've made two posts since the upgrade, and 1 was fine, while the other I had to refresh several times to get it to stick. e.g. The page just sat there "saying" - "Saving. . ."
  19. Didn't know you posted, heh been super busy with the day job building a monitoring system for the company, in addition to building an update system( for our own software )from scratch . . . pretty interesting stuff, and I learned A LOT about systemd services + timers, but without actually getting into the architecture of it all. It's a nightmare trying to visualize all this in your head. Chicken, I've come to realize that that for myself, C is the only real way to go with embedded design. I personally find C++ good for when you need to use a lot of strings, and perhaps other various constructs, it can be ok to work with. But when you need all out performance, C will usually be the best option. Unless you're super proficient with C++, and you write all of, or at least all of the important code from scratch. Same goes for C though really. An example would be my two process application where I needed to share a file between the two halves, and I wrote my own binary file lock. Because the C std API calls were all way too slow. EDIT: Oh, and you can bet I will eventually get around to watching the video.
  20. Yeah, pretty cool little board. I was offered a chance to get a "beta" board in exchange for developing open source software for this specific board. Unfortunately, I was hired full time just a week prior by a person whom was contracting some work out to me . . . So I was, and am still busy doing work for my "day job". I think one of the neatest things about this board, is the Octavo SoM. Which is pretty much an AM335x processor, with internal memory( no need to worry about getting DDR traces exactly right ), and from what I was told around 6 months ago from one of the team members of the SoM is that many of the processors "pins"( balls ) can be brought out and used. Where the beaglebone does have many I/O / peripheral options, but from memory, less than half of the pins are used( if memory serves correctly ).
  21. The only Make book I've had hands on with was a beaglebone book that I got pre-print as I met the author online, and he sent me a copy to review. I suppose from a beginners perspective it may have been useful, but it was all but useless to me. Nothing you could not figure out on your own, using google. Most of the book was an exercise in Linux commands. I suppose if you did not know Linux well, and did not know how, or want to use google. Then it may have been useful. The problem I'm seeing with a lot of these book is that none of them really give you an idea of how an embedded system works. From the perspective of the beaglebone book. It did not teach me how to figure out things on my own. Such as a simple GPIO pin, how does the physical pin number relate to the kernel pins number, then how do those numbers relate to the actual GPIO pin value listed in the sysfs file system. Other periphery was neglected as well in depth. So in the context of the beaglebone, and now RaspberryPI, I'd have to say Derrek Molloy's books are probably the best. But what I described above also applies to DR Molloy's books as well. His books are just better written, with a bit more detail covered. Again, he does cover a few "canned" examples in great detail, with a lot of source code on github to help with these examples. But I do not get the general feeling that I understand the hardware any better from reading his books. Plus, much of his material is now outdated, by 2-3 years. Could I somehow do better myself ? You know, I do not know. First glance, I'd have to say no.
  22. I will add that, I do not know of the others, they look like they'd be good reads, but the Beej guide to( anything ) is not what I'd consider a good "book". I've read through several of his online books, relating to interprocess communications, and networking. Neither of those two topics were very well written, and the content is old. e.g. the content is outdated. I will also add that LDD( Linux Device drivers ) while in hard copy format is a paid book. The author felt compelled to make the book available free online: http://www.xml.com/ldd/chapter/book/ The third edition I believe is also available for free online here: https://lwn.net/Kernel/LDD3/. free electrons also seems to have a single pdf file version, but i have not looked into it. Anyway LDD2 is a very good book if you need to understand Linux device driver, I paid for a hard copy and have not regretted it. For C++, these are supposed to be pretty good as well: http://mindview.net/Books/TICPP/ThinkingInCPP2e.html, but they are dated.
  23. Yeah, this specific format isn't something that I'd need per se. I did look up APA102 a week or longer ago, and got the gist. Basically ws28xx "ish". I'm not exactly sure what I want really. For work, I do need something as a test system for GPIO indication. For this, a serial type LED would probably not be ideal. But for a personal type project, I want something, but don't know exactly what I want yet. Something I can control remotely, something that is RGBW, and then . . . I don't know. The remote bit could possibly be something like an ESP32( if they're out yet ) or of that nature. Then the actual control MCU, I'm not sure.
  24. So coming back to this problem again, just now. I decided for my current purpose to use a shell script. Mostly because a shell script should be readable by most, that are familiar with UNIX like systems, and I'm not the only one maintaining this system. @@Rickta59 bc is a problem, because it does not come default with the current debian image we're working with. Sure I could install bc using APT, but why waste the effort and space ? I did create a simple solution though based off a couple of stackoverflow posts I searched for . . . root@beaglebone:~# temp=$(cat /sys/bus/w1/devices/28-*/w1_slave |awk ' /t=/ {print $10}') root@beaglebone:~# echo ${temp:2} 16812 This is of course fixed type, but I do not necessarily need a floating point type do I ? I don't think so . . . But going back to our discussion from before. Running cat on a 1-wire device, there is a very noticeable 2-3 second pause at the beginning. This pause, as I recall does not happen when I ran the C++ code mentioned previously. With that said, for the purpose I'm using this for. It doesn't matter. EDIT: If floating point did matter though . . . root@beaglebone:~# temp=$(cat /sys/bus/w1/devices/28-*/w1_slave |awk ' /t=/ {print $10}') root@beaglebone:~# awk "BEGIN {print ${temp:2}/1000}" 16.937
  25. @@zeke So *maybe*. I've actually been wanting to some RGB LED experimenting, for lighting purposes in my bedroom. Sunrise alarm clock and all that. But it really depends on the cost. Costs of the board, with LEDs, and cost of the board + LEDS populated. I must say that does look pretty cool ! EDIT: By the way total newb question here. What is "APA102" ?