SDCC valid device list is missing devices - sdcc

I'm rebuilding a sdcc compiler after a mishap with my old system. I had been able to build on a pic18F4410, but my new setup does not include that in its valid device list.
The device list it is calling valid looks very small.
sdcc --use-non-free -mpic16 -p18f4410 test_blinkall.c
'18f4410' was not found.
Valid devices are:
p18f242 p18f248 p18f252 p18f258
p18f442 p18f448 p18f452 p18f458
p18f1220 p18f1320 p18f2220 p18f2320
p18f2455 p18f2550 p18f4220 p18f4320
p18f4331 p18f4455 p18f4520 p18f6520
p18f6620 p18f6680 p18f6720 p18f8520
p18f8620 p18f8680 p18f8720
I'm not sure where this device list is getting pulled from. I had it working once before(Using that exact compile line), so I'm sure the solution is out there somewhere...
I'd like to get that list updated with pretty much all supported PIC18 devices.
SDCC version:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.5.6 #1249 (Sep 2 2015) (UNIX)

Got it working - followed some instructions somewhere on installing SDCC via CVS checkout/compile. Checks out the latest of an old version. New version is 3.5, not 2.5.6.
Downloaded 3.5 release. Works fine.

Related

Getting meta-azure-device-update to work with yocto kirkstone release

