>>USB requires a crystal. Internal clock is not accurate enough. So USB >>communication but no crystal won't do.
>But when not using a USB capable PIC, you may get rid of crystal. Do you know >the standard used with SMD crystal ? Does it worth it to use a SMD xtal or is >HC49 form-factor enough ? I'm asking because HC49 is much more easier to find. My standard supplier has two types of epson SMD xtals, the smaller ones are 11.7x4.8mm. That is about the same footprint as HC49. You won't save a lot of space with an SMD xtal then. >Also, some PIC can have two clock sources, one for USB peripheral, another one >for PIC itself. When plugged to a PC, the board can exchange data, when >unplugged, it could go to lower speed and save battery life. That's of course possible. >>> BTW, I wonder how Jal deals with clock speed runtime modification... >>I don't think it does at all. Everything that has some timing in it (like >>delay, serial...) only works correct at the specified clock speed. If you've >>specified 4MHz clock, but run at 32kHz, a _usec_delay(1000) won't delay 1 ms, >>but 125ms. >I know, pragma clock can be defined only once. But is this only about >_usec_delay ? I can't anothe issue, but I may be wrong. Otherwise it could be >possible to re-define _usec_delay in some way (...) and have multiple >implementation depending on selected speed. serial_hw calculates the baud rate timers from the pragma clock and I think there are other libs that rely on that. There's the question again about "redefinable constants" or "compiler variables" that are only used while compiling but which are not going into the resulting asm code as variables. We've had that request before when talking about different optimization targets for different libs... And I think that would only touch the compiler frontend, so that might be an addition to the compiler to think about... A problem here can be when a procedure or function is called from both low-speed and high-speed parts. For a start the compiler could simply throw an error then. Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
