How to implement reading of CAN bus data on clean Android device? - Android Auto General

Hi,
I would like to implement reading of CAN bus data from a device with clean Android.
Any general info/hints/guidelines where and how to start with implementation would be appreciated.
A general info how Android reads data from CAN bus would be even more appreciated
Note: I know this should go to software development section of forum but I'm new here and still am not allowed to submit to that section.

In order to expose vehicle signals (on a CAN bus for exemple), you need to develop an Vehicle Hardware Abstraction Layer (VHAL). It is pretty well described here : https://www.androidautomotivebook.com/android-automotive-and-physical-car-interaction/
In details, you can have several kind of implementation of a VHAL :
- it could be a full SW implementation using a CAN driver in your Android sys image
OR
- you can have a small hardware CAN microcontroller that will be in charge of reading CAN frames for you and sends only value change (you will then save a lot of Android OS CPU compare to a CAN driver inside sys image...)

Related

MSM72xx chipset-level configuration tools

**BE VERY CAREFUL WITH THESE TOOLS. IT IS ENTIRELY POSSIBLE TO DO IRREPAIRABLE DAMAGE.**
Ripped from the Xperia ROM, these programs allow control over a number of settings in the device.
RegisterEditor should allow direct reading and writing of registers on the qualcomm msm72xx chipset, which will allow control over virtually every setting available, just need to determine addresses and potential values, etc
TBattery talks directly to the battery chipset, and returns values such as mAh capacity, battery temperature, current draw, percentage remaining, etc.
DbgTerm allows real time display of Debug Log on device.
DebugTool allows among other things redirecting of KITL output to USB. You can also configure the level of logging for the Debug Log and have it save the log to SD.
Save Kernel KITL Log to SD:
1.) Open DebugTool.exe, input value 43D in [5]DebugFlags, click menu -> write
2.) Shut Down with Power Button (long press), and start up
3.) Do actions you want to be logged (load program that fails, drivers, etc.)
4.) Plug phone into usb, connect w/activesync and copy off /Storage Card/HtcLog/*.txt
5.) Open DebugTool.exe, input value 0 in [5]DebugFlags, click menu -> write
FMTuner allows direct advanced control over the FM Radio chipset, among other things allows activation without headphones (although I don't see a way to route audio to the speaker)
Uni-AT allows issuing of AT commands to the ROM.
dump a raphael ROM and open up rilphone.dll in a hex editor, look for the strings like +CRING, @AGPSADDRESS, $HSUPA_STATUS, these are AT Commands that can be issued to the radio ROM, to query status and alter settings.
Query an existing setting like so:
AT+CRING?
AT$HSUPA_STATUS?
[email protected]?
Querying a command should give you some input as to the required format.
Change a setting like so:
AT+CRING=1
AT$HSUPA_STATUS=1
[email protected]=1
For a setting with multiple parameters, such as AT+HTCNV, set it like so: AT+HTCNV=param1,param2,param3
Useful AT Commands:
AT+RADIOVER : returns radio rom version
AT+HTCNV : returns +HTCNV: 1,10,8 - param1 = DTM support, 1/0, param2 = MCS support 8/10/12, param3 = HSDPA Category 6/8/12
AT+HTCENS : ENS support 1/0
Reserved for more stuff
WOW!!!!!!!!
this would get alot more views in the diamond section.... thanx for posting it still
Looks like most of these tools were posted in Diamond section already here: http://forum.xda-developers.com/showthread.php?t=416334&highlight=htc+debug+tools
However everyone seemed to miss the significance of RegisterEditor entirely, it's listed in the linked Wiki as a 'very basic registry editor' but it has nothing to do with the registry at all..
Anyway, this is a dup post. Doh! But these versions are newer, and i'll try to make it more useful by including more knowledge about the apps
Wow! Kudos for this! Amazing. Register Editor is very powerful. Gotta map this out
Interesting. I wonder if these tools could be useful in unlocking the FM radio on CDMA Touch Pros.
[Edit: I noticed that you specified these were for the 72XX chipset. Any idea what kind of compatibility they have with the 75XX?]
Not sure, worth a try since they are similar, the api might be the same. You should be able to try a read operation without harming anything..
FMTUner Tested on Raphael
I've tested FMtuner on Raphael CDMA but nothing happens, I mean, the tool works, but no frequency is detected.
Fabian
bedoig said:
Interesting. I wonder if these tools could be useful in unlocking the FM radio on CDMA Touch Pros.
[Edit: I noticed that you specified these were for the 72XX chipset. Any idea what kind of compatibility they have with the 75XX?]
Click to expand...
Click to collapse
there is CDMA debugtools set, grab it from any cdma beta rom (maybe posted on ppcgeeks, if not, i can upload it here), similar to gsm but for example the AT tool differs (UNI_AT will not work on CDMA) etc etc.
bump for adding new AT commands
Is there some documentation for tBattery explaining exactly what each reading is?
Also have a suggestion if possible that it include a time hack with each sampe it saves to the log instead of just a start and end time.
Thanks in advance.
cmonex said:
there is CDMA debugtools set, grab it from any cdma beta rom (maybe posted on ppcgeeks, if not, i can upload it here), similar to gsm but for example the AT tool differs (UNI_AT will not work on CDMA) etc etc.
Click to expand...
Click to collapse
Could you post the CDMA debugtools set?
Thankyou very much
someone asked me in PM today to post the tools, see attachment.
tbattery
how exactly do i install this program? do i just copy it to my SD card and open it from my phone? thanks in advance
yup, copy to eg SDcard to DebugTools folder and run the debugtool

[DEV] Blackstone Linux / Android Development

This thread is for development discussion only. If you are not actively working on the project, please go to the discussion thread where your contribution will be more valuable. By keeping this thread clean, we can hope to get Android working on our devices much quicker.​
Project Status:
We now have a 2.6.27 kernel which is capable of booting Angstrom and Android. Android looks good and is responsive, but most core functions are not there yet. Work is focused on kernel development to provide us with a stable base with working hardware. You can find test files in the second post.
We have a Wiki page where the project gets documented in some detail.
History
The development had a slow start while Orux worked out how to make the mdp talk to mddi to get a working display. We hope that progress will be faster now as there has been considerable work on the Diamond and Raphael hardware, which is quite similar to the Blackstone.
23Feb09
Screen problems fixed at last - many weeks work from Orux got the mdp talking to mddi and give us a working display.
03Mar09
Wow! So much progress in just a week! We now have working SD (some issues with brands of cards - under investigation), allowing booting direct from the SD card; working hardware buttons, and some GSM functionality (the network connects and reports of sending SMS successfully). Credit to Orux, Pichurri, Cybersalsero, Jonlar (and have I missed anyone out - not me, I have been spectating!). Pichurri has posted a full install package on teh wiki, go try it and give feedback in the testing thread.
(to be continued!)
Current tasks
Debugging SD card problems many ppl having
Getting our own version of Android (currently using builds optimised for Raph/Diam
More GSM functions - who will be first to make a call???
What can I do?
You tell us! First thing would be to get yourself set up with a development environment. You need Linux on your PC - either installed as the main OS or if you use Windows, in a virtual machine (eg Virtualbox). Then follow the instructions on the wiki to get the sources and latest diff.
Reserved for files
Here you will find the up to date files related to the project.
Pichurri's full 2.6.27 install package is on the wiki here
You should correct the posts: 2.6.26 and 2.6.27 is the kernels used. More info: www.kernel.org
brumbrum said:
You should correct the posts: 2.6.26 and 2.6.27 is the kernels used. More info: www.kernel.org
Click to expand...
Click to collapse
We are using 2 kernels:
2.6.25 --> htc-msm-2.6.25 branch in git.linuxtogo.org. This is the kernel that we are testing in our machines these days.
2.6.27 --> htc-msm-2.6.27 branch in git.linuxtogo.org. Where we will stay in a few days. Better kernel, more improvements. Here is where people from other projects are working now.
orux said:
We are using 2 kernels:
2.6.25 --> htc-msm-2.6.25 branch in git.linuxtogo.org. This is the kernel that we are testing in our machines these days.
2.6.27 --> htc-msm-2.6.27 branch in git.linuxtogo.org. Where we will stay in a few days. Better kernel, more improvements. Here is where people from other projects are working now.
Click to expand...
Click to collapse
Sorry, my mistake. Typed the message above late in the night.
But in the first and second post in this thread it says 2.2.65 and 2.2.67.
Thanks, was posted in a rush, just pm me if you see more errors. We use the odd numbered dev kernels, they will always have the most recent stuff.
A challenge for someone who likes graphic drivers:
I think linux is using ~10% of epson controller capabilities.
We have a lot of information about this controller, and open source code from epson.
Perhaps someone would like to work with this stuff.
orux said:
A challenge for someone who likes graphic drivers:
I think linux is using ~10% of epson controller capabilities.
We have a lot of information about this controller, and open source code from epson.
Perhaps someone would like to work with this stuff.
Click to expand...
Click to collapse
Do you mean things like picture-in-picture? Would be good later on in the gui - multiple desktops, that kind of thing. Also I noticed the Epson controller handles TV-out. Do we know if the out-connection exists for this, or have they just not connected it up?
Another thing to consider maybe USB on-the-go - the MSM72xx supports it; if (big if) the usb port has the right connections, it would be possible to mount external storage.
But I think it's more for later on - core functionality would be about making calls, sms, GPRS/3G. Let's see what we get from the latest kernel. Orux have you talked to the RAPH/DIAM guys on irc about merging?
orux said:
A challenge for someone who likes graphic drivers:
I think linux is using ~10% of epson controller capabilities.
We have a lot of information about this controller, and open source code from epson.
Perhaps someone would like to work with this stuff.
Click to expand...
Click to collapse
what makes you believe that?
whatever makes you believe it, share it!
if you have anything like docs,etc to share or point to lets have it !
Blackstone has got 2 graphic processors:
--->mdp, inside the chip. We have drivers in the kernel (mdp.c, mdp_ppp.c ...) I am not sure what capabilities are being used in current kernel. There are not good docs about mdp processor (I haven't got any useful).
--->epson controller. It can do:
• Picture in Picture, Transparency, Alpha Blending
• Image Rotation (90°, 180°, 270°) and Mirroring
• Scroll Assist
• AME (Auto Movie Enhancement)
• Supports up to three layers
• Image Doubling
• Bi-Cubic Scaling (1/2x ~ 8x)
• Over/Down Sampling Scaling (1/8x ~ 8x)
• Edge Enhancement
We don't have driver support in current kernel, but we have docs and source code from epson (link posted in discussion thread).
Htc Touch Pro has a tvout usb cable adapter, and seems to work in linux! I don't know if this cable works with our device.
USB on-the-go: interesting TODO.
patp said:
Orux have you talked to the RAPH/DIAM guys on irc about merging?
Click to expand...
Click to collapse
Not yet; perhaps your (or pichurri, ...) task when we have a good .27 diff. I have too much language limitations for an on-line discussion
p3ngwin said:
what makes you believe that?
whatever makes you believe it, share it!
if you have anything like docs,etc to share or point to lets have it !
Click to expand...
Click to collapse
OK, OK! These things take time - we all have other jobs I guess. We plan to get any open source docs online in a systematic way, we just need to figure out a reliable way - ie not RS etc. And we have to be careful of proprietry materials - we don't want copyright lawyers after us...
If anyone wants to offer us some rock solid webspace, that would be awesome.
TODO: Investigate instability of screen
I think that problems with screen are caused by onscreen keyboard. This keyboard is an excellent hack, but it is not 100% integrated with android.
We need to test a kernel without it.
orux said:
I think that problems with screen are caused by onscreen keyboard. This keyboard is an excellent hack, but it is not 100% integrated with android.
We need to test a kernel without it.
Click to expand...
Click to collapse
Or use the cup cake version with the keyboard in android it self.
Full doc of the epson controler : http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=278&Itemid=40
Link is at the bottom of the wiki, add yours
I don't think we need to put all the docs at the same place, just add links at the bottom of the wiki, either hosted or link to website.
I can provide hosting if you need, just pm me.
repository
what do you guys think about creating some kind of repository(git or svn) to upload and share our blackstone kernel? i think it would make development much easier if you could see changes of other people immediately. we could use github or sourceforge.
I also think the On-Screen Keyboard is a problem.
Earlyer today I was goofing around in Android and every time I moved the keyboard, the graphics started acting very weird.(scrolling, not updating etc.)
When I hit F5 on the OSK, it would refresh Android and go back to the home page and the screen would be normal again.
Maybe route the OSK to a pip on the epson?
It's git for kernel dev, anyways svn sucks (inc troll)
If we set up a git, we'll need a guy working as a maintainer and pulling from everyone. This may become usefull when people start working in many different areas of the kernel, but for now diffs are better as they can be easily shared, and there's a howto in the wiki.
patp said:
OK, OK! These things take time - we all have other jobs I guess. We plan to get any open source docs online in a systematic way, we just need to figure out a reliable way - ie not RS etc. And we have to be careful of proprietry materials - we don't want copyright lawyers after us...
If anyone wants to offer us some rock solid webspace, that would be awesome.
Click to expand...
Click to collapse
hey i have a servage account that i hardly use which has massive space and bandwidth i could give you a ftp account to and any sql servers you may need. let me know
Rewpparo said:
Full doc of the epson controler : http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=278&Itemid=40
Link is at the bottom of the wiki, add yours
I don't think we need to put all the docs at the same place, just add links at the bottom of the wiki, either hosted or link to website.
I can provide hosting if you need, just pm me.
Click to expand...
Click to collapse
Agreed, the wiki is the best place for this. Would you be happy for me to mention your hosting offer on the front page (which will quite soon need a better structure I'm sure).
JanSchotsmans said:
I also think the On-Screen Keyboard is a problem.
Earlyer today I was goofing around in Android and every time I moved the keyboard, the graphics started acting very weird.(scrolling, not updating etc.)
When I hit F5 on the OSK, it would refresh Android and go back to the home page and the screen would be normal again.
Maybe route the OSK to a pip on the epson?
Click to expand...
Click to collapse
Now that my friend, is a stunning idea (if it can be done simply). How does it relate to the Android OSK mentioned by xmoo? I guess the linux one is low level whereas the Android one is basically an app in the gui. Advantages to both, but if it works out of the box, the android one would mean we could essentially get rid of the linux one. We have ssh if we want to type in a console (or maybe android terminal app?).

dumping a code

Greetings everyone
I have worked on 8051(atmel), processor.
in those processors we need to dump codes using a dumper.
The question is how do we need to dump the code in the raspberry pi.
My project is to control a small bulb or an LED just to switch it on and off,
and if i need to do that wirelessly how do i do that. i mean if i give an input using my mobile(android) i want that light to be switched off.
P.S : i am using WI-FI.
Php?
Android app or web server -> php request -> MySQL -> c or python -> GPIO -> resistor -> transistor ?
That's one way to do it.
Sent from my iPad using Tapatalk HD
No vinodmadhu6, the CPU on the Raspberry Pi is nothing like the Atmel AVR chips, you can program using a range of modern programming languages.
I'd say Python would be a good way to go, especially if AVR has been your main experience of programming up until now, as it is an easier language to learn
An 8 bit 8051 it definitely isn't! It is a full 32 bit ARM processor capable of running various flavours of Linux.
It is possible to pull the voltages high and low on the pins on the header of the main board, referred to as the GPIO.
Have a read of this:-
http://elinux.org/RPi_Low-level_peripherals

Windows 10 preview

Anyone gave this a try yet?
http://gizmodo.com/you-can-download..._source=gizmodo_twitter&utm_medium=socialflow
gsmyth said:
Anyone gave this a try yet?
http://gizmodo.com/you-can-download..._source=gizmodo_twitter&utm_medium=socialflow
Click to expand...
Click to collapse
Nope, have no use for it...
I've looked into interfacing with GPIO in C# but found it to be lacking in many ways, the most important being speed. It also appears to be impossible to repurpose pins with ALT functions which Microsoft have fixed to SPI/I2C etc- you can't use them as basic GPIO pins which makes it impossible to use Windows 10 with many, many Pi accessories. I have successfully tested I2C, however, and SPI to an LCD display is next on my list.
As for straight up GPIO twiddling, my litmus test was multiplexing a 7 segment, 4 digit display - not exactly an uncommon or complex activity. I couldn't get a stable timing resolution any smaller than 500 microseconds, and at this point you're plugging decimal numbers into DotNet's TimeSpan.FromMilliseconds and things are getting silly.
I'll have to try it with a straight up loop to see what overhead the threaded timer introduces, but right now Visual Studio is refusing to deploy code at all- probably because I've got a shoddy networking setup to bridge the Windows IOT ethernet-only connection to my PC.
One thing is abundantly clear; if you're not a DotNet/C# developer then it isn't for you.
It's Microsoft, just saying.
gsmyth said:
Anyone gave this a try yet?
http://gizmodo.com/you-can-download..._source=gizmodo_twitter&utm_medium=socialflow
Click to expand...
Click to collapse
It is just for developers. No desktop only app testing. Total waste of time.
gsmyth said:
Anyone gave this a try yet?
I'm also interested in finding out. Haven't tried it myself yet.
Anyone got it running?
How does it compare to 8.1?
Click to expand...
Click to collapse
@wodeh: what do you recommend to use in place of Windows 10 ? How does it compare to linux+python (with RPi-gpio) ?
I never used my RPi for this kind of things, I'm just curious.
@davcri91 it depends what you're familiar with- if you already know C#, use Windows and are familiar with Visual Studio then it will certainly get you off to a good start. Right now, though, support for Pi add-ons in Windows 10 is going to be all but non-existent so it's not the best all-round experience.
Raspbian, the official OS, grants you much more flexibility- you can choose to use Python, Ruby, Node JS, PHP, C, Go or really whatever you fancy. All the current documentation and software support is focussed on this OS, so Pi add-ons- especially more complicated things like our Unicorn HAT or the Pi DAC+- will work.
As for performance, I've yet to try a better test since I couldn't get Visual Studio to upload code to my Pi anymore and didn't want to waste any more time with it. My initial experimentation suggested that C# is tremendously slow at toggling an IO pin though, I couldn't even reasonably multiplex a 4-digit, 7-segment display whereas in Raspbian I can clock out serial data to a 128x64 pixel LCD at 200FPS.
Someone with a more recent working knowledge of C# ( mine is about 10 years out of date ) could probably do somewhat better... I'd hope.
The GUI "Universal App" stuff seems to be a talking point for Windows IoT but this has absolutely no utility in any setup that doesn't have a screen. My preferred setup for Raspberry Pi UIs is HTML/CSS with a RESTful or Web Sockets API- that way I can use my phone, my laptop, or whatever screen/device is handy.
So to summarise:
Windows IoT:
* Targeted at existing C# developers
* Dev-environment with step debugging and all the trimmings
* GUI framework... I think... for better or worse
* Slow to build and deploy
* Slow IO, it seems
* Impossible to use pins reserved for I2C/SPI as general purpose IO, breaking any add-ons that rely on this
Raspbian:
* Complete and total free for all- could probably even use C# with Mono
* Whatever Dev environment you can cobble together.. it'll probably be Sublime Text on your computer plus SCP or VIM/NANO/IDLE
* No standard framework for doing anything, which is a shame- there needs to be an official stance + docs on App/Game dev for the Pi
* You can just run Interactive Python and toggle GPIO pins on and off instantly with commands- fast deployment/test/fail cycle since you're already *on* the device
* IO pins will toggle at 20 Megahertz using C, although the resulting signal will be useless mush
* You can re-assign IO pins as you see fit- SPI and I2C can be regular GPIO, and you can use ALT functions to move some things around
This is a totally top-of-my-head summary of the strengths/weaknesses of each. It's an apples to oranges comparison, though!
You made a really great post, thank you wodeh
For now I think I'll stick to linux because I'm used to Python.

Communicate with Microcontroller through TCP/IP

I am trying to figure out how I can light an LED with my NodeMCU V2 via the use of WiFi and a phone application I create via Android Studio but I don't know where to start nor can I find any information on how I can do it, I've seen tutorials where they make me use their 3rd party tools to achieve this and I've seen it done on a web server but I'd like it to be on a phone application. Is there any way this can be done? Bluetooth is not an option because I want it to be accessed from anywhere as I plan to port-forward the IP in the future.
This is a very interesting idea. I do not have a specific answer. I did some programming of 68HC11 about 20 years ago. The chip was mounted on a system board and connected to my desktop computer using a serial cable. I would develop the program on the desktop then download to the `11 over the serial cable. There was a small program in the `11 that would receive the program and load it into the `11 memory.
Structurally you need similar components: a software development system that run in your phone [a small Android Studio], an electronic communication link [Bluetooth, http, whatever], a system board, and software in the system board to receive commands and a data stream from the phone and load the stream of machine language into the 68HC11.
I still have the system board: CME11E9-EVBU AXM-0199 REV.C Axiom Manufacturing. For more info do a Google search for that ID, or just click here...
https://canada.newark.com/axiom/cme-11e9-evbu-ed/spi-sci-rs232-lcd-dev-board/dp/13C2791
I am not familiar with what is going on in that section of technology these days, but much of what you need should be available and findable. If such a system does not yet exist then it is a business opportunity waiting for someone like yourself.
All the best to you

Categories

Resources