OEM driver use for on-chip peripherals

Questions on other types of hardware and getting it talking to the ARM CPU
Post Reply
TodWulff
Posts: 42
Joined: Fri Oct 19, 2012 4:03 am
Location: The Mitten State - Shores of Lake Huron

OEM driver use for on-chip peripherals

Post by TodWulff » Thu Sep 06, 2018 7:10 pm

olzeke51 wrote:
Fri Jun 06, 2014 2:08 pm
...with the LPC8xx series, they have a boot rom API that has routines for
several built in peripherals . DO the other chips have this API available?

Is there a way to CALL them ?? I2C is one I had in mind - but it requires
a buffer pointer to be passed to it (along with other variables), I figure
the INTERRUPT SUB could process the buffer contents -
a string (array) of 512 bytes could be chopped up

Bit-banging would seem to take more time , especially if this data is
being passed to other serial devices -- 'course Real World Time is a
lot slower than microcontroller time !!!!!

Just a thought -- olzeke51
basicchip wrote:
Fri Jun 06, 2014 9:03 pm
Between __ASM__ and CALL (expression) and knowing that when you assign a variable the last value is left in R7, yes

I have used them to make IAP calls, which are different than API calls. Some of the API calls are poorly documented from NXP.
Has anyone had success with making ARMbasic use of the driver code that reportedly exists in the ROM for the newer NXP devices' peripherals?

As Gary had enumerated, it could certainly serve to lighten the weight/efficiency of user ARMbasic code - i.e. offloading the serial comms stuff to the OEM driver code and on-chip peripherals vs. bit-banging is just one example use case. I almost salivate at the idea of avoiding the overhead of having to bitbang the heck out of the IO, when the resources to avoid doing so is baked into the silicon.

I'm likely to go down the path of writing ARMbasic wrappers for the onboard UART and SPI devices/drivers, having just thrown in the towel on trying to port over NXP's libs from C++ to ARMbasic (had just about got it when I ran into problems with some of the typedef structures and enumerations). I just don't want to reinvent the wheel, if someone has already written an ARMbasic wrapper for these on-chip peripherals & drivers.

Please advise. TIA.

-t



olzeke51
Posts: 327
Joined: Sat May 17, 2014 4:22 pm
Location: South Carolina
Contact:

Re: OEM driver use for on-chip peripherals

Post by olzeke51 » Mon Sep 10, 2018 7:34 pm

So......
[this doesn't offer any help]
So... :) I am not the only one to attempt to take C/C++ and translate to ARMBasic !!!
'
I tried to do it with the LCD routines of some of the Adafruit devices. Lost my steam....
Olzeke

TodWulff
Posts: 42
Joined: Fri Oct 19, 2012 4:03 am
Location: The Mitten State - Shores of Lake Huron

Re: OEM driver use for on-chip peripherals

Post by TodWulff » Tue Sep 11, 2018 4:02 pm

Hi Gary! I hope this finds you doing well, kind sir. Yeah, I am too trudging down a similar path. 8-)

I've not lost steam yet & am actually revisiting using ported C libs (vs. using on-chip drivers) now that I've gained a bit of additional mental clarity. I started to recut my AB teeth with the 824 & found that it has a bunch of the drivers on-chip and are seemingly very well documented. However, this is not the case with other NXP devices, namely the 11U37 and the 54102 (which I am using with a USB host ASIC (+ Blue Tooth nubbins) to enable remote control of a system with a BT joystick/gamepad device). The 11U37 has only INTDIV, POWER, and USB on-chip drivers (note that the docs have quite a robust set of well-documented drivers for USB peripheral use, I perceive - that is on the list to exploit this winter in another project). The UM leads one to believe that the 4K EEPROM has a driver but I am suspecting that they are referencing the ISP/IAP code being expanded to accommodate the EEPROM - sort of misleading, I perceive. BUT, that reinforces what Bruce had asserted - NXP's on-chip stuffs can be poorly documented at times.

I'll update and share any works I end up getting implemented in a manner that yields some success.

<shifting gears>

In harmony with the spirit of sharing, in case it may be of help to you with your current LCD efforts (if you're still pursuing that), I've (very old) AB code, having originally dev'd it more than a decade ago, that I recently dusted off and got working last week with Bruce's newer goods (with a small bit of tweaking (surprisingly not too much)). They are attached herein for your use/corruption.

As info, the AB_Extensions lib is just a default #inc that I use during dev. It has some possibly useful and likely non-useful/erroneous/useless stuffs therein - 'I admit nothing' (<-- done in my best Sgt Schultz voice) - rape away - no attribution needed or desired - all liability disclaimed... :ugeek:.

Image

Have a great week.

-t
Attachments
AB_LCD.7z
NXP LPC824 DIP device, with ARMbasic thereon, driving a 16x2 character LCD.
(13.06 KiB) Downloaded 17 times

Baumann
Posts: 1
Joined: Tue Nov 27, 2018 9:23 am

Re: OEM driver use for on-chip peripherals

Post by Baumann » Wed Nov 28, 2018 10:55 am

That's very neat, Tod. What did you develop this for initially btw?

TodWulff
Posts: 42
Joined: Fri Oct 19, 2012 4:03 am
Location: The Mitten State - Shores of Lake Huron

Re: OEM driver use for on-chip peripherals

Post by TodWulff » Sun Dec 02, 2018 6:35 pm

Nothing in particular, actually. I did this to blow the dust off of my gray matter, as it had been so long since I actively programmed embedded stuffs.

Also, it will be put to use this winter, as a debug tool, and possibly as a proper display if I gain traction on another project before spring.

Post Reply