Can anyone help me understand this snippet? Is it even C?
lcd_bl: backlight {
compatible = "pwm";
level = <8>;
};
Specifically:
What is lcd_bl?
I am assuming that lcd_bl is a label, but there is no goto lcd_bl. lcd_bl is referenced in this snippet which is in the same file as the one above
lcd0: display {
back = <&lcd_bl>;
};
What data structure is backlight?
Why are <> used when assigning a number to a variable?
What is happening in the second snippet?
Any help on this would be appreciated.
Yes, this code is C programming language. It's used for the development of the board AM437x. more info about the board
take a look at am4372.dtsi,dt-bindings/pinctrl/am43x and pwm C libraries to understand this code if you are a senior C developer otherwise forget about it it's not novice level.
Related
I'm having trouble getting my .hdl files to loads in the HardwareSimulator. So far I have implemented FullAdder.hdl and Add16.hdl.
The error message I'm recieving is
line 22, zab has no source pin
Here is the relevant code for the Add16:
CHIP Add16 {
IN x[16], y[16];
OUT out[16];
PARTS:
HalfAdder(x=x[0],y=y[0],sum=out[0],carry=c);
FullAdder(x=x[1],y=y[1],c=c,sum=out[1],carry=d);
FullAdder(x=x[2],y=y[2],c=d,sum=out[2],carry=e);
FullAdder(x=x[3],y=y[3],c=e,sum=out[3],carry=f);
FullAdder(x=x[4],y=y[4],c=f,sum=out[4],carry=g);
FullAdder(x=x[5],y=y[5],c=g,sum=out[5],carry=h);
FullAdder(x=x[6],y=y[6],c=h,sum=out[6],carry=i);
FullAdder(x=x[7],y=y[7],c=i,sum=out[7],carry=j);
FullAdder(x=x[8],y=y[8],c=j,sum=out[8],carry=k);
FullAdder(x=x[9],y=y[9],c=k,sum=out[9],carry=l);
FullAdder(x=x[10],y=y[10],c=l,sum=out[10],carry=m);
FullAdder(x=x[11],y=y[11],c=m,sum=out[11],carry=n);
FullAdder(x=x[12],y=y[12],c=n,sum=out[12],carry=o);
FullAdder(x=x[13],y=y[13],c=o,sum=out[13],carry=p);
FullAdder(x=x[14],y=y[14],c=p,sum=out[14],carry=q);
FullAdder(x=x[15],y=y[15],c=q,sum=out[15],carry=drop);
}
I'm strugginling to find the error since I'm pretty sure I've implemented this chip in exactly the same way in the past and it worked fine.
As for the full adder, it's the same error message but for line 16.
I'll provide the relevant code for this part also:
CHIP FullAdder {
IN x, y, z; // 1-bit inputs
OUT sum, // Right bit of x + y + z
carry; // Left bit of x + y + z
PARTS:
HalfAdder(x=x,y=y,sum=xy,carry=zxy);
HalfAdder(x=z,y=xy,sum=sum,carry=s);
Or(x=zab,y=s,out=carry);
}
I can't wrap my mind around the error referring to line 16. That's way after the terminating bracket in FullAdder.
I've browsed the internet and as far as I can tell my implementation is perfectly correct. Any advice from anyone who are proficient in the Computer Processors area? This would definitely be useful for anyone else who are running into the same/similar problems.
Thanks
edit: According to this link Logic Gates my implementation looks more or less exactly the same. Could it be a faulty HardwareSim at my end? Although I doubt that since I've used it in the past and it was recommended to me by my University.
The problem is in the x input to your Or gate in the FullAdder. You are referring to a signal (pin) "zab" but no such signal is defined.
In future, please remember to post the entire files. It is hard to help you diagnose an error in line 16 when it is difficult to tell what line that actually is.
I'm trying to refactor a small amount of legacy non-functional-totally-procedural-old-school-"is this FORTRAN?!" code, and I'd like some input.
Since Swift 3 is getting rid of the "confusing" ++ prefix/postfix operator, along with C-style for loops, I've been hard at work updating my gross Swift 2.0 (and really gross C and Objective-C) files, and for the most part, it hasn't been too bad. However, I've run into one of those pesky do...while loops that I probably wrote after a night of heavy drinking.
Here's a slimmed down version of the original code:
BSDPath *startPath = &ctx->paths[startIdx];
BSDPath *endPath = &ctx->paths[endIdx];
BSDPath *currentPath = startPath;
do {
if (flags & CurveElement) {
// ... Some code here ...
}
} while (currentPath++ != endPath);
I've Swiftified some stuff, and now I'm here:
let startPath = ctx.paths[index]
let endPath = ctx.paths[endIndex]
var currentPath = startPath
repeat {
if flags.contains(.Curve) {
// ... Some code here ...
}
index += 1
currentPath = ctx.paths[index]
} while currentPath != endPath
As you can C, I've Swiftly converted most of it to the new nice and clean Apple of my eye. However, I can't help but wonder if there's an even cleaner way of writing this — that is, without totally throwing out the bath water and giving in to the for...in siren song. To be honest, I'm not even sure if that code runs correctly. I've never really been able to wrap my head around the control flow of the do...while statement. I mean, I get how it works, but it just seems backwards to me. But I digress.
I suppose the reason I want to know the "cleanest" way to rewrite my old stuff is that I just kind of miss being able wrap assignment statements in parentheses to kill two bytes with one var. I totally agree that the ++ operator is counterintuitive, but for all it's jankiness, it certainly did take a little of the tedium out of typing into a code editor all day. But I digress (again?!).
Anyway, that's all I've got. I would love to know of any timesavers I'm unaware of, but any thoughts, ideas, or comments are welcome and greatly appreciated. Thanks!
Is there a way in VBA to create classes and/or methods that have a limited list of acceptable constants to use as arguments or in assignment statements?
These exist already in VBA per the images below:
I would like to incorporate this in my classes.
It's not a limited set of constants. You type xlsheethidden the program sees 0. The compiler puts 0 into the program. Nothing stops you doing this. ReportCS1.Visible = 1,000,000. It's an aid to writing programs, it doesn't form part of the finished program.
If you want to limit what can be passed then you'll need to write code checking what was passed, if wrong do err.raise(&h80070000 OR 13, blah,blah, blah).
This turns a WinError into a HResult - 13 seems resonable. = 0x8007000d
//
// MessageId: ERROR_INVALID_DATA
//
// MessageText:
//
// The data is invalid.
//
#define ERROR_INVALID_DATA 13L
Tim Williams answered my question in his comment. Thanks Tim!
You can create an Enum See: cpearson.com/excel/Enums.aspx
Stupid question that I'm sure is some bit of syntax that's not right. How do I get dlsym to work with a function that returns a value? I'm getting the error 'invalid conversion of void* to LSError (*)()' in the following code - trying to get the compile the linux lightscribe sample program hoping that I can link it against the OSX dylib (why the hell won't HP release an actual Cocoa SDK? LS has only been around for what? 6 or 7 years now?):
void* LSHandle = dlopen("liblightscribe.1.dylib", RTLD_LOCAL|RTLD_LAZY);
if (LSHandle) {
LSError (*LS_DiscPrinter_ReleaseExclusiveUse)() = dlsym(LSHandle, "LS_DiscPrinter_ReleaseExclusiveUse");
..
lsError = LS_DiscPrinter_ReleaseExclusiveUse( pDiscPrinter);
The C standard does not actually define behaviour for converting to and from function pointers. Explanations vary as to why; the most common being that not all architectures implement function pointers as simple pointers to data. On some architectures, functions may reside in an entirely different segment of memory that is unaddressable using a pointer to void.
The “recommended” way to use dlsym is:
LSError (*LS_DiscPrinter_ReleaseExclusiveUse)(LS_DiscPrinterHandle);
*(void **)&LS_DiscPrinter_ReleaseExclusiveUse = dlsym("LS_DiscPrinter_ReleaseExclusiveUse");
Read the rationale and example on the POSIX page for dlsym for more information.
Ok I finally found the problem. It was inside the C function(CarbonTuner2) not the objC method. I was creating inside the function an array of the same size as the file size so if the filesize was big it created a really big array and my guess is that when I called another function from there, the local variables were put on the stack which created the EXC_BAD_ACCESS. What I did then is instead of using a variable to declare to size of the array I put the number directly. Then the code didnt even compile. it knew. The error wassomething like: Array size too big. I guess working 20+hours in a row isnt good XD But I am definitly gonna look into tools other than step by step debuggin to figure these ones out. Thanks for your help. Here is the code. If you divide gFileByteCount by 2 you dont get the error anymore:
// ConverterController.h
# import <Cocoa/Cocoa.h>
# import "Converter.h"
#interface ConverterController : NSObject {
UInt64 gFileByteCount ;
}
-(IBAction)ProcessFile:(id)sender;
void CarbonTuner2(long numSampsToProcess, long fftFrameSize, long osamp);
#end
// ConverterController.m
# include "ConverterController.h"
#implementation ConverterController
-(IBAction)ProcessFile:(id)sender{
UInt32 packets = gTotalPacketCount;//alloc a buffer of memory to hold the data read from disk.
gFileByteCount=250000;
long LENGTH=(long)gFileByteCount;
CarbonTuner2(LENGTH,(long)8192/2, (long)4*2);
}
#end
void CarbonTuner2(long numSampsToProcess, long fftFrameSize, long osamp)
{
long numFrames = numSampsToProcess / fftFrameSize * osamp;
float g2DFFTworksp[numFrames+2][2 * fftFrameSize];
double hello=sin(2.345);
}
Your crash has nothing to do with incompatibilities between C and ObjC.
And as previous posters said, you don't need to include math.h.
Run your code under gdb, and see where the crash happens by using backtrace.
Are you sure you're not sending bad arguments to the math functions?
E.g. this causes BAD_ACCESS:
double t = cos(*(double *)NULL);
Objective C is built directly on C, and the C underpinnings can and do work.
For an example of using math.h and parts of standard library from within an Objective C module, see:
http://en.wikibooks.org/wiki/Objective-C_Programming/syntax
There are other examples around.
Some care is needed around passing the variables around; use the C variables for the C and standard library calls; don't mix the C data types and Objective C data types incautiously. You'll usually want a conversion here.
If that is not the case, then please consider posting the code involved, and the error(s) you are receiving.
And with all respect due to Mr Hellman's response, I've hit errors when I don't have the header files included; I prefer to include the headers. But then, I tend to dial the compiler diagnostics up a couple of notches, too.
For what it's worth, I don't include math.h in my Cocoa app but have no problem using math functions (in C).
For example, I use atan() and don't get compiler errors, or run time errors.
Can you try this without including math.h at all?
First, you should add your code to your question, rather than posting it as an answer, so people can see what you're asking about. Second, you've got all sorts of weird problems with your memory management here - gFileByteCount is used to size a bunch of buffers, but it's set to zero, and doesn't appear to get re-set anywhere.
err = AudioFileReadPackets (fileID,
false, &bytesReturned, NULL,0,
&packets,(Byte *)rawAudio);
So, at this point, you pass a zero-sized buffer to AudioFileReadPackets, which prompty overruns the heap, corrupting the value of who knows what other variables...
fRawAudio =
malloc(gFileByteCount/(BITS/8)*sizeof(fRawAudio));
Here's another, minor error - you want sizeof(*fRawAudio) here, since you're trying to allocate an array of floats, not an array of float pointers. Fortunately, those entities are the same size, so it doesn't matter.
You should probably start with some example code that you know works (SpeakHere?), and modify it. I suspect there are other similar problems in the code yoou posted, but I don't have time to find them right now. At least get the rawAudio buffer appropriately-sized and use the values returned from AudioFileReadPackets appropriately.