|
Spatial posted:Now I have a division question When I've had to do stuff like that before, I've usually been able to find some good info or at least something to get my brain in gear in The Art of Computer Programming. There is a big section on arithmetic algorithms.
|
#
?
Jul 31, 2015 21:29
|
|
|
|
| # ? May 11, 2024 23:11 |
|
|
Yeah, I was just looking at Knuth's Algorithm D in Hacker's Delight. Looks promising.
|
|
#
?
Jul 31, 2015 21:53
|
|
|
It works! But I had a realisation this morning: the program logic can be structured so I don't need the modulo at all. Hahahaha.... God drat it. 
|
|
#
?
Aug 1, 2015 15:20
|
|
|
I'm having a blast with the recently released TIS 100 game, which has you programming assembly for a fictional multi-core computer. The architecture is super limited, which makes even the simplest of operations quite puzzling. I recommend it for fans of puzzle games and/or assembly. Now my wife is into it. I hope it's a gateway to assembly on a real architecture.
|
|
#
?
Aug 2, 2015 13:25
|
|
|
Spatial posted:It works! But I had a realisation this morning: the program logic can be structured so I don't need the modulo at all. Hahahaha.... God drat it. I always used to feel bad about obsoleting something clever, but honestly now there's no better feeling than removing entire sections or even files worth of code. So satisfying. An empty file automatically has 100% code coverage.
|
|
#
?
Aug 2, 2015 19:44
|
|
|
Agreed. Doubly so because this is going into a production ROM.
|
|
#
?
Aug 3, 2015 00:18
|
|
|
sliderule posted:I'm having a blast with the recently released TIS 100 game, which has you programming assembly for a fictional multi-core computer. What's your favorite slide rule?
|
|
#
?
Aug 3, 2015 08:29
|
|
|
sliderule posted:I'm having a blast with the recently released TIS 100 game, which has you programming assembly for a fictional multi-core computer. This but with embedded stuff and not forklifts 
|
|
#
?
Aug 4, 2015 15:40
|
|
|
That analogy would hold truer if it were Game Dev Tycoon. For TIS 100 to be in league with Forklift Truck Simulator, I would have to control a character who was virtually programming assembly. Also, I'm not sure what's going on in that last panel. sarehu posted:What's your favorite slide rule? NEVER slide down headfirst.
|
|
#
?
Aug 4, 2015 17:42
|
|
|
thanks dad
|
|
#
?
Aug 4, 2015 19:23
|
|
|
TIS-100 is cool and scratches the itch of wanting to work in assembly when you can't find a reason to actually write something in assembly.
|
|
#
?
Aug 15, 2015 19:41
|
|
|
What's the difference between a FPGA and a CPLD? If you're considering that you might want one of those for a project, how do you know how many logic elements or w/e you need? FPGA stuff has always seemed like voodoo to me, is there a thing that breaks it all down.
|
|
#
?
Aug 24, 2015 20:15
|
|
|
Crankit posted:What's the difference between a FPGA and a CPLD? I've always wondered too, are they just a bunch of NAND or NOR gates plus input/outputs?
|
|
#
?
Aug 24, 2015 20:35
|
|
|
xilni posted:I've always wondered too, are they just a bunch of NAND or NOR gates plus input/outputs? Generally CPLDs are much much smaller / less powerful / less complex than full-blown FPGAs -- at one point the architectural difference was that a CPLD was just a 'sea of gates' that you could connect in various shapes, whereas FPGAs were based on a modular block based architecture, where LUTs of various size are used to form logical functions.
|
|
#
?
Aug 24, 2015 21:00
|
|
|
movax posted:Generally CPLDs are much much smaller / less powerful / less complex than full-blown FPGAs -- at one point the architectural difference was that a CPLD was just a 'sea of gates' that you could connect in various shapes, whereas FPGAs were based on a modular block based architecture, where LUTs of various size are used to form logical functions. It's also important to note that CPLDs are non-volatile, whereas FPGAs need to be reconfigured from external memory at reset. I've seen a CPLD (or maybe it's a PLA, but the distinction isn't critical) used as glue logic for a hardware power source manager (where using discrete components would be too big). In that situation, it is important to have the logic available as soon as power as present (even before regulators can stabilize) so that the hardware can be setup properly and allow the rest of the system to boot up. Slanderer fucked around with this message at 21:20 on Aug 24, 2015 |
|
#
?
Aug 24, 2015 21:18
|
|
|
There's sort of a hierarchy of programmable logic devices which nowadays matters much less than it used to. At the very bottom you have things like PALs, which are basically a bunch of inputs, split into normal and inverted signals for each input, and then connected to a programmable crossbar, which then connects to a bunch of AND gates, which are typically all merged together with some non-programmable logic (like a single giant OR gate). So, if your logic looks like a bunch of AND gates with possibly-inverted inputs, followed by a single OR gate (or maybe an OR gate with possibly-inverted inputs) then you can use a PAL. PLAs are the same, except there's a second programmable crossbar between the ANDs and the output gates. So, if your logic looks like a bunch of AND gates with possibly-inverted inputs, followed by a bunch of OR gates with possibly-inverted inputs, then you can use a PLA. Some of these early systems may only be single-time programmable, using fuses instead of switches internally. CPLDs introduce some kind of routing network, so that you can take a signal and wrap it back to the input-side of the chip somehow, forming loops in your logic. If you logic looks like a smallish network of ANDs, ORs, and inverters, then you can use a CPLD. Some CPLDs also have some form of latches, allowing for register-delays. FPGAs have a very complex routing network, with the chip organized in a grid of lookup table-based cells (which can implement e.g. any 4-input 4-output logic function and typically have optional latches on the outputs) and each cell can connect to its north/south/east/west neighbors. Typically there is also some form of express routing network layered on top of this to quickly move signals across the chip, as well as specialized cells that perform expensive tasks like multipliers or PLLs. Because of the complex routing fabric, FPGAs can make reasonable use of vastly more logic cells than simpler architectures, often by orders of magnitude. FPGAs are interesting enough that you can realistically implement something like an entire processor. There's lots of little extras going on at the same time. Some FPGA architectures have carry-chain assist logic built in at various parts of their layout. Some FPGAs and CPLDs have integrated microcontrollers, or RAM banks, or other highly specialized subcomponents. The general reasons to prefer something other than a FPGA are either lower cost, lower power, or higher speed. FPGAs pay a relatively high penalty for their complexity, whereas the simpler architectures can eek out an edge. But at this point because it's so much nicer to work with FPGAs, the various FPGA architectures have been worked on so much that they are highly competitive in the speed domain, and only marginally worse when it comes to cost or power usage. FPGAs typically require a more complex board design to work with than anything else. CPLDs and simpler chips will almost always have their program stream "built in" somehow, while FPGAs will almost universally require an external EEPROM or something to carry the program stream, which is read when the chip first powers up. Obviously, this also results in the power-up time for the circuit being longer, although typically not by much unless you are dealing with absolutely enormous chips and programs. All of this is sort of blurry; modern CPLDs are probably internally using cells fairly similar to those of FPGAs, because it's easier for the companies to unify their architectures, and just have a simpler routing network. At this point, PALs and PLAs are honestly hard to source; basically every manufacturer will prefer to just sell you a CPLD, because they aren't any more expensive to make or use and are more useful. FPGAs from different manufacturers may have wildly different routing philosophies, which can matter deeply for different applications. For anyone who is just exploring the field without particular power or speed requirements, I would suggest sticking with the FPGA domain rather than CPLDs, because it's easier to program. Estimating logic gate usage is honestly hard without some experience in seeing what various designs look like on various architectures; in general, if you're new to the field, you aren't going to build anything large enough to have serious worries, so you can just get something cheap.
|
|
#
?
Aug 24, 2015 21:19
|
|
|
Slanderer posted:It's also important to note that CPLDs are non-volatile, whereas FPGAs need to be reconfigured from external memory at reset. I've seen a CPLD (or maybe it's a PLA, but the distinction isn't critical) used as glue logic for a hardware power source manager (where using discrete components would be too big). In that situation, it is important to have the logic available as soon as power as present (even before regulators can stabilize) so that the hardware can be setup properly and allow the rest of the system to boot up. That applies to SRAM-based FPGAs (the majority); there are flash-based FPGAs like Actel (Microsemi) IGLOO/IGLOO2 which have a selling point of them being live at power-on and requiring no external configuration memory. You also have anti-fuse devices, which of course have their configuration burned into them via silicon sculptor / the programming tool.
|
|
#
?
Aug 24, 2015 21:29
|
|
|
Do most FPGAs have NAND or eMMC packaged onto the die so you don't physically need an external chip?
|
|
#
?
Aug 24, 2015 23:10
|
|
|
Popete posted:Do most FPGAs have NAND or eMMC packaged onto the die so you don't physically need an external chip? Nope, just a variety of different ways to load the configuration bitstream. Design security is done via AES, eFUSEs, etc. Generally it's serial flash memory, but there's also some parallel schemes floating around, and some systems dispense with the memory entirely (at least directly) and have the FPGA programmed in-circuit (ISP) by some other processor. Altera/Xilinx FPGAs are all SRAM -- no other way to get the desired performance. The majority of the bitstream size would be eaten up by configuring all the BRAMs. Their CPLDs have internal memory to store configuration. Aforementioned Microsemi parts are flash -- no external memory needed. Helps with design security too.
|
|
#
?
Aug 24, 2015 23:25
|
|
|
Crankit posted:What's the difference between a FPGA and a CPLD? To answer your second question, you write out your VHDL/Verilog in a vendor toolchain, and it will synthesize the design and spit out a number of logic gates / whatever metric that particular vendor uses. The languages are mostly device-agnostic, so it's easy enough to shop around if you're unsure which to go with.
|
|
#
?
Aug 25, 2015 00:03
|
|
|
I ended up buying one of these after reading the last few posts about FPGAs: http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCEstick.aspx I have a project that an FPGA would be perfect for, it's just really tough to pick out a relatively pricey piece of silicon from all of the marketing, especially when I don't know a whole lot about them. Things like how much power a design uses on an arbitrary FPGA seems completely indeterminable to me. Converting from CNF to some number of LUTs and flip flops isn't obvious to me, but I can guess. It turns out Lattice sells a slew of cheap dev boards though, I'm not sure why I thought they were all (still?) several hundred dollars. It might be a good option for others that have the same dilemma. Also the datasheet for it is really easy to read and really detailed: http://www.mouser.com/ds/2/225/iCE40FamilyHandbook-311139.pdf
|
|
#
?
Aug 25, 2015 01:16
|
|
|
dougdrums posted:I ended up buying one of these after reading the last few posts about FPGAs: http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCEstick.aspx ICE40s are quite nice for small projects as they don't have a huge amount of LUTs, and are used quite a bit as glue logic for phones/wearables I believe. The main problem I find is that the software is nowhere near as intuitive as Quartus II, and rather more text config file based. Nonetheless, it's quite good to learn with, as the dev boards are quite good, and more importantly, cheap.
|
|
#
?
Aug 25, 2015 12:32
|
|
|
I'm still learning the Launchpad (C++ programming in general) and have a tutorial book on the basics. For "if" statements, it suggests making a flowchart of what you want to do and going from there, so that's where I'm at. I want to put a battery in a machine, then turn the machine on and let it run until the battery dies and (1) have a visual display in hours:minutes and (2) create a pass/fail log if it lasts 4 hours or more. The machine has an auto shutoff when the voltage drops below a certain level and a 5V output that I can tap into while it is running. I want to feed that 5V into an input pin and use that as the starting block of this flowchart:  Bottom Block 1: I've never worked with LCD or segmented LED displays before. I'm guessing that I probably won't be using a 60 second delay as a trigger, but that is the general idea. What is a good resource to learn how to have a Launchpad output increment a stopwatch that displays the output in hours and minutes? I don't care about seconds. Bottom Blocks 2 and 3: I'd like to record long term failure rates. My idea is to use some sort of non-volatile memory to store how many "passes" and how many "fails" have happened and then read that back in and display on an LCD or segmented LED. I have no idea how to actually do this. Where is a good place to learn about writing and reading to non-volatile memory with a Launchpad?
|
|
#
?
Aug 28, 2015 03:50
|
|
|
SkunkDuster posted:Bottom Block 1: I've never worked with LCD or segmented LED displays before. I'm guessing that I probably won't be using a 60 second delay as a trigger, but that is the general idea. What is a good resource to learn how to have a Launchpad output increment a stopwatch that displays the output in hours and minutes? I don't care about seconds. quote:Bottom Blocks 2 and 3: I'd like to record long term failure rates. My idea is to use some sort of non-volatile memory to store how many "passes" and how many "fails" have happened and then read that back in and display on an LCD or segmented LED. I have no idea how to actually do this. Where is a good place to learn about writing and reading to non-volatile memory with a Launchpad? Also consider the usability for your retrieve function. Are there going to be runs you don't want recorded? Is the information going to be useful if it isn't attached to a specific battery? Do you want a button to toggle the display between time and history?
|
|
#
?
Aug 28, 2015 22:17
|
|
|
Captain Cool posted:If you don't have a display yet, look up the TM1638 display module from dealextreme or wherever. For three GPIOs you get eight digits and eight LEDs. The datasheet is not that readable but all the information you need is in there. There are libraries around for Arduino and Raspberry Pi that you can use as a reference. This is all very new to me, but that gives me an idea of what components to buy and learn how to use which is very helpful. I'm familiar with basic electronics, but programmable micro controllers are completely new to me. Pretend I just crawled out of a time capsule from 1978. I'm looking for resources to learn how to use the Launchpad to solve these steps in the project. The book suggested coming up with an idea, then making a logic flowchart on how to accomplish what I'm after. I got that much and now I see I need to learn the fundamentals of sending an output to a display and reading and writing to an EEPROM. I have no idea how to do either of these things. Captain Cool posted:Also consider the usability for your retrieve function. These are some very good questions and I'm impressed you would think of them without even knowing what I am working on. Captain Cool posted:Are there going to be runs you don't want recorded? Yes, there are a lot of runs that I don't want to record. After building a battery pack, we drain it (on a test machine) and recharge it to full before starting the test cycle. Every one of those drains would be a failure. I was thinking about this today and I would like the amber light to blink when a machine is on (not recording or counting) and then have a button labeled "TEST" that would turn the amber LED on solid and start counting and record the result. I could use one color of LED for "machine is turned on" and another color for "testing", but I only have 3 colors of regular dim LEDs, so that's why I'm planning on two states for the amber LED. I have tons of ultra-bright LEDs in various colors, but I don't want to get blinded every time I look at the panel. PWM is an option for dimming, but that would complicate the code quite a bit, so I'm just going to make it work with red, green, and amber. Another reason to do it this way is that the blinking would get your attention to remind you to hit the "test" button. edit: Instead of using LEDs, I'd like to use LCDs that can change the colors of the backlights to indicate different states, but I don't know if I'd be getting myself in too deep by going that route. Captain Cool posted:Is the information going to be useful if it isn't attached to a specific battery? Yes. There are 10 test stations. The whole reason I want to do this is because the failure rate seems higher than it should be and I would like to see if one of the test machines is causing it. The current draw is the same on all machines, but I suspect there may be some intermittent problem with a machine that is causing false failures of the batteries. We also have 10 battery chargers so that complicates fault isolation. It isn't feasible to keep track of all that in a spreadsheet. Knowing if one test machine has an unusually high failure rate would be very useful. Captain Cool posted:Do you want a button to toggle the display between time and history? I considered this, but would rather just have both displayed at all times. Either with a two line LCD or an extra LED segmented display per station. The math would be ---- (100/(fail+pass))*fail ---- and then display the result. Skunkduster fucked around with this message at 03:55 on Aug 29, 2015 |
|
#
?
Aug 29, 2015 03:47
|
|
|
can't really contribute too much as i'm posting from a ferry, but don't discount standing on the shoulders of others. before doing anything i would look into battery controller ICs to see if any do a reasonable portion of what you're trying to do. a product i work on uses a ni-cad battery and after reading about the cell chemistry, charging stages, trickle charging, etc., i'm very grateful our hardware team included a battery charging IC that reports on the health of the cell so my code can just check the level on a pin while running. we derive capacity from the run time of our product, but i'd be surprised if there wasn't something out there that can give you more comprehensive information and in perhaps less time than it takes to drain all the cells.
|
|
#
?
Aug 29, 2015 17:37
|
|
|
The msp430's have internal flash you can read/write to, so you don't actually need an external chip. Energia comes with a library (mspflash) and an example program. https://github.com/energia/Energia/blob/master/hardware/msp430/libraries/MspFlash/examples/flash_readwrite/flash_readwrite.ino Note also that any flash/eeprom is cycle limited. Typical numbers are either 10,000 or 100,000 cycles. You'd need to look up exactly what you're using. If you write once a second, and you have something that can only take 10k cycles, you'll get 6.9 days of use. This is per address you use, so if you were able to alternate between 2 addresses, you'd get 14 days, and so forth. Or if you wrote something once an hour, you'd get 1.1 years out of one address. If you only wrote elapsed time when it failed, even if it failed daily, you'd still get decades of use out of one address. Of course then you'd loose count if the power failed while a test was going on, and you'd get garbage results. http://processors.wiki.ti.com/index.php/Emulating_EEPROM_in_MSP430_Flash Also, you can't put 5v directly to a launchpad. You'll need some kind of level shifter ( for this, a voltage divider is far and away the easiest) to bring the the level down to 3.3v. Aurium fucked around with this message at 21:12 on Aug 29, 2015 |
|
#
?
Aug 29, 2015 20:56
|
|
|
SkunkDuster posted:This is all very new to me, but that gives me an idea of what components to buy and learn how to use which is very helpful. I'm familiar with basic electronics, but programmable micro controllers are completely new to me. Pretend I just crawled out of a time capsule from 1978. Looks like Launchpad's equivalent of shields is called Boosterpacks. I see boosterpacks for ADS1118 and an rf module that include a two-line LCD. It is cheaper to wire it up yourself, but these things should just plug in to your board. Definitely use internal flash for storing runs. I should have thought of that, but I guess I've spent too long working with microprocessors that don't have that option.
|
|
#
?
Aug 29, 2015 23:13
|
|
|
Aurium posted:The msp430's have internal flash you can read/write to, so you don't actually need an external chip. The MSP430FR series uses ferroelectric ram, which is nonvolatile, faster and lower power than flash, doesn't have any meaningful endurance problem, and is accessed just like regular old SRAM.
|
|
#
?
Aug 30, 2015 07:07
|
|
|
sund posted:we derive capacity from the run time of our product, but i'd be surprised if there wasn't something out there that can give you more comprehensive information and in perhaps less time than it takes to drain all the cells. We do it this way because there is a circuit board in the battery pack that "learns" the charge time and then outputs it to a display on the equipment that tells the user how much battery time is remaining. The board also has stuff for current limiting, heat sensing, a diode for reverse polarity protection, etc, so even if there was something like that out there, I wouldn't trust that it would be able to directly access the cells to give meaningful data. Aurium posted:If you only wrote elapsed time when it failed, even if it failed daily, you'd still get decades of use out of one address. Of course then you'd loose count if the power failed while a test was going on, and you'd get garbage results. Probably 5-10 writes a month, so no problems there. Are you saying I'd get garbage results for that particular run, or that it would corrupt historical data? I'm assuming the former, but just wanted to make sure. Aurium posted:Also, you can't put 5v directly to a launchpad. You'll need some kind of level shifter ( for this, a voltage divider is far and away the easiest) to bring the the level down to 3.3v. Thanks, I was planning to look that up to be sure. I could do voltage dividers with resistors, but will probably go with voltage regulators because the company is footing the bill for this project.
|
|
#
?
Aug 30, 2015 08:04
|
|
|
Wait what, don't use linear regulators for level shifters, they'll mangle digital signals because they're not designed for fast rise and fall times.
|
|
#
?
Aug 30, 2015 09:35
|
|
|
I impulse bought a couple Photons a while back and they just came in. I didn't do enough background research and it turns out these things are a huge pain in the rear end to develop on. The particle team has "disrupted" the poo poo out of embedded dev by making every interaction with the photon have like 4 different middle men ~in the cloud~ Flashing the LED blink script to my Photon doesn't make it flash its LED, it just puts it in safe mode for some reason. Have any of y'all had better luck with these things?
|
|
#
?
Aug 30, 2015 14:20
|
|
|
SkunkDuster posted:Probably 5-10 writes a month, so no problems there. Are you saying I'd get garbage results for that particular run, or that it would corrupt historical data? I'm assuming the former, but just wanted to make sure. You assume correct. I mean just that run. If you only save at the end you'd lose elapsed time, presumably starting over when power is applied again. So if you lost power 3/4 the way though a test, it would run again for the rest, and then record a time of about 1/4. SkunkDuster posted:Thanks, I was planning to look that up to be sure. I could do voltage dividers with resistors, but will probably go with voltage regulators because the company is footing the bill for this project. As someone else noted, linear regulator isn't the right way to do this. For a power/no power case like this, it would probably work, but you'd get a big huh moment from anyone looking at the board. I also think it would leave the pin floating when the regulator turns off due to insufficient input voltage (or at least in a relatively high impedance state), where you actually want it connected to ground in that case If you want experience doing it the "right" way, look up a level shifter IC, or potentially a buffer or even a comparator. And by right way, I mean the right way for high speed circuits. For low speed, a resistor divider probably actually is the right way for its ease and low price.
|
|
#
?
Aug 30, 2015 16:45
|
|
|
SkunkDuster posted:Probably 5-10 writes a month, so no problems there. Are you saying I'd get garbage results for that particular run, or that it would corrupt historical data? I'm assuming the former, but just wanted to make sure. Since you're storing multiple pieces of data, you can have issues if the chip resets between writes. You might count a failure without counting the run. A basic protection method would be to store a backup copy of that data and flags saying that you're updating the main or the backup. If the flag is bad on startup, restore the data from the other copy.
|
|
#
?
Aug 31, 2015 15:11
|
|
|
Aurium posted:As someone else noted, linear regulator isn't the right way to do this. For a power/no power case like this, it would probably work, but you'd get a big huh moment from anyone looking at the board. I also think it would leave the pin floating when the regulator turns off due to insufficient input voltage (or at least in a relatively high impedance state), where you actually want it connected to ground in that case My thinking was that the voltage regulator would protect the circuit in case the 5V input destabalized and jumped up to 12V for some reason. I fully expect the 5V will be stable and never fail, but it was a "better safe than sorry" type of thinking. If it raises the cost of the project $30 or even $50 (10 inputs) that is fine. Regarding the floating state when the 5V input is absent, would it work to configure the input pin as a "pulldown" or tie the pin to ground through a 10K resistor? Captain Cool posted:With flash memory, in the general case, you need to erase data before you can update it. Erasing a sector sets all bits to 1, and writes can only set bits to 0. If your chip resets for some reason in between the erase and the write, your data is gone. There are various ways you can detect and correct a problem like this. But it looks like the Launchpad uses FRAM, which doesn't need an erase before the write. Try to use native/atomic types so the data is updated with one opcode. I don't expect any corruption in that case unless a lightning bolt knocks out the building power at the exact moment it is doing the erase/write. Learning this is going to be the biggest hurdle for me. Honestly, the extent of my knowledge on this is that there are memory ICs that can be written/read, some are volatile and some are not, some forms of memory can be accessed by individual bytes and others only by sectors. That is about it. I pretty much need a "EEPROM for dummies" at this point, but I do have a couple of specific questions. There are suggestions to use the chips memory to store the test results, and that makes sense. Is the memory area where I would record these results the same area that the program is stored? If so, how would I make sure that I'm not writing the test results over the program code and corrupting it? My plan is to use 4 bytes for each of the ten test stations to record pass/fail data. 2 bytes to record the "passes" and 2 bytes to record the "fails" for a total of 40 bytes to record all the data. To display the failure rate, I'd read those 4 bytes, do the math (determining total runs by pass+fail), then output the percentage to the LCD. Is that a logical way to approach this, or am I thinking about this all wrong? It would be nice to also record and display "average historical run time" for each station, but I'll cross that bridge later. What's the best way to convert a number of seconds to hours:minutes:seconds? I'm assuming that I will be counting the time internally in seconds and end up with something like 15,798. How do I convert that to 4:23:18?
|
|
#
?
Sep 1, 2015 02:42
|
|
|
SkunkDuster posted:My thinking was that the voltage regulator would protect the circuit in case the 5V input destabalized and jumped up to 12V for some reason. I fully expect the 5V will be stable and never fail, but it was a "better safe than sorry" type of thinking. quote:Regarding the floating state when the 5V input is absent, would it work to configure the input pin as a "pulldown" or tie the pin to ground through a 10K resistor? quote:I don't expect any corruption in that case unless a lightning bolt knocks out the building power at the exact moment it is doing the erase/write. Anyway, this is not important to pound out up front. It's one of the things that will take this from a project to a product. quote:Learning this is going to be the biggest hurdle for me. Honestly, the extent of my knowledge on this is that there are memory ICs that can be written/read, some are volatile and some are not, some forms of memory can be accessed by individual bytes and others only by sectors. That is about it. I pretty much need a "EEPROM for dummies" at this point, but I do have a couple of specific questions. There are suggestions to use the chips memory to store the test results, and that makes sense. Is the memory area where I would record these results the same area that the program is stored? If so, how would I make sure that I'm not writing the test results over the program code and corrupting it? I guess you will need to track down multiple datasheets. The MSP430 datasheet doesn't mention the MPU, but the FRAM datasheet does. quote:What's the best way to convert a number of seconds to hours:minutes:seconds? I'm assuming that I will be counting the time internally in seconds and end up with something like 15,798. How do I convert that to 4:23:18?
|
|
#
?
Sep 1, 2015 03:20
|
|
|
SkunkDuster posted:What's the best way to convert a number of seconds to hours:minutes:seconds? I'm assuming that I will be counting the time internally in seconds and end up with something like 15,798. How do I convert that to 4:23:18?
|
|
#
?
Sep 2, 2015 01:50
|
|
|
John Big Booty posted:(seconds%3600) : ((seconds%3600)/60) : (seconds % 60) 1:0:1 2:0:2 3:0:3 ... 59:0:59 60:1:0 61:1:1 That is not how hours work. (the correct answer is (seconds / 3600) : ((seconds / 60) % 60) : (seconds % 60))
|
|
#
?
Sep 2, 2015 02:03
|
|
|
ShoulderDaemon posted:1:0:1
|
|
#
?
Sep 2, 2015 02:48
|
|
|
|
| # ? May 11, 2024 23:11 |
|
|
SkunkDuster posted:My thinking was that the voltage regulator would protect the circuit in case the 5V input destabalized and jumped up to 12V for some reason. I fully expect the 5V will be stable and never fail, but it was a "better safe than sorry" type of thinking. If it raises the cost of the project $30 or even $50 (10 inputs) that is fine. Regarding the floating state when the 5V input is absent, would it work to configure the input pin as a "pulldown" or tie the pin to ground through a 10K resistor? If you expect it to be spikes, a zener diode shunt is the correct way to do it. If the peaks might be able to source high current, and If your load is high impedance (like a uC input pin), a series (current limiting) resistor to a voltage divider to a zener diode shunt would be able to handle truly impressive over voltage conditions. If your load is somewhat lower impedance, you'd be better served by a buffer that can already tolerate your expected input voltage range. Most hex buffers can do this, most datasheets will have words to this effect, such as. ST's HCF4050B posted:The input high level signal (VIH) can exceed the VDD supply voltage when these devices are used for logic level conversions. VIH here can be +15V. 6 per chip for this one too. (most are 6 per chip)
|
|
#
?
Sep 2, 2015 20:36
|
|