enl
-
Content Count
346 -
Joined
-
Last visited
-
Days Won
22
Posts posted by enl
-
-
I tend to use this style for many things, in particular single thread embedded applications like one tends to have on the smaller MSP430's, but it isn't always my preference.
The code tends to be more readable if done reasonably well, with full optimization available since it is expanded by the preprocessor, but inline functions can be just as efficient and are often less likely to lead to debugging issues, making them generally preferable when available, but with the drawback that expansion is not mandatory, so timing is not guaranteed. If forced, you lose some space optimization features.
-
They are not cheap, but keep in mind that they developed the software, and, unlike some of the clones (by the magic of google) actually perform as advertised
I may be biased, having spent several thousand dollars for significantly less performance during the present millennium for a dedicated device, but I see it as a real deal.
With the USB units, buffering is a concern, but none of them (as far as I can tell) are over endowed with memory. They need a USB channel that can suck up data and a host that can do something with it. I have had no issues at 500MHz with a saleae pro on a netbook, but I am not streaming netflix when I am using it. You are looking at low speed UART work, and I would bet a ZX81, or bottom end saleae clone, would be capable of dealing with it.
If you are in a time pinch, at those speeds, an MSP430G can split the bits and ram them up the USB line from a launchpad. A 13$ msp432 can do a lot better than that.
Given what you are looking at, you are likely to need to write your own protocol analyzer, or see if one is available for a standard device. The Saleae has the advantage of a reasonable dev environment for rolling your own protocol analyzer.
The only things showing up in a quick google search that do DALI are pretty far up in price and are locked up against building your own.
If it were me, and a deadline was up, I'd call saleae and grab the logic-4 or logic-8 on fast shipping.
If $100 is a killer, then you already blew too much time on the project.
-
I have and use a Saleae logic-8, and have a logic-8pro at work. The lowest end is logic-4 at about $110. For what you are looking at (sub-100KHz) the logic-4 would do well as the sample rate is 12MHz. The logic-8 is 100MHz sample, which is reasonable to about 10MHz systems. There software has several protocol analyzers (I2C, SPI, RS232/standard serial, USB, and about 20 others) and I think it is possible to write your own. I have nothing but good things to say about the unit, and would only give the standard cautions that the units are most useful on a laptop running on battery power to avoid ground issues. A number of the far east import units are near clones, but I can not speak for the quality of them. (one I was looking at had a link to Saleae for the software. I thought that was a bit.... scummy)
The reason I went for this is that the reviews were good, the sample rate was sufficient for most of what I need, low V to 5V logic compatible, protocol decoders for things I need are not extra cost, and the software is a good match for what I have used in standalone units for many common features. You can pull the software and play with it without the unit. If there is no unit on the computer, the software fakes it for you for demo.
Learning curve is good enough that I have had students using it to debug I2C and SPI in less than 15 minutes. Not experienced students, but first time with anything more involved than blink an LED level students.
Edit: watched the video you linked. Looks like a Saleae clone. I don't like the plastic case (shielding issues), but at sub-mhz it is likely not a problem. I haven't used the software he uses. I have a windows machine for such things (due to Autodesk, oscilloscope remote UI, and the microscope cameras), so it isn't a hassle.
-
What orientation do you have for a project? The capabilities of the processors differ so much that it is difficult to answer your question without knowing where you are going. No sarcasm is intended in the following suggestions:
Robotics? You can do multiaxis control in real time.
Audio? You can do signal processing within the limits of the ADC resolution.
Video? I would guess that you could produce VGA output to run 640X480 VGA at 8 color (one bit per color), or possibly better with some careful programming, and have no major issue producing a videogame. Certainly 320X240 should be straightforward. Using R-2R chains, you could easily produce interesting video output, though anything requiring a frame buffer would likely be out due to RAM limitations. It would probably not be too hard to produce NTSC in the same vein as an Apple II.
The gains you get with the 432 include speed, memory, and processing per cycle. With a 430, serious audio isn't really practical. Real video is superstar territory. With the 432, both are straightforward, though not necessarily trivial.
Specific ideas in audio: A guitar multi effect, maybe distortion, Wah (a pot on an ADC for bandsweep), flange, and reverb. All are moderately straightforward, but explore different algorithms.
Video: One of the coolest thins I saw at a trade show in the late 70's was a video dazzler. Just cool patterns, but really, really cool. An audio input to control an arithmetically produced pattern as VGA output?
Robotics: An 8 channel, I2C command servo controller?
Do you ride? One of the things I did years ago with a PIC was an electronic ignition for a 1975 Honda CB400F (4 cylinder). Maxed out at about 12000RPM. The unit was tight to about 8000, but had a bit of jitter above that. Drove an output for the tach as well. The 432 can cover other things at the same time, and not lose it's place for the ignition timing.
Got a cat? Using the ADC and DSP capability, an ultimate class cat toy? Detect appropriate stimulus (Meow, scratching, othe r) using a microphone, and do something interesting, like turn on a laser pointer mounted on servo's to entertain the cat, and when it gets to a certain point, release a treat?
Ok... my mind runneth over. Several of these are things I don't have the time to do. There are many, many more. All of these take more than the 430 can reasonably do (except ignition timing), but none fully explore the capability of the 432.
-
I suspected this as result of placing an order and getting free shipping. Nice to have it confirmed. The free license for full CCS with the launchpad is also still active, though the checkout added a number of other things for no reason (25 pack of launchpads, full CCS for full cost, and a couple other things), but they were deletable.
-
Starting point is you have an off by one eror on the loop counter: the test should be "<5", not "<6" as you are trying to do it.
But, I think the main issue is that A0, A1, etc are aliases for pin identities, not channel values. You might try:
const int analogpins[]={A0, A1, A2, A3, A4}; . . . . for (int i=0; i<5; i++) { sensorValue=analogRead(analogpins[i]); . . .- dubnet, energia and morelius21
-
3
-
@@roadrunner84 The circuit can be used for on-off. When a signal is not present, the period is greater than a boundary value. When it is present, the period is less than the boundary value.
The advantages to this type of circuit over many alternatives are simplicity and versatility. It can be used for FSK, OOK, and can be used for standard serial, FM and MFM self timed communication, among others. For FSK and OOK, a minimum number of cycles can be used per bit, often only one, if the channel otherwise doesn't affect phase with frequency or have significant filtering.
The drawback is that, in applications where you NEED to use a carrier (such as On-Off or FSK) due to channel properties, the processor has to do timing at higher than bit rate frequency and can't treat the input using standard UART tools.
The historical application that comes to mind (1977) for this is the TRS-80 cassette, where, rather than use the Kansas city standard, FM (and MFM) were used with a standard audio cassette recorder. Quite reliable and tolerant to timing variation at one transition per bit. Similar methods were used into the mid-1980's by several other manufacturers.
-
How about a circuit like this?
That is what I was describing. The upper section is your minimum (FSKIN side). This is, again, presuming that the MSP430 will do timing of state changes to get frequency. This is presented essentially as an analog connection, but, with a Schmidt trigger input pin, you get zero crossing detection.
- energia, abecedarian and pokmo
-
3
-
Probably not, but the key thing are that a) the signal should center around Vcc/2 (1.5V in a 3V system),
teh level should not go outside power supply bounds, and c) the swing should be more that 2/3 Vcc p-p. Additionally, fast transitions are nice, but may not be achievable with audio output device. Using a Schmidt trigger input (available for the timer inputs) makes this less critical.The need for an op-amp would be due to insufficient level from the audio output. A line level output will be about 2.2Vp-p into 50Kohm, but headphone outputs may or may not meet this, and a line level output may drive much higher voltage open circuit. My design would be 5K in series with a 100nF cap (or larger), feeding the center of a voltage divider made with a pair of 100K resistors for biasing. If the input is Schmidt trigger, no issues with biasing to mid range. (For an input htat is NOT Schmidt trigger, do not do this, as the input may enter a state that leads to internal high current and damage.)
If the output level into 50K is much less than this (I would be surprised), then a gain stage (op-amp) would be needed.
This is not the greatest scheme in the world, but is pretty much what the most reliable cassette tape storage schemes in the late 1970s used. Again, I would tend to stay away from the audio hardware, but if you gotta, you gotta.
-
I see. I'm just hoping to take (audio) commands from the PI and control a DC motor with a MSP430. So the data won't need to be transmitted. Does that mean the Soft Modem demo is irrelevant since it expects a phone line and UART on RX and TX, respectively? Sorry, I'm very new. I know I could use USB instead, but I wanted to control the MSP430 with javascript.
Rather than an ADC and FFT filtering, could I just use RC filters?
Thanks
You haven't make clear what you mean by audio commands. Do you mean something like tones as used in touch tone telephones? Or are you just interested in getting useable information from the pi to the MSP430 via the audio output in any format at all? or are you just interested in getting data from one to the other and selected the audio output by default?
If the first or second, single tone detection isn't that hard. I would use capacitive isolation and protection diodes to limit the signal. Bias with a voltage divider to the middle of the power supply range, and then, using a digital input and timer, time the period. Different frequencies to differentiate commands/states.
If you aren't tied to the audio line, using straight digital lines would be preferable. You could use a standard serial, or use SPI, or I2C, or... Straight serial is likely easiest, as that is the least setup from the PI end, and easy to handle from the MSP430 end, since there are a minimum of protocol issues.
As you move to an old laptop, it will almost certainly have a serial port available (though it will need level conversion for interface with the MSP430). Audio may be unreliable, especially on older hardware, due to timing issues, etc. Many older devices (post soundblaster) didn't have any audio hardware to speak of. All software driven, like the modems. This led to some, um, interesting, issues during sound production, including poor timing, unpredictable skips from the buffer, and dropped intervals. Serial was was hardware all the way, other than a few cases with 8-bit systems, since so little hardware is involved. By the mid-1980's (80286 era), it was generally included as an integrated part of the system chipset.
-
-
The guideline for picking a clock source and the required accuracy and stability is pretty straightforward, but in general, using the DCO is what you want. If you have the crystal in system, the DCO frequency can be compared to it and the bit rate divisor can be adjusted for best approximation.
The error rate given describes the accumulated timing error, NOT the unreliability of the line, and can be used to determine whether there is likely to be data errors in transmition due to timing issues.
To add a little background, the bits are sent and received in nominally identical time slices. The first edge of the start bit is used to synchronize the process, and, from then on, the receiver examines the line at the middle of each bits allotted time slice. For 8 bit data, with a start and a stop, the total time used is 9.5 bit times, and if the timing slips more than 0.5 bit times in that, then the receiver may lose synchronization on the later bits and the stop bit. This will trigger an error state if the receiver expects the bits faster than the sender provides them, and the bit the receiver sees as the stop isn't the appropriate stop state, and confusion will result from a number of possible ways for the synchronization to fail leading to bits being read as the wrong position in the data.
THis 0.5/9.5 ratio means that the maximum difference in bit rate , for reliable operation, is 5.5%. THis isn't bad, but does require a decent clock at both ends. If both clocks are off by 3% in different directions, then there will probably be loss of synchronization. This is the total difference, and, if one clock is very close, the other tan take substantially all of the error (this is not an unusual case, but is not always the case)
The clocks for the MSP430 that make sense here are, as you said, the DCO and a 32KHz crystal. The Crystal is accurate to about 0.01% worst case. The DCO is accurate to maybe 3% typical. On the other hand, as you noted, due to the need to produce the serial clock by dividing the control clock, at bit rates that are greater than about 5% of the clock rate, there will be bit rates that can not be generated to meet the requirement. For historical reasons, the standard bit rates don't play well with power-of-two frequencies like 32768Hz.
The situation is improved (and this is where the more favourable looking that expected error bound for the crystal comes from) by dithering the clock when you can't get an exact match: The basic rate is higher than needed, and some bits are stretched by a clock to minimize the accumulated error. This works well, but, if done at both ends of the line, can fail when the bitrate is about 1/5 of the clock rate (6Kbs with the 32KHz crystal). This is a rough number, not exact, since it depends on the details of how the bit time adjustment is done. If one end is dead stable, and an extra stop bit is thrown in, it works quite well up to maybe 1/3 of the clock rate (9600bps with a 32KHz crystal).
All of that said, I usually just use the factory calibrated DCO frequency and have no problem. I don't even bother with checking the exact frequency.
- Apr30, bluehash and roadrunner84
-
3
-
I have been through a number of generations of in house prototype and hobby scale small volume, and if I can avoid it, I don't do it myself. That said, I don't make a lot of boards anymore, so there is a large grain of salt involved when I say that, with a little care, prototyping on a mill can be viable. It is what I do most of the time these days, as I have the equipment. It isn't as fast as photo, or even toner transfer. There is a mess involved unless dust collection is dead on-- handling the fibreglass dust is a different league than chips and dust from pretty much any other material. What follows is off the top of my head and based on my (probably somewhat outdated) experience.
Positives include consistent trace width-- UV is also good, but requires good technique or results can get pretty bad--, no shorts or opens like plague toner transfer and sloppy UV, lower cost than UV if the equipment is already in house, the afore-mentioned alignment positives, no second setup for drilling, and no wet chem. Double sided isn't a big deal with proper use of alignment holes or fixtures, and other in house methods have similar issues.
Negatives are dust control, through hole plating (which is the same for most other in house methods), board properties, workholding issues, and leveling.
The key to good results is flat and level. A vacuum hold down on a flat bed it pretty much a dead requirement for good results, and accepting that the bed is going to need replacement periodically due to drill damage is a part of it.. If the bed is dead on, then the feature size can be quite good using a 90 degree point tool for the fine work-- depth controls width between close features. I run two tools for clearing: a 90 deg point for outlines and separation of close features (depth controls cut width), and a 0.75mm bullnose for larger area clearing and wide clearance, followed by a drill bit. If the board isn't held dead flat and level, the results will be bad, with nonuniform feature widths and variable substrate thickness between traces. I use a plugin for Eagle to generate the G-code.
I would say that the biggest drawback to milling prototypes involving high frequency devices is the change in substrate properties due to the substrate removal, both due to dielectric loss and due to increased moisture pickup. I have never had a major issue, since I have never milled when I anticipated an issue, but I have seen the effects in a few cases and needed to adjust component values to compensate. The key thing is that the prototype board may have characteristics very different from the production board.
That said, I don't recommend milling unless there is a compelling reason. For the few boards I do that way, it is ok, and 0.2mm traces on 0.5mm centers is very achievable. I prefer to use a service since I can usually wait. In a pinch, for something simple, I might even use a sharpie and etch, though that is last resort. I can do 0.5mm trace on 1.2 centerlines that way, which is fine for a lot of one-off, since I still use as much 0.1" (2.54mm) lead space devices as I can. I'm old and have poor eyesight. 10 sec with pliers and through hole devices are surface mount.
-
-
The 4017 is a decade counter IC. This means that it has a clock input and ten (actually 11) ouputs. At any point in time, one output is active. Each clock causes which output is active to advance. There are a few other pins, like a carry output that is active when outputs 0-4 are, and a reset input. It has been around for give or take 45 years, and is still useful, for anything from an LED chaser, waveform synthesis, to LED multiplexing circuits.
It would appear that the kit was not designed to push you in any single direction, so:
I might consider making a puzzle. You have several input devices available (photoresistor, push button, potentiometer, thermistor) and a number of output devices, and could likely come up with something interesting.
Other things, more straightforward,, might be a thermometer with 7seg display, A thermostat that is only active when it is dark (or light) , a Halloween prop, a signal control for a model railroad, .........
The hard part is when there are too many options (See _Zen_and_the_Art_of_Motorcycle_Maintenance_ by Pirsig for some interesting input on this).
-
I never noticed that board on adafruit. I may grab one just to play with, though I don't know if it will fit my final project-- I don't think there are enough triggers, though I may be able to reduce the number I need. The lack of ability for background sound may also be an issue, but I might be able to work with it. There are advantages to a packaged solution over the theoretical best solution.
-
Has anyone used the Novoton voice modules ("Chipcorder" ISD2360 for example) or similar devices? I am looking for suggestions for an upcoming project, and the price/performance of these looks reasonable, but I have no idea what other options are out there.
General outline: the relevant part of the the system will detect roughly a dozen events and play a short audio response to each, playing general background otherwise. Think of something like varied breathing sounds all of the time, with other sounds overlayed or replacing in response to inputs. Total audio is, give or take, 30 seconds, with about a dozen individual responses besides the background. The background sounds will be expanded to fill available device space if more is available, but 30 seconds is the minimum.
I am also looking at a WTV020SD type device, but, again, have not used one, and am not sure I am thrilled about the SD card in this system, and don't see that it has any way to layer multiple audio clips.
Input? Ideas?
-
-
Forgot to mention another possibility that I have used: nitrile mechanics gloves. Closing the wide (wrist) end can be done with silicone: I have clamped smoothly and tightly using aluminum bar about 5mmfrom the edge roll and run silicone into the exposed end without clamping. Leaves a decent seal. You could trim a finger end to run the wire through and seal that with a dab of silicone and a zip tie.
-
Basic guidelines would dictate that if it can't be hermetically sealed, then it needs to shed water and breath. If attitude can be guaranteed, then an open or screened/perforated bottom should do.
As a totally different thought, that I have not tried yet, a full hydrophobic coating might do the job, like one of the relatively new hydrophobic coatings for driveways/sidewalks.
Or, go old school. Tie the thing up in a condom. The urethane ones hold up well over time, better than the latex ones, and are a bit tougher. A dab of silicone on the sensor wire at the appropriate location before a zip tie around the opening. As long as it is not drum tight (some slack) and has little air in it, it shouldn't effect pressure readings. The Sensortag may be a little too big for this, but similar solutions can be worked out with other schema, like a silk/rayon bag coated with tent waterproofing spray, whatever that is called these days (I don't camp much anymore, so it has been a number of years since I had to use the stuff). Again, if there is a bit of slack, it shouldn't significantly affect pressure readings.
-
The info you provided is unclear and the numbers you give don't add up.
Do you need 10V peak-to-peak? 10V amplitude (20V peak-to-peak)? 10VRMS?
If 6.6Vp-p (+/-3.3v) is giving 80dB, then, as piezo devices are pretty linear for constant frequency, the output power will be pretty linear with voltage, whichever measurement is used. 6.6Vp-p square wave has a principal amplitude of (4/pi)*3.3V, and an RMS of about 3.0V. This is what is driving the resonance. If the device is spec'd at 10VRMS, then you should be getting 117dB+20log(3.0/10)=117-10.4dB=106.5dB (approximately 1/10 the power, which goes by the square of the voltage). If the device is spec'd peac amplitude square wave, sine amplitude, or p-p, you should be closer to the 117dB.
How did you measure the 80dB? Are you sure you are at resonance?
In general, due to the high Q value, driving one of these at resonance requires either careful tuning with a stable source, or a resonant driver, which is how the clock crystals are driven and commercial piezo alarms are driven. I would guess that you are driving off resonance (as the Q can be several hundred to several thousand, you need to be within a few cycles/sec) or you don't have a proper measurement of the actual output.
Also note that at 25KHz, you can do a LOT of damage to your ears, even though you can't hear it. Wear hearing protection if you are near the device when operating.
@@Roboticus a transformer would be fine here. If even remotely well made, it will reproduce the square wave well. In general, a sine wave if what you actually want, though. All power to drive the resonance. Power that doesn't do the work you want can lead to failure of the device, worst case. For a square wave, roughly 40% of the power is in the harmonics, 60% in the principal. Losing the harmonics is a benefit.
-
This code will not produce a neat order of 0, 1, 2, 3 .... It will be shuffled/randomized. The Go designers did this intentionally to break programmers' code when they try to rely on assumptions based on consistent undefined behaviors. As a result you are forced to convert those sorts of things into a list and sort them or whatever ... something better-defined anyhow.
Remember Pascal? Originally, no short circuit conditionals, among other things intended to force `good practice'. Most of these things were (incompatibly) rectified by various compiler designers. Even the UCSD line eventually gave switches for some of these things by the early 1980's. Java still does the same thing, in some ways (no overloading operators, for example, makes writing code to do non-triveal math a bit of a suck) Hmmm... I wonder if I still have a set of UCSD p-code floppys around?
-
Networked, a DALI setup can be used to control / monitor lighting in a very large building. Which is very useful. As far as bluetooth lights go . . . I have one, and this one is not all that great, but I can see how bluetooth, or wifi lights can be very useful.
I don't follow that end of the universe at this point. I have worked in facilities with good, though AFAIK wired, network lighting control.
The consumer technology seems to be predominantly gimmick. Historically, the early adopters drove technology, and by the time it made mass market, there was a reasonable level of reliability and utility achieved from the experience of the early adopters. I don't see that with most of the IoT devices, honestly including the lightbulbs. I see a few uses in the home, and in fact have wireless control (formerly X10, now RF keyfob hanging on the wall by the door) for lights in my basement, as I didn't want to run more wire for the switch. I do not trust a system that requires a smartphone to operate the lights in my house (lose or break the phone and SOL until replaced) via bluetooth (poor security)
-
The IOT thing has been around for long enough to become a cliche. As it stands now, in the consumer marketplace, it is a sales point for people that want the latest and greatest technology but have no clue how it works or what it is useful for. Roughly four years ago, I was shopping for a new refrigerator. The big store I went to had nothing that wasn't advertised as IOT (except dorm size), though only some of them were networkable. All of the networkable ones had features like temp setting through a web interface. All identified themselves readily with no security over the connection. A couple allowed Wifi connections direct to them (they acted as hubs if also connected to, say, a home network) 'for convenience'.
I don't need to know the details to know that a) these devices are a big ol' security hole,
there is no need for a network connection for a home 'fridge, and c) once it is set, I have never changed the temp setting on a fridge or freezer, and don't see the benefit to being able to via a web interface, and d) I want no part of a neighbor, or a neibor's annoying kid, being able to shut my fridge off when I go away for a couple days while there is food in it.I also don[t see the point of the same features (and basicly same interface and poor security) in a lightbulb. Or many other products. A toaster oven with wifi and web interface (they exist)? What on earth for?
This is related to, but different from, the cloud push.
There are things that can benefit from the 'cloud' storage (file server) and always connected models. In most cases, it is a gimmick or a way to rent-seek. Note where autodesk, for example, is going. Subscription and cloud storage, on their server, only. No net connection, no use. Saving backups locally is made awkward to impossible (awkward in autodesk's case). Drop the contract, and you no longer have access to your files. Since software doesn't wear out, it is a way to insure an income stream, and a better one, for the provider, than the last generation upgrade without downgrade path model that sold a new Autocad or Inventor license to most enterprise users every year (upgrade one machine, and all of the othrs in the organization can no longer work with projects touched on the upgraded machine), Given the market constraints and the need for the company to have an income stream if it is to remain solvent, I don't know how else they can do it, but that doesn't mean that I, as the little guy, like it or can afford it.
I'll shut up now. <Pshhhh> And have an adult bevvie.
Basic MSP430 GPIO Macros
in Code vault
Posted
Welcome to the preprocessor. I don't know of any more elegant solution as parameters are literal, though there may be one. The second level forces the parameter to be seen as a token itself and be substituted. The initial version did not let the token be seen on its own.
I learned the power, and limitations, or macro expansion with asmh on MVS, writing a 12 liner to expand to the twelve days of xmas for a class. The C/C++ preprocessor is more capable, but is still not doing full featured regeps.