I am using two msp430f5529 with booster pack(trf7970a),I'm making one module to work in special direct mode(as per sloa214,SDM is used to transmit data) and another one module to work in Direct Mode1(DM1) to receive transmitted data from module one. But I'm not able to receive any data.
Below is my tx code.
Mifare_SDM_config();
Mifare_SDM_Enter();
Mifare_SDM_Transmit((unsigned int*)tx_buff,10,1); //here 1 is parity bit
Mifare_SDM_Exit();
and my receiver code.
//Entering DM1 Mifare_DM1_Enter();
Mifare_DM1_Recieve(rx_buff,rx_len,1);//here 1 is parity bit
Mifare_DM1_Exit();
am I missing anything?
I am trying to instantiate a state machine at top level module and connect the states at top level ports to probe them as part of debug. I am trying something like this as in example below:
.state[0](DEBUG_1),
.state[1](DEBUG_2),
DEBUG_1 and DEBUG_2 are output ports in the top level module, and I want to probe these signals at the top logic.
The above is not working in SystemVerilog and gives errors. How else can this be done?
package states;
typedef enum logic [2:0] {RE = 3'b000,
NOR = 3'b001,
WD = 3'b011,
TO = 3'b010,
EVL = 3'b110,
DEC = 3'b111} state_t;
endpackage
import states::*;
module fsm (
input clk,
input reset,
output state_t state
);
import rtl_pkg::*;
import states::*;
module top (
output logic DEBUG_1,
output logic DEBUG_2
);
fsm fsm_inst (
.clk(sys_clk),
.reset(sys_reset),
.state[0](DEBUG_1),
.state[1](DEBUG_2),
.state[2](DEBUG_3),
);
ERROR - (VERI-1137) syntax error near '['
ERROR - module top ignored due to previous errors
Here is one way to get rid of the compile errors:
module top (
output logic DEBUG_1,
output logic DEBUG_2, DEBUG_3
);
// ... signal declarations
fsm fsm_inst (
.clk (sys_clk),
.reset (sys_reset),
.state ({DEBUG_3, DEBUG_2, DEBUG_1})
);
endmodule
Concatenate the 3 DEBUG bits using {}, then connect it directly to the state port.
Please have a look at the following code
Formula.ads
package Formula is
procedure CalculateFormula;
end Formula;
Formula.adb
with Ada.Text_IO; use Ada.Text_IO;
with Formula; use Formula;
package body Formula is
procedure CalculateFormula is
package fom_io is new Ada.Float_Text_IO(Float);
use fom_io;
u : Float;
t : Float;
a : Float;
answer : Float;
begin
put_line("Enter 'U'");
get(u);
put_line("Enter 'T'");
get(t);
put_line("Enter 'A'");
get(a);
answer = (u*t)+ 0.5(a(t*t));
put("Answer is: ");
put(answer,Fore => 1,Aft => 1,Exp => 1);
end CalclualeFormula;
end Formula;
When I run this code, I get the following error
gnatmake -d -PC:\Users\yohan\Documents\Ada\Formula\formula.gpr
gcc -c -I- -gnatA C:\Users\yohan\Documents\Ada\Formula\formula.ads
cannot generate code for file formula.ads (package spec)
gnatmake: "C:\Users\yohan\Documents\Ada\Formula\formula.ads" compilation error
[2013-04-06 03:18:22] process exited with status 4 (elapsed time: 00.22s)
I am very new to Ada. Started coding few hours back. Please help me to get rid of the above issue. Thank you.
EDIT
formula.gpr
project Formula is
for Main use ("formula.ads");
end Formula;
The GPR file shows that you are trying to use a package specification as a main program unit - that doesn't work.
Two ways to fix this: The simplest one is to make "CalculateFormula" a standalone main program in a file "calculateformula.adb" and set this in your project file:
for Main use ("calculateformula.adb");
But if you want to see how packages work, there is a "better" way (in that it gets you to understand what packages are for and how they are used...)
Packages are reusable components : the package spec is all you need to see in order to use them ... but you actually use them in another program. So in this case you would create a main program
with Formula; use Formula;
procedure MyMain is
begin
CalculateFormula;
end MyMain;
and in the .gpr file,
for Main use ("mymain.adb");
And then the compiler will automatically compile the correct packages and find the other issues that Shark has pointed out.
You really don't need a separate Main here, as the "hello world" example showed. However such trivial "main subprograms" (in the correct Ada lingo) are not so unusual, especially for purposes like unit testing packages to be used in more complex apps later.
This is puzzling because there are some big errors that the compiler should be flagging, like:
package fom_io is new Ada.Float_Text_IO(Float);
which isn't withed, and
answer = (u*t)+ 0.5(a(t*t));
because:
= is not the assignment operator; you need :=.
0.5(XXXX) isn't valid multiplication.
Also, there's exponentiation in Ada, so t**2 can replace t*t.
formula.adb
with
Ada.Float_Text_IO,
Ada.Text_IO;
use
Ada.Text_IO;
package body Formula is
procedure CalculateFormula is
use Ada.Float_Text_IO;
u, t, a, answer : Float;
Procedure Prompt( Item : out Float; Name : String ) is
begin
put_line("Enter '"& Name &"'");
get(Item);
end prompt;
begin
prompt( u, "U" );
prompt( t, "T" );
prompt( a, "A" );
answer:= (u*t) + 0.5*( a*t**2 );
put("Answer is: ");
put(answer,Fore => 1,Aft => 1,Exp => 1);
New_Line;
end CalculateFormula;
end Formula;
This corrects the syntax errors you had. The other answer seems right in that this ["cannot generate code for" error] seems to be a problem with the gpr-file rather than the source itself.
I’ve got a MCF5282 that I’m trying to use PDD4 as a GPIO on. In my setup code, I’ve got:
MCF5282_GPIO_DDRDD = 0x10; /* cs on dd4. */
MCF5282_GPIO_PORTDD = 0x10; /* active-low. */
And in my main loop, I’ve got:
MCF5282_GPIO_PORTDD = (mainloop_cnt & 0x10);
Which should give me a nice square wave on the oscilloscope, but the port doesn’t seem to be doing as I say. Am I missing some setup steps? I can’t find anything in the 5282 manual about a “Port DD pin-assignment register” to repurpose it from its “primary” role as DDATA.
Edit 2011-03-01: We never figured this out, we just used a different pin for GPIO.
You probably need to clear PSTEN in the Chip Configuration Register to disable DDATA, see page 27-4 of the MCF5282 and MCF5216 ColdFire Microcontroller User’s Manual
Whenever I create a large Mathematica project I run into this problem: Preventing avalanche of runtime errors in Mathematica, i.e., Mathematica's error message are opaque, archaic, and legion.
The idea then is to disable all of Mathematica's own error messages and implement type checking and error messages of your own in every Function and Module. However I have not found a simple and efficient way of doing this and end up with, e.g., some function generating an error 20 function calls deep and then get a whole cascade of error messages all the way back up to the main routine.
How would you set up a simple mechanism for this that only generates one error message at the function that experiences the error and a simple list of the chain of function calls?
EDIT: Since it has come up in a couple of answers; I am specifically looking for something lightweight regarding the output it produces (otherwise I could just stick with Mathematica's error messages) and obviously also lightweight in computational overhead. So while Stack and Trace are definitely light on the overhead, their output in complex projects is not quick to parse and some work needs to be done simplifying it.
YAsI - Yet Another (silly?) Idea ...
Re-reading your question ...
The idea then is to disable all of Mathematica's own error messages and implement type checking and error messages of your own in every Function and Module.
Found this:
$MessagePrePrint = ( #; Print[Stack[_][[;; -5]]]; Abort[]) &
v[x_, y_] := w[x, y];
w[x_, y_] := x/y;
StackComplete#v[1, 0];
During evaluation of In[267]:= {StackComplete[v[1,0]];,
StackComplete[v[1,0]], v[1,0], w[1,0], 1/0, 1/0, Message[Power::infy,1/0]}
Out[267]= $Aborted
conclusion ... Aborts at first message and leaves a "reasonable" stack trace. "Reasonable" means "Should be improved".
But it is completely non-intrusive!
To get the ball rolling here is one idea that I've been toying with; the creation of a pseudo stack.
First make a global variable theStack={} and then in every Function or Module start with AppendTo[theStack,"thisFuncName"] and end with theStack=Most#theStack. Assuming moderate (~a few tens) depth of function calls, this should not add any significant overhead.
Then implement your own typing/error checking and use Print#theStack;Abort[]; on errors.
Refinements of this method could include:
Figuring out a way to dynamically get "thisFuncionName" so that the AppendTo[] can be made into an identical function call for all Functions and Module.
Using Message[] Instead of Print[].
Pushing other important variables / stateful information on theStack.
One attempt to implement #Timo's idea (theStack)
Incomplete and perhaps flawed, but just to keep thinking about it:
Clear["Global`*"];
funcDef = t_[args___] \[CircleMinus] a_ :>
{t["nude", args] := a,
ReleaseHold[Hold[t[args] :=
(If[! ValueQ[theStack], theStack = {}];
AppendTo[theStack, ToString[t]];
Check[ss = a, Print[{"-TheStack->", Evaluate#theStack}];
Print#Hold[a]; Abort[]];
theStack = Most#theStack;
Return[ss])
]]};
v[x_, y_]\[CircleMinus] (Sin# g[x, y]) /. funcDef;
g[x_, y_]\[CircleMinus] x/y /. funcDef;
v[2, 3]
v[2, 0]
Output:
Out[299]= Sin[2/3]
During evaluation of In[295]:= Power::infy: Infinite expression 1/0 encountered. >>
During evaluation of In[295]:= {-TheStack->,{v,g}}
During evaluation of In[295]:= Hold[2/0]
Out[300]= $Aborted
A suggestion for extracting stack, maybe something that relies on Trace?
An example of using Trace below, from Chris Chiasson. This code saves evaluation tree of 1 + Sin[x + y] + Tan[x + y] into ~/temp/msgStream.m
Developer`ClearCache[];
SetAttributes[recordSteps, HoldAll];
recordSteps[expr_] :=
Block[{$Output = List#OpenWrite["~/temp/msgStream.m"]},
TracePrint[Unevaluated[expr], _?(FreeQ[#, Off] &),
TraceInternal -> True];
Close /# $Output;
Thread[
Union#Cases[
ReadList["~/temp/msgStream.m", HoldComplete[Expression]],
symb_Symbol /;
AtomQ#Unevaluated#symb &&
Context#Unevaluated#symb === "System`" :>
HoldComplete#symb, {0, Infinity}, Heads -> True],
HoldComplete]
];
recordSteps[1 + Tan[x + y] + Sin[x + y]]
To answer Samsdram's question, the code below (also from Chris) gives evaluation tree of a Mathematica expression. Here is the post from MathGroup with source code and examples.
(Attributes## = {HoldAllComplete}) & /# {traceToTreeAux, toVertex,
HoldFormComplete, getAtoms, getAtomsAux}
MakeBoxes[HoldFormComplete[args___], form_] :=
MakeBoxes[HoldForm[args], form]
edge[{head1_, pos1_, xpr1_}, {head2_, pos2_, xpr2_}] :=
Quiet[Rule[{head1, vertexNumberFunction#pos1, xpr1}, {head2,
vertexNumberFunction#pos2, xpr2}], {Rule::"rhs"}]
getAtomsAux[atom_ /; AtomQ#Unevaluated#atom] :=
Sow[HoldFormComplete#atom, getAtomsAux]
getAtomsAux[xpr_] := Map[getAtomsAux, Unevaluated#xpr, Heads -> True]
getAtoms[xpr_] := Flatten#Reap[getAtomsAux#xpr][[2]]
toVertex[traceToTreeAux[HoldForm[heldXpr_], pos_]] := toVertex[heldXpr]
toVertex[traceToTreeAux[HoldForm[heldXprs___], pos_]] :=
toVertex#traceToTreeAux[Sequence[], pos]
(*this code is strong enough to not need the ToString commands,but \
some of the resulting graph vertices give trouble to the graphing \
routines*)
toVertex[
traceToTreeAux[xpr_, pos_]] := {ToString[
Short#Extract[Unevaluated#xpr, 0, HoldFormComplete], StandardForm],
pos, ToString[Short#First#originalTraceExtract#{pos}, StandardForm]}
traceToTreeAux[xpr_ /; AtomQ#Unevaluated#xpr, ___] := Sequence[]
traceToTreeAux[_HoldForm, ___] := Sequence[]
traceToTreeAux[xpr_, pos_] :=
With[{lhs = toVertex#traceToTreeAux[xpr, pos],
args = HoldComplete ## Unevaluated#xpr},
Identity[Sequence][
ReleaseHold[
Function[Null, edge[lhs, toVertex##], HoldAllComplete] /# args],
ReleaseHold#args]]
traceToTree[xpr_] :=
Block[{vertexNumber = -1, vertexNumberFunction,
originalTraceExtract},
vertexNumberFunction[arg_] :=
vertexNumberFunction[arg] = ++vertexNumber;
originalTraceExtract[pos_] :=
Extract[Unevaluated#xpr, pos, HoldFormComplete]; {MapIndexed[
traceToTreeAux, Unevaluated#xpr, {0, Infinity}]}]
TraceTreeFormPlot[trace_, opts___] :=
Block[{$traceExpressionToTree = True},
Through#{Unprotect, Update}#SparseArray`ExpressionToTree;
SparseArray`ExpressionToTree[trace, Infinity] = traceToTree#trace;
With[{result = ToExpression#ToBoxes#TreeForm[trace, opts]},
Through#{Unprotect, Update}#SparseArray`ExpressionToTree;
SparseArray`ExpressionToTree[trace, Infinity] =.;
Through#{Update, Protect, Update}#SparseArray`ExpressionToTree;
result]];
TraceTreeFormPlot[Trace[Tan[x] + Sin[x] - 2*3 - 55]]
Perhaps we have been over thinking this. What if we just tweaked the pattern matching on the arguments a little. For instance, if we modified the function to check for a numeric quantity and added some code to print an error if it fails. For instance,
TypeNumeric[x_] := If[! NumericQ[Evaluate[x]],
Print["error at "]; Print[Stack[]]; Print["Expression "]; Print[x]; Print["Did
not return a numeric value"];Return[False],
(*Else*)
Return[True];]
SetAttributes[TypeNumeric, HoldAll];
Step 2: If you have a function, f[x_] that requires a numeric quantity, just write it with the standard pattern test and all should be well
Input:
f[x_?TypeNumeric] := Sqrt[x]
f[Log[y]]
f[Log[5]]
Output:
error at
{f}
Expression
Log[y]
Did not return a numeric value
f[Log[y]]
Sqrt[Log[5]]
I believe this will work and, it makes robust type checking as simple as a writing a function or two. The problem is that this could be hugely inefficient because this code evaluates the expression x twice, once for the type checking and once for real. This could be bad if an expensive function call is involved.
I haven't figured out the way around this second problem and would welcome suggestions on that front. Are continuations the way out of this problem?
Hope this helps.