anyone know what's going on with oshonsoft?

[Me]

They have (had?) a great IDE for PIC's and were making lot's up additions
and bug fixes to to them up to about the end of march 2007 then everything
stopped.

They still post new testimonials on the website but the only reply to bug
reports is an automated reply.

There is a serious bug in the Oshon PIC IDE reguarding PICs with internal
PLL multipliers not being programmed correctly. The simulator and compiler
are using the external clock rate rather than the PLL generated clock when
it is selected. This screws up bit communication rates, delays, etc. that
rely on the clock frequency.

If it wasn't for the end of support 6 months ago I'd say they were the best
bang for the buck when it comes to PIC programming packages.

 

[Scott Seidman]

There is a serious bug in the Oshon PIC IDE reguarding PICs with
internal PLL multipliers not being programmed correctly. The simulator
and compiler are using the external clock rate rather than the PLL
generated clock when it is selected. This screws up bit communication
rates, delays, etc. that rely on the clock frequency

Isn't this just one fuse? Can you change it manually??

 

[Me]

Isn't this just one fuse? Can you change it manually??

the problem isn't the config bits being set wrong it's the simulator and
the code the compiler creates. If you set the config for intPLL the
compiler sets the config bits for that but ignores the PLL created osc
freq.when generating values for registers and instead timing is based on
what you said the external clock osc. was.

-ex.: the statement waitMS 12 sets a delay of 1 Ms if the 18F4550 is used
with intPLL as the osc source (x12).

-ex. you set up for rs232 and a baudrate of 19.2K and you can't communicate
with a PC who's hyperterm is set to the same because your baudrate is off
by a factor of 12.

-firmware debounce of switches can fail, stepping motors turn at the wrong
speed, timer base interrupts happen at the wrong interval, the list goes
on.

it's probably also a problem with USB and other (serial memory etc.) timing
based items; but I haven't had time to use it.

Sure, there are workarounds for these by jamming the correct code into the
appropriate registers after the compiler does it wrong; once you've
identified the problem. Do you really want to buy a software package and
have to identify and create fixes for all time based uses if using intPLL
modes? The point was, what happened to oshonsoft. They use to be great
about putting out bug fixes and respond to bug report/questions quickly.
Now it's been about 6 months and not a peep out of them. They must still be
around. New glowing testimonials appears every couple of weeks on the site.

 

[Scott Seidman]

Do you really want to buy a software package and
have to identify and create fixes for all time based uses if using
intPLL modes?

No, but for 29 Euros, you put up with a lot. I like CCS, personally, but
it does cost more.

Have you tried the oshonsoft contact page?