I have an problem, when i enconde the imagem with 16 bit depth i obtain one error, the error is:
"enable RExt__HIGH_BIT_DEPTH_SUPPORT";
I use the InternalBitDepth = 16 , i need use this.
I read what i need changed in TypeDef.h the next line :
#ifndef RExt__HIGH_BIT_DEPTH_SUPPORT
#define RExt__HIGH_BIT_DEPTH_SUPPORT 0 ///< 0 (default) use data type definitions for 8-10 bit video, 1 = use larger data types to allow for up to 16 bit video
I change to #define RExt__HIGH_BIT_DEPTH_SUPPORT 1 ///, and i run the makefile, but the error remained.
Whats happen?
thank you in advance
Are you sure that HM supports the bit depth of 16?
I am not sure about my claim; but I think every time I hear from someone about "higher bit depth in HM", they usually talk about 10 or at most 12 bit depth.
As I said, I am not sure at all. Maybe it supports!
If you'll find the answer, please share it with us.
Good luck
Go to the main directory.
Open CMakeList.txt.
Find the line setting HIGH_BITDEPTH.
Change OFF to ON to enable HIGH_BITDEPTH.
In the building directory, delete CMakeCache.txt.
cmake again to rebuild to project.
Fix the warnings of shifting 32bit integers (change 1 << into 1ll <<).
Done.
Related
I'm developing an I2C driver on the STM32F74 family processors. I'm using the STM32CubeMX Low Level drivers and I can't make sense of the generated defines for I2C start and stop register values (CR2).
The code is generated in stm32f7xx_ll_i2c.h and is as follows.
/** #defgroup I2C_LL_EC_GENERATE Start And Stop Generation
* #{
*/
#define LL_I2C_GENERATE_NOSTARTSTOP 0x00000000U
/*!< Don't Generate Stop and Start condition. */
#define LL_I2C_GENERATE_STOP (uint32_t)(0x80000000U | I2C_CR2_STOP)
/*!< Generate Stop condition (Size should be set to 0). */
#define LL_I2C_GENERATE_START_READ (uint32_t)(0x80000000U | I2C_CR2_START | I2C_CR2_RD_WRN)
/*!< Generate Start for read request. */
My question is why is bit 31 included in these defines? (0x80000000U). The reference manual (RM0385) states "Bits 31:27 Reserved, must be kept at reset value.". I can't decide between modifying the generated code or keeping the 31 bit. I'll happily take recommendations simply whether its more likely that this is something needed or that I'm going to break things by writing to a reserved bit.
Thanks in advance!
I am guessing here because who knows what was on the minds of the library authors? (Not a lot if you look at the source code!). But I would guess that it is a "dirty-trick" to check that when calling LL functions you are using the specified macros.
However it is severely flawed because the "trick" is only valid for Cortex-M3/4 STM32 variants (e.g. F1xx, F2xx, F4xx) where the I2C peripheral is very different and registers such as I2C_CR2 are only 15 bits wide.
The trick is that the library functions have parameter checking asserts such as:
assert_param(IS_TRANSFER_REQUEST(Request));
Where the IS_TRANSFER_REQUEST is defined thus:
#define IS_TRANSFER_REQUEST(REQUEST) (((REQUEST) == I2C_GENERATE_STOP) || \
((REQUEST) == I2C_GENERATE_START_READ) || \
((REQUEST) == I2C_GENERATE_START_WRITE) || \
((REQUEST) == I2C_NO_STARTSTOP))
This forces you to use the LL defined macros as parameters and not some self-defined or calculated mask because they all have that "unused" check bit in them.
If that truly is the the reason, it is an ill-advised practice that did not envisage the newer I2C peripheral. You might think that the bit was stripped from the parameter before being written to the register. I have checked, it is not. And if did you would be paying for that overhead on every call, which is also undesirable.
As an error detection technique if that is what it is, it is not even applied consistently; for example all the GPIO_PIN_xx macros are 16 bits wide and since they are masks not pin numbers, using bit 31 could for example guard against passing a literal pin-number 10 where the mask 1<<10 is in fact required. Passing 10 would refer to pins 3 and 1 not 10. And to be honest that mistake is far more likely than, passing an incorrect I2C transfer request type.
In the end however "Reserved" generally means "unused but may be used in future implementations", and requiring you to use the "reset value" is a way of ensuring forward binary compatibility. If you had such a device no doubt there would be a corresponding library update to support it - but it would require re-compilation of the code. The risk is low and probably only a problem if you attempt to run this binary on a newer incompatible part that used this bits.
I agree with Clifford, the ST CubeMC / HAL / LL library code is, in places, some of the worst written code imaginable. I have a particular issue with lines such as "TIMx->CCER &= ~TIM_CCER_CC1E" where TIM_CCER_CC1e is defined as 0x0001 and the CCER register contains reserved bits that should remain at 0. There are hundreds of such examples all throughout the library code. ST remain silent to my request for advice.
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 have the following code snippet:
#include "contiki.h"
#include <stdio.h> /* For printf() */
PROCESS(calc_process, "calc process");
AUTOSTART_PROCESSES(&calc_process);
PROCESS_THREAD(calc_process, ev, data)
{
double dec=13.2, res=0, div=3.2;
PROCESS_BEGIN();
res=dec+div;
printf("%f",res);
PROCESS_END();
}
After uploading the above code in Tmote sky platform using the command
make TARGET=sky calc.upload, the program will be loaded to the mote (there is no error). Then login to the mote using make login TARGET=sky, the following output is displayed....
OUPUT:
**Rime started with address 4.0
MAC 04:00:00:00:00:00:00:00 Contiki 2.7 started. Node id is set to 4.
CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26
Starting 'calc process'
%f**
How can I get the correct value?
Thanks
It is not floating point calculation support that you need - you have that already. What is missing is floating point support within printf(). That is to say that res will be calculated correctly, but printf() does not support its display.
Because it requires a relatively large amount of code, many microcontroller targeted libraries omit floating point support in stdio. There may be a library build option to include floating point support - refer to the library documentation.
You might do well to ask a question about the specific calculation necessary, and how it might be done using integer or fixed point arithmetic. Alternatively you might write your own floating point display as described here: How to print floating point value using putchar? for example.
I am doing a firmware upgrade using SPI bus on EEPROM as well as Internal ROM of 8051, basically writing a .hex file on both these memory devices.I am able to see .hex file written there.I am able to see slave and master are communicating properly, but not able to write anything on my memory devices.
If you have suggestions and if you have faced similar problems, please let me know where is the actual problem.
Any inputs would be welcomed.
Regards,
Ravi
I think more information will likely be required. In any case, here a few pitfalls I could see:
Hex Files are not necessarily memory images. The 8051s I've worked with usually use Intel Hex which is an ASCII format that describes the memory. The format is well documented here.
If you're having trouble writing to the EEPROM, you may not be writing the proper instructions. Typically, SPI EEPROM will be Byte addressed, but still has paging internally. You should start your writes on a Page boundary and write the whole page, then issue another write command, etc. By convention if you overrun a page, or start in the middle of a page it will loop around. So if your page is 8 bytes long, and you start writing 0-7 starting at index 4, you'll get:
Page Start: Index 0 = 4
Index 1 = 5
Index 2 = 6
Index 3 = 7
Index 4 = 0
Index 5 = 1
Index 6 = 2
Index 7 = 3
Most EEPROMs have locking mechanisms to prevent accidental writes once they are finalized. If the lock has been set, you will need to write an unlocking method (this will be detailed in the data sheet if it has it)
To further help you, please reference part numbers and better yet Data Sheets if you can.
Since many of the Project Euler problems require you to do a divisibility check for quite a number of times, I've been trying to figure out the fastest way to perform this task in ZX81 BASIC.
So far I've compared (N/D) to INT(N/D) to check, whether N is dividable by D or not.
I have been thinking about doing the test in Z80 machine code, I haven't yet figured out how to use the variables in the BASIC in the machine code.
How can it be achieved?
You can do this very fast in machine code by subtracting repeatedly. Basically you have a procedure like:
set accumulator to N
subtract D
if carry flag is set then it is not divisible
if zero flag is set then it is divisible
otherwise repeat subtraction until one of the above occurs
The 8 bit version would be something like:
DIVISIBLE_TEST:
LD B,10
LD A,100
DIVISIBLE_TEST_LOOP:
SUB B
JR C, $END_DIVISIBLE_TEST
JR Z, $END_DIVISIBLE_TEST
JR $DIVISIBLE_TEST_LOOP
END_DIVISIBLE_TEST:
LD B,A
LD C,0
RET
Now, you can call from basic using USR. What USR returns is whatever's in the BC register pair, so you would probably want to do something like:
REM poke the memory addresses with the operands to load the registers
POKE X+1, D
POKE X+3, N
LET r = USR X
IF r = 0 THEN GOTO isdivisible
IF r <> 0 THEN GOTO isnotdivisible
This is an introduction I wrote to Z80 which should help you figure this out. This will explain the flags if you're not familiar with them.
There's a load more links to good Z80 stuff from the main site although it is Spectrum rather than ZX81 focused.
A 16 bit version would be quite similar but using register pair operations. If you need to go beyond 16 bits it would get a bit more convoluted.
How you load this is up to you - but the traditional method is using DATA statements and POKEs. You may prefer to have an assembler figure out the machine code for you though!
Your existing solution may be good enough. Only replace it with something faster if you find it to be a bottleneck in profiling.
(Said with a straight face, of course.)
And anyway, on the ZX81 you can just switch to FAST mode.
Don't know if RANDOMIZE USR is available in ZX81 but I think it can be used to call routines in assembly. To pass arguments you might need to use POKE to set some fixed memory locations before executing RANDOMIZE USR.
I remember to find a list of routines implemented in the ROM to support the ZX Basic. I'm sure there are a few to perform floating operation.
An alternative to floating point is to use fixed point math. It's a lot faster in these kind of situations where there is no math coprocessor.
You also might find more information in Sinclair User issues. They published some articles related to programming in the ZX Spectrum
You should place the values in some pre-known memory locations, first. Then use the same locations from within Z80 assembler. There is no parameter passing between the two.
This is based on what I (still) remember of ZX Spectrum 48. Good luck, but you might consider upgrading your hw. ;/
The problem with Z80 machine code is that it has no floating point ops (and no integer divide or multiply, for that matter). Implementing your own FP library in Z80 assembler is not trivial. Of course, you can use the built-in BASIC routines, but then you may as well just stick with BASIC.