I'm pretty new to the yocto project so bear with me if these are trivial problems.
I followed this(https://hub.mender.io/t/preparing-the-yocto-project-environment-from-scratch/801) tutorial and was able to compile a minimal yocto image, flash that image to a SD card and run it on a raspberrypi3.
My next goal is to add the azure device update layer(https://github.com/hiroyha1/meta-azure-device-update)
I cloned the repository to the sources directory and tried to add this layer via bitbake. Since LAYERSERIES_COMPAT was set to "warrior" this failed. I changed that variable to "kirkstone" and updated the syntax in all bb files, basically changing _append/_prepend to :append/:prepend.
Now when I try to run bitbake adu-image-base I get this error:
ERROR: No recipes in default available for:
$MYWORKDIR/sources/meta-azure-device-update/recipes-bsp/u-boot/u-boot-fw-utils_%.bbappend
I searched for this error and found out that sometimes there are "dangling appends". As I found out a fix for that could be to set "BB_DANGLINGAPPENDS_WARNONLY ?= "true"" in the layer.conf.
After running bitbake adu-base-image again the next error is:
ERROR: adu-base-image-1.0-r0 do_rootfs: Could not invoke dnf. [...]
No match for argument: adu-agent-service Error: Unable to find a
match: adu-agent
So I'm pretty stuck here. I think that the dangling appends are the reason for that error - the adu-agent-service isnt build so cannot be packed in the image, for me this makes sense since the root_fs is part of the OTA functionality. My approach would be to revert the "BB_DANGLINGAPPENDS_WARNONLY" change and get this layer to build properly, but I'm struggling to debug this further.
So how can I get this layer to work with the kirkstone release?
P.S if the proposed layer is utterly broken and there is no easy way to get this to work with the kirkstone release a hint would be great.

Error while cross-compiling chromium for ARM from x_64

I am trying to build chromium from source code following instructions at
https://chromium.googlesource.com/chromium/src/+/master/docs/linux/build_instructions.md
I have successfully built and tested chromium for amd device, Now I am trying to cross-compile it for arm device, However when I set the flag
target_cpu = "arm"
using
gn gen out/Debug --args='target_cpu="arm"'
I get the following error
ERROR at //build/config/linux/atk/BUILD.gn:13:1 (//build/toolchain/linux:clang_x86_v8_arm): Assertion failed.
assert(current_toolchain == default_toolchain)
^-----
See //ui/accessibility/BUILD.gn:294:20: which caused the file to be included.
configs += [ "//build/config/linux/atk" ]
Any leads would be appreciated
I have had the same issue where I tried building chromium on my Linux x64 server for an ARM based device, I was able to get past the issue by commenting the assert function out (as the function assert is usually for sanity checking based on my understanding). You can achieve this by modifying the file build/config/linux/atk/BUILD.gn and adding a # to the following code assert(current_toolchain == default_toolchain).
I followed the guidance on the webpage suggested by Asesh (followed Recipe 2) but the issue we are facing is to do with different current_toolchain and default_toolchain being set and would cause assert() to fail, the instructions given on the webpage doesn't seem to relate to out problem.(https://chromium.googlesource.com/chromium/src/+/master/docs/linux/chromium_arm.md)
To explain why I commented out the assert() code, reading https://www.chromium.org/developers/gn-build-configuration I found the following section: Snip of section "Overriding the CPU architecture".
As we both are configuring target_cpu="arm", this should be enough to configure and build chromium for our ARM devices (this would cause current_toolchain to be set to a different toolchain then default_toolchain, hence why assert() is giving us this error).
After commenting out the assert() I was successfully able to run gn gen out/xxx, gn args out/xxx and run autoninja to build chromium.
This issue has been fixed in Chromium:
https://chromium-review.googlesource.com/c/chromium/src/+/3074662

Ensuring installation/filesystem is properly in place

I have installed RedHawk 1.10.0 using Ubuntu 14.0.4LTS as described in appendix F of the RedHawk documentation. I also installed standalone IDE from SourceForge
again, as specified in appendix F, chapter 2.5. The IDE comes up looking ok, but here are the problems:
The components list is empty (there are supposed to be a set of pre-defined components). The directory is empty as well on the file system.
When attempting to generate C++ component, I get:
"Exception running "/bin/redhawk-codegen" /bin/redhawk-codegen - template=redhawk.codegen.jinja.cpp.component.pull --checkSupport
In detail, it said: bin/redhawk-codegen":error=2 no such file or directory. The /bin/redhawk-codegen is there under OSSIEHOME. The "pull" template is under: /usr/local/lib/python2.7/dist-packages/redhawk/codegen/jinja/cpp/component.
If I attempt to start Domain Manager I get an error "no domain configuration available".
So for all these problems it is obvious that I need to get a better picture of the expected file layout of all IDE and core RedHawk components. This is not clear from the documentation. Is there a starting point where I can begin debugging "where to find things"?
Regarding your first issue:
When installing for CentOS using the RPMs, a number of components, and devices are pre-packaged into the yum repository. When installing from source, as one must do for Ubuntu in 1.10, the pieces of Redhawk are modular and are installed individually.
The directions from Appendix F walk the user through installing each of the parts that make up the framework. The core, a GPP, bulkio, bustio, and the code generator. This does not include any components or devices (other than the GPP). To install these, you'll need to clone them from their respective git repositories and build and install from source either from the command line, or through the REDHAWK IDE. Building and installing the components from the command line follows the same pattern as the framework, there is a reconf script, which creates the configure script which creates the makefile script. eg. ./reconf; ./configure; make; sudo make install
Regarding your second issue:
These symptoms seem to point to the OSSIEHOME and SDRROOT variables not being set. Make sure that the OSSIEHOME and SDRROOT variables are set in the terminal using "echo $SDRROOT" and "echo $OSSIEHOME" prior to running the IDE. Keep in mind that the environments are unique to each session so, for example, having them set in one bash terminal does not guarantee they are set when launching the IDE from a desktop shortcut. Confirm they are set in your terminal, then launch the IDE from the same terminal.
Regarding your last issue:
This is likely also caused by your second issue. However, if it is not resolved following the above steps, take a look within $SDRROOT/dom/domain There should be two files. One DomainManager.dmd.xml.template and one DomainManager.dmd.xml. If all you have is the template then you need to create the DomainManager.dmd.xml file by copying the template. Then edit it and fill in the id and name fields. The default name is generally REDHAWK_DEV and the id should be a UUID.

HelloWorld Deployment with QtQuick 2.0 in Windows 7 and XP

I've been struggling to get my application deployed properly for several weeks now (it's a hobby), and I just don't know what else to try.
I started a new project in Qt Creator (2.6.1), by selecting Applications -> Qt Quick 2 Application (Built-in Elements). I tweaked the QML to make the background blue and text red:
main.qml
import QtQuick 2.0
Rectangle {
width: 360
height: 360
color: "blue" // Added!
Text {
text: qsTr("Hello World")
anchors.centerIn: parent
color: "red" // Added!
}
MouseArea {
anchors.fill: parent
onClicked: {
Qt.quit();
}
}
}
I'm using Qt 5.0.1 and the x86 MSVC 2010 compiler. I built the Release version and it ran fine in QtCreator. If you need more compiler specifics, I'll post them.
To deploy, I created a new folder on my desktop called HelloWorld/ and copied everything from H:\Qt\Qt5.0.1\5.0.1\msvc2010\bin\* and H:\Qt\Qt5.0.1\5.0.1\msvc2010\plugins\* and 'H:\Qt\Qt5.0.1\5.0.1\msvc2010\qml* into it, along with the Release HelloWorld.exe executable.
Overkill? Yes. But I'm desperate.
When I run HelloWorld/HelloWorld.exe in Windows 7 64-bit, the application runs fine. But when I copy this HelloWorld/ folder over into a virtual machine running Windows XP 32-bit, it shows a properly-sized window, but with nothing in it (white, with no text). When clicking in the center of the window, the window closes as it should.
So I loaded the executable in Dependency Walker, but nothing looked out of the ordinary (IESHIMS.DLL and WER.DLL were of course missing). I ran Start Profile, and got a slew of red errors:
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsAlloc") called from "MSVCR100.DLL" at address 0x78ABBA3B and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsGetValue") called from "MSVCR100.DLL" at address 0x78ABBA48 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsSetValue") called from "MSVCR100.DLL" at address 0x78ABBA55 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsFree") called from "MSVCR100.DLL" at address 0x78ABBA62 and returned NULL. Error: The specified procedure could not be found (127).
LoadLibraryExW("C:\documents and settings\owner\desktop\helloworld\platforms\qminimald.pdb", 0x00000000, DONT_RESOLVE_DLL_REFERENCES) returned NULL. Error: %1 is not a valid Win32 application (193).
LoadLibraryExW("C:\documents and settings\owner\desktop\helloworld\platforms\qwindowsd.pdb", 0x00000000, DONT_RESOLVE_DLL_REFERENCES) returned NULL. Error: %1 is not a valid Win32 application (193).
GetProcAddress(0x7E410000 [USER32.DLL], "UpdateLayeredWindowIndirect") called from "QWINDOWS.DLL" at address 0x013A8749 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C9C0000 [SHELL32.DLL], "SHCreateItemFromParsingName") called from "QWINDOWS.DLL" at address 0x013A8997 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C9C0000 [SHELL32.DLL], "SHGetStockIconInfo") called from "QWINDOWS.DLL" at address 0x013A89C9 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "GetTickCount64") called from "QT5CORE.DLL" at address 0x670726A7 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x755C0000 [MSCTFIME.IME], "ImeGetImeMenuItems") called from "IMM32.DLL" at address 0x76397354 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x4FDD0000 [D3D9.DLL], "Direct3DCreate9Ex") called from "LIBEGL.DLL" at address 0x01487198 and returned NULL. Error: The specified procedure could not be found (127).
I also tried to run a debug version, but I only have the 64-bit versions of the MSVC100 dll's, so I can't copy them to the XP machine (I can only run the 32-bit redistributable). I don't know what other tools I can use to try to solve my problem.
I know I must be doing something stupid, but I really can't find anything on the internet to help. It's really frustrating to spend so much time developing a Qt application, and then get stuck trying to deploy it.
I should note that the program runs just fine in a Windows 7 32-bit virtual machine (after MSVC2012 redistributable has been installed).
The application I'm really interested in running, runs really strangely in Windows XP. When I first run it, the window sizes properly and a couple text strings show up. But none of the Rectangle{} elements are displayed. I left the app running for a few minutes as I made myself some coffee, and when I returned to my computer, the window was blinking random shapes and text, to the beat of the text cursor! What the heck is that?! It looked like a basic math function was screwed up, so parts of the interface were being displayed at improper sizes and positions. I even saw the real interface show up for one blink of the mouse cursor (and yes, the random shapes appear and disappear to the beat of the mouse cursor).
On a whim, I tried using the application (clicking where I know a text box exists), to populate one of the lists, and it worked! The application is running completely fine, except for the graphics. I know Qt 5.0 reworked some of the OpenGL handling, right? Could this be a bug, or maybe a library I haven't installed?
I also encountered the same problem when deploying quick 2.0 application on Windows XP builded by Qt 5.1 rc1 with ANGLE; It's seems to be ANGLE problem, on http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL is recommended to use OPENGL for XP, also Qt 5.1 with OPENGL works for me on Windows XP
Install Microsoft Visual C++ 2010 Redistributable Package (x86)
on client machine (windows xp).
Use release build, not debug build, You seems to be using Debug
version.
Don't use OpenGL(Most of XP Users may note have updated OpenGL
version, otherwise‍ you may have to force them to upgrade it.)
Update
Use OpenGL for Windows XP. User have to install or upgrade their OpenGL drivers. Read this.
Try using the MinGW version instead of the VC++ one. It's likely that there are layers and layers of .Net stuff preventing you from running on XP. XP came out before 90% of the current .Net stuff existed which is why it wont work as it's not installed.
Just a guess but its worth a shot.

Why does windows side by side (winSxS) install policy for auto upgrade when there are known issues between versions?

We have an app compiled using MSVC 2K5, SP1 (version 762 msvcrt80)
All is well, right up until somebody installs on the same machine .Net3.0SP1, and along with it msvcrt80 version 1433 is installed and a policy to automatically upgrade.
Now we have random crashes all over the place and unhappy customers.
I understand we can adjust our manifest files to force the usage of a specific version, but I've only found the really ugly way of copying detail that is auto generated and modifying it by hand. This is especially unpleasant with a large number of apps to fix
Can we instead get rid of the stupid 'upgrade' policy in the winSxS directory?
Is there an option/flag to compile for a specific version only and still automatically generate the manifests?
Find the generated manifest for your specific version of the CRT. Then add a pragma to the main file of your application:
#pragma comment(linker,"/manifestdependency:\"type='win32' " \
"name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".CRT' " \
"version='" _CRT_ASSEMBLY_VERSION "' " \
"processorArchitecture='x86' " \
"publicKeyToken='" _VC_ASSEMBLY_PUBLICKEYTOKEN "'\"")

Resources