I have written code using tcl/tk for quite some time and I would not have much problem writing this code (actually, I have written a very similar code before) but since Android is Java I will have to educate myself before I try to build this app. What I am trying to find out is how much will I have to educate myself before I can pull this thru. Learning to write code in tcl/tc did not took me long and I actually did a lot of learning while writing code so again, not having experience in java I am seeking the feed back of those that are currently way ahead of me to give me a better feel of what I am getting into... :victory:
This app will be based in a program built for windows. I have thru the years ask the vendor if they are going to port it to android and I always get the same response, "in a few months"...
Here is what I am looking forward to build...
Overview
Need to create an Android app that will consist of an UI and data processing terminal to communicate with a serial device. The terminal will be capable of sending commands to the serial device to gather information, process the information and then display it in human understandable terms.
Goals
Basic program:
* Create communication with a FTDI chip at 1200 Baud Rate, 8 data bits, No Parity, 1 stop bits and xon/xoff flow control, I have prove it to work with no control since the amount and rate of data is so small.
* Capable to send hex ascci commands, receive a dump in hex ascci then translate that hex ascci dump into decimal format for processing. The serial device communication and hardware cannot be changed. Most all commands are set but there is one command that the value will change depending on previous data found.
Example of communication:
send :000000037D (status command)
Response:
Hex/ascii -> decimal
:0401010C2A0094 -> 4 1 1 12 42 0 148
:0401010C9A0489 -> 4 1 1 12 154 4 137
In this example column 2, 3, 5 and 6 has the data I need and will have to process to display the final values.
* Status command should have option to be controlled with a timer with options for 1, 5, 20, 40 sec and Timer off. There should be a button on the UI to send that status command, also, the ability in the future for the command to be microphone driven (x amplitude loud noise will trigger command).
UI:
* Dark colors to keep the display from eating up the battery.
* Should turn off the display every 10 seconds and should come up on new data, mic driven or phone shake.
* Should have a display where the last data numbers will be displayed. Also to have the ability to create a second larger display with the same last data numbers.
* Need 8 buttons for commands, drop down menu for settings (timer settings) and exit button.
* There should be a space (table) to display data, up to 99 records. It should look more like a excel spread sheet with just 2 column. These columns will bet the data location and the data itself. The table should be able to hold about XX amount of records, if it gets larger then a scroll bar should be used to navigate up and down the table.
Enhanced program
Display altitude/barometric pressure on request(capable phones).
Future:
Right now the device talks to the computer via a serial/usb dongle but I am planning to build the hardware to make it Bluetooth capable but in very few odd instances I might have to run it with the dongle due to the distance between the device and the phone might exceed the most common 30 feet Bluetooth maximum distance.
Im tired of taking my pc to a dusty and pc unfriendly environment so I have decided to take the plunge and build the app myself. Learning Java and android will be beneficial as I can see me in the future building more apps for personal use .
As it is now I can control this device using a hyper-terminal in my Samsung Note. Problem is having to type the commands manually, getting the responses back, translating those hex responses to decimal then building the response... too much work by hand...
Currently im using Slick USB Serial Terminal. Although they have a paid version that could help with the commands it will still leave me with processing the response by hand. It is useful when all I want is to advance the display on the device as it is the most used command but still at times it is imperative to get the status from the system and I am back to square one. And if I wanted a full status report It would take me nearly an hour to process by hand...
I have bought these books:
Java All-In-One for Dummies 3rd edition.
Programing Android, O'Reilly, 2nd edition.
Beginning Android 4, Application Development, Wei-Meng Lee, seems to be 1st edition.
Android application development for java programers, James C Sheusi, also seems to be 1st edition.
Anyone care to comment or recommend a book or a website?
Thanks everyone! You will be seeing much more of me as soon as I start having questions!!! lol!
Is my English really that bad? lol!!!
kinda hard to believe no one can answer this question here. moving on.
Probably this that you may be looking for.
Save time on re-inventing the wheels, or you can decompile theirs.
one of the hyperterminals I been using provides their source so Im not too worried about that. I did not knew you could decompile and app. Anyways, thanks for your reply.
Related
Anyone know of a good calculator program that will let you enter a full formula for evaluation similar to the behaviour of PowerCalc or SpeedCrunch (which are available for XP) for Windows Mobile?
I just found one called CalctorMobile that does it but it's kind of slow and "clunky" feeling... like someone programmed it in about 5 minutes Any other suggestions?
Sorry if this should be in a different section of the forums...
I'm still in precalc 2 but i use SpaceTime 3.0. I think it's awesome..you should try it out..i don't know if it will fulfill your needs because i'm not in calc yet but it does have a lot of calc stuff. It's very user friendly and looks very nice.
its a 30 day trial
http://www.spacetime.us/pocketpc/
Sorry, I was just using "calc" as short for "calculator". I don't actually need something capable of doing calculus. I just want something that I can type a whole line into and it will follow order of operations and solve it.
e.g.
I type in "(4 + 4) * 2" and it spits out "16" rather than having to punch in each step individually.
oh then spacetime will be great for you! give it a try, you will love it.
it even solves equations like y or f(x)=....
sometimes my teacher writes a problem on the board and type it right into my phone..it takes him about 7 steps to solve the log or exponential function problem, while it takes me about 20 secs to enter the problem in haha..u just cant get used to using it too much..u will not learn..make sure u only use it to check ur answers and not depend on it for every problem.
I've finished my post secondary education. I just prefer that type of calculator. I'll be checking SpaceTime out tonight or tomorrow. Thanks for the suggestion.
This may be getting too nerdy, but I was looking at a winCE emulator that runs the HP48/49/50 calculator on the device. Gotta love RPN for fast calculations!
Nerd here as well so heres a link to a free HP RPN calculator: http://free42.sourceforge.net
Works great and the price is right!
SpaceTime is pretty good. Way more powerful than I need.
Only issue I've noticed so far is that it doesn't behave very well when the screen is rotated while it's running. It does not resize it's display unless you close the application and open it again.
I'm developing a touch screen based system for controlling electronic music. As part of the development, we'll be building our own touch screen, but that's not going to be ready for some time. In the mean time, I need to start writing the software (which will be done in java), and I'm going to need a touch screen to use for testing.
So, I am NOT trying to write an application for the Galaxy Tab. I am writing a application that runs on the my desktop, and I'd like it to be able to get touch information from the Galaxy, in any way practical. I've looked into using an iPad for this, but it looks to be too much of a pain to be worth it. All I need is a way of my java application receiving the list of co-ordinates of touches from the tab, in real time. I don't need any higher level gesture interpretation (as I'll have to do that on my end for the final system anyway), just all the touch co-ordinates. Does anyone have a suggestion on the best way to go about this? Is there something in existence already to accomplish this easily, or is there any kind of java library I can use to make calls to a connected tab from my application? I've been googling around, but haven't found any particularly useful information on the subject, as the tab is chiefly meant to be a stand-alone item, not a pc peripheral. Any tips on where I might start looking would be a huge help. Thanks!
-cullam
cullambl said:
I'm developing a touch screen based system for controlling electronic music. As part of the development, we'll be building our own touch screen, but that's not going to be ready for some time. In the mean time, I need to start writing the software (which will be done in java), and I'm going to need a touch screen to use for testing.
So, I am NOT trying to write an application for the Galaxy Tab. I am writing a application that runs on the my desktop, and I'd like it to be able to get touch information from the Galaxy, in any way practical. I've looked into using an iPad for this, but it looks to be too much of a pain to be worth it. All I need is a way of my java application receiving the list of co-ordinates of touches from the tab, in real time. I don't need any higher level gesture interpretation (as I'll have to do that on my end for the final system anyway), just all the touch co-ordinates. Does anyone have a suggestion on the best way to go about this? Is there something in existence already to accomplish this easily, or is there any kind of java library I can use to make calls to a connected tab from my application? I've been googling around, but haven't found any particularly useful information on the subject, as the tab is chiefly meant to be a stand-alone item, not a pc peripheral. Any tips on where I might start looking would be a huge help. Thanks!
-cullam
Click to expand...
Click to collapse
Ok, well I'm going to try and be brief and not turn this into an Android programming essay so here goes.
You have a couple of different routes you can take.
1. If you use eclipse for development and you hook up your tablet, you can watch the log and see that it prints useful information constantly, basically debug output that tells you whats going on in the background. If you just want to look at it, you can probably see it there.
2. This would be my choice, but I'm a programmer so I love a new adventure. I would recommend you just write a quick app for your tablet that pumps out the location of a touch whenever you touch the screen. If you are familiar with sockets and such, you can just write a simple server Java app that collects packets of data from your tablet, and just have the tablet send out a multicast packet containing the coordinates you touch every time you touch the screen.
There are probably some other ways, but if you are already going to be doing the bulk of the project in Java, you aren't looking at a difficult learning curve to write a basic little android app.
Thanks! I'll definitely try the eclipse trick. And yeah, writing an app on the tab is probably going to be necessary, but MUCH easier than having to learn a new language, and get an official license to do one on the iPad. The thing I'm really unsure about is the available communication methods for getting data back and forth between them. I was hoping there might be some sort of java api to get calls going through the usb connection. So I'll guess I'll see what the Eclipse hook up shows me.
cullambl said:
Thanks! I'll definitely try the eclipse trick. And yeah, writing an app on the tab is probably going to be necessary, but MUCH easier than having to learn a new language, and get an official license to do one on the iPad. The thing I'm really unsure about is the available communication methods for getting data back and forth between them. I was hoping there might be some sort of java api to get calls going through the usb connection. So I'll guess I'll see what the Eclipse hook up shows me.
Click to expand...
Click to collapse
apple stuff is crap anyways, leave them to their pretentious commercials and closed minded development.
as far as the android sdk, I think it will take you a lot less time to just use network communications. google socket client/server java tutorials and you should be set to go in about 2 hours. I have implemented it, its all straight forward, and imho probably an easier app to write that something that pumps out of the usb port
Awesome, thanks
This may be an area where the dumbphones win, but I've only been able to find one app that is just a timer--open the app, you've got a timer--and it's way too cumbersome.
When the app opens, I need to see:
A number pad.
A Next button (for moving from hh/mm/ss).
A Start button.
ETA: Also, number pad input needs to overwrite the current field, not insert.
These features have been available on every dumbphone for over a decade. Can't they be done in Android?
This isn't exactly what you are looking for, but I use it.
https://market.android.com/details?id=com.hybrid.stopwatch
It has a stopwatch, too, but remembers which mode you chose and launches in that mode.
Yeah, I tried that one and it has all the same issues as Kitchen Timer, though it's nicer to look at. Who decided an Android timer would use this cumbersome +/- interface? It's made worse by the fact that once you get a cursor in a field, it inserts rather than overwrites, and won't jump fields.
Ideally, the only actions necessary to set a timer should be open-0-0-7-3-5-start, no navigation, no clicking up and down as if we had a device with two buttons (i.e. a watch).
Yeah, I looked around for a timer too. This was the easiest to use that I found. I rarely have to change the time on it so for me I launch it and hit go. But if I was constantly changing the value, it would be annoying. Makes you want to go out and write your own!
I'm poking around in App Inventor to see what I can manage--I would be lost writing code from the ground up. I think I should at least be able to come up with something with multiple one-button presets on the starting page, and they can probably be user-programmable, but I don't think App Inventor has the commands to give focus to a numerical text-box (thereby highlighting the contents for replacement and launching the number pad) on app initialization.
If you want, take the time to send me some EXACT specifications and I'll see if I have time to whip something up; we're not talking 10 year global weather modeling here! LOL
TIA,
Roots
Rootstonian said:
If you want, take the time to send me some EXACT specifications and I'll see if I have time to whip something up; we're not talking 10 year global weather modeling here! LOL
TIA,
Roots
Click to expand...
Click to collapse
I'm actually making progress in App Inventor, but if it comes to naught, I'll PM you.
Well, it's not finished and it's not pretty, but it's a timer
So far, I can't get the box to grab focus when the app opens, but it's still quicker for entering a new value than the others on the market. The empty red bar will bring up the number pad. Hit hours, mins, or secs to start the timer with the relevant units. Start/Pause work, and if you enter, for instance, "90 + Mins" it will convert it to 1 hour 30 mins. More than two digits in the Hours box will break the UI, but it will count them down
The preset buttons and persistent notification box don't do anything yet, and it doesn't remember the last value entered if you close the app yet, but the core functionality is there.
http://dl.dropbox.com/u/7299403/TimerSAUR.apk
ETA: enabled persistent notifications and shake-to-stop.
ETA2: remembers last value entered and whether Persist was checked, made some visual tweaks and added an icon.
ETA3: re-skinned the whole thing and hid the preset buttons for now. I can add features, but I'd call it a complete app, and more functional than anything on the market, for my purposes.
ETA4: I, um, even fixed those script errors that caused FCs if you tried to start a timer with all fields empty. Details.
D'oh! As far as I can tell, the App Inventor "clock" function pauses if the device is sleeping--not exactly practical for a timer :/
Maybe I'll have another run at it tomorrow.
Maybe you can save the time that it paused, then calculate how much time has passed when it wakes up and start from there. That won't help much if your time expires while it is sleeping, though. Will App Inventor let you prevent sleeping?
Talking to App Inventor community members, I think the clock provided is just not workable for something like this. Maybe if I'm willing to build a windmill to turn a doorknob, I could figure something out, but I'd probably be better advised to start learning real code if I want to pursue the matter.
Better yet, I could take Rootstonian up on his/her offer
Yeah, it shouldn't be too difficult to build. And since you already have some of the GUI worked out, you can just pass that on.
I've built one Android app but it was a while ago so I'm very rusty. But it sounds like it can be done pretty quickly.
Jason
For my very first app I've decided I want to make a camera that recalibrates the phone camera to compress the entire detectable range of light into the visible spectrum, creating a false color image that allows the user to see and photograph things normally outside the visual spectrum.
Long term I'd like to create three filters, one that only displays near infrared, one that only displays ultraviolet, and one that let's colorblind users recalibrate the spectrum to ranges they can see.
I've been programming professionally for nearly two decades and have done a few android development tutorials, but this'll be my first android app I'm making without instructions. I must admit I'm a bit lost. Where should I start?
In addition to apps in general, how would you go about getting the raw camera output (not the final image output which seems to be RGB) so that it could be manipulated?
Has anyone had any luck find the source code for the MTCB MCU? I'd like to mod the shutdown timer such that it leaves the device fully operational for the timer duration. Or if anyone has info on the instruction set used, I could perhaps made the mod using assembly or bitbanging.
This may help. It uses an 8051 instruction set
KLD2-v277 "source"
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
dhmsjs said:
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
Click to expand...
Click to collapse
Great work! Thank you! I'm not profound in this MCU programming but I really believe that it is of great importance to hack that code and mod it in order to squeeze more from these units. A applause you and hope other will join your effort.
Open source implementation could be interesting down the road
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
webdude12 said:
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
Click to expand...
Click to collapse
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
dhmsjs said:
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
Click to expand...
Click to collapse
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
webdude12 said:
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
Click to expand...
Click to collapse
While it is by no means complete, I've worked through enough of this MCU code that I think I have a pretty good high-level understanding of how and what the MCU does. As I said above, what I'm missing now is much of the hardware context (for example which MCU pins connect to what, some of the peripheral chip #s, etc), and also the Android software context -- specifically the code that sends commands through SPI to the MCU. I have looked briefly at some of the Android code (for example MTCManager.apk) but didn't find anything useful there. It seems like the SPI interface is lower level -- perhaps as in a device driver??
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
DRidilla said:
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
Click to expand...
Click to collapse
Sound processor yes since that is just sending different commands to the sound processor. Mic mod no since that is a hardware mod only (as far as I can see it anyway).
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
Click to expand...
Click to collapse
My understanding of the mic hardware interconnection is not good enough to say one way or the other. Probably varies from model to model as well (I don't seem to have a big problem with my external mic).
Control radio before Android boots might be tough since most all of the radio user interface comes through Android anyway. Might be possible to restore previous radio config before Android is up, but that might also not be such a great thing for many users. Not sure I'd want my radio to come up blasting away if I don't also have a way to silence it.
Then again with an open source solution, all you would really need is the will to make it so. I guess we all have our own dream lists, no?
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal?
Click to expand...
Click to collapse
Both microphones are hardwired together. It is not possible to "shut off" one with software. There's also a modification to improve the radio's frequency response by replacing some capacitors. Again, not possible with software.
dhmsjs said:
...
Click to expand...
Click to collapse
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Aaaron16 said:
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Click to expand...
Click to collapse
Thanks! Really appreciate the photos. Difficult to read the chip #s though.
I know the radio device is similar to a TEF6624 - maybe a TEF6686?
Pretty sure the sound processor is a BD37531 or BD37534.
Not sure what the video matrix switch is -- FMS6502 maybe?
These all connect to the MCU via I2C. Interested in identifying the other devices that connect via I2C too. I can see the I2C addresses they use to communicate with the chips, but I can't generally look up a chip # by its I2C address. The goal is to find the data sheets for each device so that I can understand exactly what the I2C comm is doing. I have data sheets for the devices listed above.
Also as an update: I stated above that the MCU is controlled by Android through an SPI channel. I've been studying this more closely and it is clear that it is not actually SPI. Looks more like a custom 3 wire interface. Uses pins 1, 2 and 3 of the MCU (the IAP15F2K61S2 device).
Pin 1 (P0.5) is data (or ACK) to Android from MCU, driven by MCU
Pin 2 (P0.6) is the clock, which can be driven by either side (open collector with pullup?)
Pin 3 (P0.7) is data (or ACK) to MCU from Android, driven by the Android CPU
It would be helpful to know which pins these connect to on the Android CPU.
Each bit sent must be acknowledged by the receiver before the next bit is clocked out. There is debouncing and timeouts applied to the signals and the transfer is aborted if either fails. Maximum bit rate is around 1MHz I think, and probably slower in actual use. If anyone recognizes this as a particular comm standard, let me know! Otherwise it must be custom for these HUs.
Component Listing (KGL Mainboard)
I noticed the KGL devices use different radio modules even across the same model. I have some units with TEF6624 modules and others with TDA7786 modules. The following are the IC part numbers for the newer 1024x600px KGL main board (date code 2014-07-20):
1. AU6258J61-JES-GR (USB 2.0 Controller)
2. 15L2K61S2 (MCU)
3. FMS6502MTC (Video Sw Matrix)
4. BD37033FV (Sound Processor)
5. GM8283C (? - 10+ traces going to 50-something pin IDC display connector)
6. T132BT (TFT Video Controller)
7. WM8751L (Stereo DAC) - markings rubbed off. See attached photo.
I couldn't find an I/O expander chip on the main board, so I'm guessing the MCU drives most of the I/O lines directly (aside from those handled by their respective audio/video controllers).
Possibly related, I found this document which seems to include many of the same components:
http://p.globalsources.com/IMAGES/PDT/SPEC/216/K1127159216.pdf
MCU Memory Map/Resource Use
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Could Malaysk make modified MCU with redisigned sound processor and sleep mod fo MTCB-MD-V2.67:angel:. I cant post download link
drive.google.com/file/d/0B9-2UI8L0wScel92bUFlaExkWnc/view?usp=sharing
dhmsjs said:
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Click to expand...
Click to collapse
How is this progressing @dhmsjs ?