memory

"How much space do we need for the statuses?"

I think if we plan on 4 square inches, we'll be fine.

"bcoz do we need more than statuses than code?"

Yes, that's why 4 square inches. The code fits in a little less than 2.

"i don't need to get back to sleep ..."

Me neither. Our new project is so fun and exciting, who needs sleep?!!!

dazheng,

I was looking abot the circuit for atrication process
i found this article:

Basically, there is no difference. The operational sequence
is designed to handle analog signals as long as you do not
overdrive it. This enables us to do a number of operations
at the same time (log, antilog, invert,rectify, add, subtract
etc.) on analog signals (i.e. signals which vary continuously).
If you overdrive the MCU, then you can use it with digital
signals too, though nobody will prefer that. There are much
better options for signals above 122%. Negating the charge
causes a positive overlap which throws the logic into an
opposite contrajecture.

there are some bits i (?) dont understand but is it right area for project.

zuisti

Note
This message was edited to reduce width.

"there are some bits i (?) ..."

Why the '?' question mark? Are you doubting your existence?

I'm beginning to wonder about your participation in our project.

I may have to start looking elsewhere for someone more qualified.

"... dont understand but is it right area for project."

See, that's what I mean.

If you don't understand, what is your contribution and value to our project?

zuisti,

I want to use the 89c734a bcoz i think it has the pins we need. can you get the code done for it. can we take the EEPROM out of the MCU?

Do we need above 122%? how much?

"can we take the EEPROM out of the MCU?"

Sure, no problem. We'll pop the top and pull it out with non-conductive tweezers.

"Do we need above 122%? how much?"

No, I'm calculating that 7.3% less than that is closer to ideal.

"No, I'm calculating that 7.3% less than that is closer to ideal."

But that still leaves us at ~113%. How do we deal with greater than 100%?

Should we put the EEPROM back in the MCU to make up the difference?

"RCF rope is so simple my third grader uses it without any trouble at all."

Maybe dazheng, zuisti, et al could hire your 3rd grader as a Consultant?

Or would that just be money for old rope...?

"Dont try to find the rope option. I looked on web and the version doesnt use it."

Yes, I usually find that it's difficult to use options that don't exist!

"Maybe dazheng, zuisti, et al could hire your 3rd grader as a Consultant?"

Yes! As demonstrated by the dialog in this thread and their other threads in this forum, the team is in desperate need of improvement.

But don't forget that from the current level, improvement should not be so hard...

Even a blind hen...

Hi dazheng,

forget the EEPROM.ive got something better

i have already implemented ADPCM successfully,the
problem i am having with MMC card interfacing is that
when i try to record compressed voice data on MMC
card,the voice upon retrieval from the card at PC end
gives a jerk after 2-3 seconds of voice play back
may be this jerk is due to sector change ,every sector comprises 510 bytes

What i am trying to design is, the 83TF892 takes
analog input data ,performs A/D conversion ,which
generates 11-bit data samples at rate of 7.2KHz ,these data samples are then subjected to ADPCM speech compression which (?) generates 4 bit compressed data
sample from 16-bit data sample ,then it takes other uncompressed data sample and compresses it to 4-bit ADPCM compressed data sample
These two data samples are then packed in a single byte,this byte containing two ADPCM data sample is then written to MMC card.This is recording process
once we are done with recording ,we need to retrieve the data , For retrieval the Micrcontroller reads compressed voice data from MMC sector by sector and transmits it to PC through serial port
which is recorded on pc in binary file
this binary file is decompressed using JavaC and then decompressed and converted to wave file through more JavaC code

can you help with any of it?

Thanks

zuisti

If you generate audio data at 7.2kHz - what do you think will happen if your PC can't play at that odd speed, and instead consume them at 8kHz speed?

zuisti,

ignoer the info from the trollops!

i thin kthe problem is you have a sector of 510 bytes.but mostly it is 512.

ya, im a wheel coder man. hahahaha

But ive got a problem with this now(?) so maybe you help me ;)

I make a simple ISOS DRSN file to toggle LED on PortD.4. I just connect 2 button on PortB. One button PortB.4 as reset button. PortB.7 as toggle swicth. I also put a delayMS = 500 as protection from button bounceying.

My question,

1. How to make LED toggle on rising edge instead of MCU have to scan the state condition of the button and respond according if.. then statement. That mean (for edge rising signal ... 0 to 5V) MCU been triggered by rising edge of signal from low to high or hight to low or high to high.

2. I'm using Xtal = 31Mhz ... and I dont connect any crytal (actually I want to use internal oscilator with PLL ) .... how to write the code for that ? any example ?

Thanks for any helps.

"i thin kthe problem is you have a sector of 510 bytes.but mostly it is 512."

Mostly 512? Check the spec again. What about the 518-byte sectors?
And what about the 502-byte, 554-byte, and the jumbo 1024-byte sectors?
We've got to handle those too. It's all there in section 3.1.4.1.59.

"1. How to make LED toggle on rising edge instead of MCU have to scan the state condition
of the button and respond according
if.. then statement. That mean (for edge rising signal ... 0 to 5V) MCU been triggered by
rising edge of signal from low to high or hight to low or high to high."

Qualify the if/then with an X/OR of the LED input and TMR0's MSB.
Trigger is best by rising edge of signal low to low.

"2. I'm using Xtal = 31Mhz ... and I dont connect any crytal (actually I want to use internal oscilator with PLL ) .... how to write the code for that ? any example ?"

You're in luck. I've already done the code for that. I made a development branch
off of mainline and checked osc_cfg.c into Perforce.

dazheng,

your a great programmer man.sector size woz wrong!

Rego has been working now on a conversion to Proton Basic (I don't have skills about MCU basics yet, as I wrote).
I somebody want to do this, my C source is simple and easy to understand I think...

i like your project much,and it is a good effort from
u (converting it to JavaC project) but how about writing a (v.b interface to it) it will
be very cool....

also did u test the real hardware (ig is there any problem in led power or anything like this)

this project can be upgraded with many opinons..

But ... my dear friend, please post your minds, repairs and opinions here!